米国防総省（DoD）におけるDevSecOps（第3章1-2節）#DevSecOps

原文・参照先資料
[DoD Enterprise DevSecOps Reference Design - DoD CIO](https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf?ver=2019-09-26-115824-583)

#3 DevSecOpsの概念
　DevSecOpsは、組織が開発者(Dev)、セキュリティチーム(Sec)、運用チーム(Ops)の間のギャップを埋めることを可能にする組織の文化とプラクティスです。協調的で機敏なワークフローによってプロセスを改善する。テクノロジーを活用した、より迅速で安全なソフトウェア提供を推進する。一貫したガバナンスとコントロールを実現する。統一されたDevSecOpsプラクティスは存在しない。各DoD組織は、その文化とDevSecOpsプラクティスを、独自のプロセス、製品、セキュリティ要件、運用手順に合わせる必要がある。DevSecOpsを採用するには、組織の文化を変え、既存のプロセスを進化させ、新しいテクノロジを採用し、ガバナンスを強化する必要があります。
　このセクションでは、DevSecOpsのライフサイクル、サポートの主要要素、DevSecOpsのエコシステムについて簡単に説明します。

## 3.1 主な用語
 このドキュメントで使用されている主な用語を次に示します。完全なリストについては、付録Bの用語集を参照してください。

表1:主な用語

|用語|定義|
|---------|----------------------------------------------------------|
|DevSecOpsエコシステム|DevSecOpsのライフサイクル全体を通してすべてのアクティビティをサポートするために、ツール上で作成され、実行されるツールとプロセスワークフローの集合体。<br />プロセスワークフローは、完全に自動化されている場合もあれば、半自動化されている場合、手動の場合もある。|
|ソフトウェアファクトリ|複数のパイプラインを含むソフトウェア開発プラント。ツール、プロセスワークフロー、スクリプト、および環境のセットを備え、最小限の手動操作でソフトウェア配布可能なアーティファクトセットを生成する。開発、ビルド、テスト、リリース、デリバリといったフェーズのアクティビティを自動化する。ソフトウェアファクトリはマルチテナントをサポートしている。|
|CI/CDパイプライン|CI/CDオーケストレータによって操作され、可能な限り自動化されているツールセットと関連するプロセスワークフロー。ビルド、テスト、セキュリティ、リリースのデリバリと、継続的インテグレーション(CI)と継続的デリバリ(CD)を実現する。|
|CI/CDパイプラインインスタンス|単一のプロセスワークフローと、プロジェクトの特定のソフトウェア言語およびアプリケーションタイプのワークフローを実行するツール。パイプラインプロセスの大部分は、可能な限り自動化されている。|
|環境|ソフトウェアコンポーネントを配備、実行する境界を設定するもの。一般的な環境には、開発、連結、テスト、本番運用などがある。|
|ソフトウェアファクトリ・アーティファクト・リポジトリ|ソフトウェアファクトリに関連付けられたローカルリポジトリ。DoD Centralized Artifact Repository (DCAR) からプルされた成果物と、DevSecOpsプロセスで使用するためにローカルで開発された成果物を格納する。アーティファクトには、仮想マシン(VM)イメージ、コンテナイメージ、バイナリ実行可能ファイル、アーカイブ、ドキュメントなどがある。マルチテナントをサポートしている。<br />プログラムには1つのアーティファクト・リポジトリがあり、タグを使用してコンテンツ・タイプを区別することができる。ローカル・アーティファクトとリリース済アーティファクトを保管するために、別々のアーティファクト・リポジトリを持つこともできる。|
|コード|プログラミング言語で書かれた、コンピュータ用のソフトウェア命令。これらの命令は、人間が読み取り可能なソース・コード、またはマシン実行可能命令にコンパイルされたソース・コードであるマシン・コードのいずれかの形式とすることができる。|
|コンテナ|オペレーティングシステム(OS)までのコードとそのすべての依存関係をパッケージ化するソフトウェアの標準単位。軽量でスタンドアロンの実行可能ソフトウェアパッケージで、OSを除くアプリケーションの実行に必要なすべてのもの (コード、ランタイム、システムツール、システムライブラリ、設定) が含まれている。<br /> 複数のコンテナを同じOS上で実行しても、互いに競合することはない。<br />![image5.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440539/519f9cc2-bf98-62df-d836-ec9fac8a0c69.jpeg)<br />図1 コンテナ<br />コンテナはOS上で動作するため、ハイパーバイザ(仮想化)は必要ない(OS自体はハイパーバイザー上で動作しているかもしれないが)。<br />コンテナはVMに比べて非常に小さく、通常は1000倍(MB単位vsGB単位)の差がある。これはコンテナにOSを含める必要がないためである。コンテナを使用すると、VMよりもアプリケーションを密にパッキングできる。<br />VMとは異なり、コンテナはクラウド間やクラウドとオンプレミスサーバ間で移動可能である。これにより、Cloud Service Provider(CSP)のロックインを軽減することができる。アプリケーションがCSP固有のサービスを使用する場合、CSPにロックインされたままになる可能性がある。<br />コンテナはVMよりもずっと高速に起動する(秒単位vs分単位)が、これはOSが起動する必要がないからである。|

### 3.1.1 コンセプトモデル
　次の概念モデルは、この文書で説明する最も重要な概念のいくつかを、それらの関係とともに示しています。これらの関係を明確にするのに役立つはずです。矢印に沿ってテキストを読むときは、矢印の方向に従います。そのため、DevSecOpsエコシステムには1つ以上のソフトウェア・ファクトリーが含まれ、各ソフトウェア・ファクトリーには1つ以上のパイプラインが含まれます。この図は、各ソフトウェア・ファクトリーにはCI/CDオーケストレーターが1つしかなく、多くのソフトウェア・ファクトリーがDCARを使用していることも示しています。
![image6.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440539/55979a42-561f-98ef-baaf-1d8e234aff55.jpeg)
　　　　　　　　　　　　　　　　図2:概念モデル

## 3.2 DevSecOpsのライフサイクル
　DevSecOpsソフトウェアライフサイクルフェーズを図3に示す。計画、開発、構築、テスト、リリース、提供、展開、運用、監視の9つのフェーズがあります。セキュリティは全てのフェーズに関連します。
![image7.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440539/280818e5-6ecb-30a7-e994-16c8c955d1fe.jpeg)
　　　　　　　　　図3:DevSecOpsのソフトウェアライフサイクル

　DevSecOpsでは、ソフトウェア開発ライフサイクルは一枚岩の線形プロセスではない。ウォーターフォールプロセスの「ビッグバン」式デリバリーは、小さくても頻繁なデリバリーに置き換えられ、必要に応じてコースを変更しやすくなっている。個々の小規模なデリバリは、完全に自動化されたプロセスまたは半自動化されたプロセスによって、最小限の人手介入で達成され、継続的なインテグレーションとデリバリを促進します。DevSecOpsのライフサイクルは適応性があり、継続的改善のためのフィードバックループがたくさんある。