DevSecOps 機能モデルは、エンジニアリング組織がソフトウェアの構築、セキュリティ保護、出荷、運用方法を評価するのに役立ちます。 これは、より成熟した、安全で回復力のあるプラクティスへの道筋を示すのに役立ちます。 このモデルでは、6 つの機能領域にわたる体験が記述され、それぞれが成熟度の 5 つの段階を経て進んでいます。
このモデルを使用して、チームが現在どこにいるかを理解し、自分が望む場所に同意し、そこに到達する増分変更を計画します。 モデルは説明的であり、規範的ではありません。 これは、1 つのスコアを生成するのではなく、製品、開発、セキュリティ、運用全体で共有の理解を作成することを目的としています。
このモデルは、Microsoftセキュリティで保護された将来のイニシアチブの目標に沿っています。 ほとんどの組織は、さまざまな機能領域で異なる段階にあります。
6 つの機能領域
このモデルでは、DevSecOps プラクティスが 6 つの機能領域に編成されます。 一緒に、組織の主導と管理方法から、ソフトウェアの設計、構築、リリース、運用の方法まで、完全なライフサイクルに及びます。
- 組織と文化: リーダーシップ、セキュリティの考え方、コラボレーション、チーム全体の継続的な改善。
- 標準とガバナンス: セキュリティ プログラム、ポリシーと標準、エンジニアリング システムの保護。
- 計画と設計: セキュリティで保護された設計プラクティス、データと分析情報、および技術的なアーキテクチャと設計。
- 開発とテスト: コード セキュリティ、開発アクセラレータ、統合とテスト。
- リリースとデプロイ: セキュリティで保護された依存関係、セキュリティで保護されたリリース、展開ワークフロー。
- 運用と監視: テナントと運用システムの保護、脅威の監視と検出、インシデント対応と修復。
5 つのステージ
すべての機能領域は、成熟度の同じ 5 つの全体的な段階を経て進行します。 また、各機能領域では、独自のステージ名を使用して、その特定のコンテキストにおける成熟度を記述します。
| 全体の段階 | 見た目 |
|---|---|
| アドホック | プラクティスは断片化され、手動で、大部分は文書化されていません。 結果は個人によって異なります。 |
| 開始 | 個々のチームは、ローカルで一貫性を促進し始め、表面に表示されるギャップに対処します。 |
| オーケストレーター | プラクティスは一元化され共有され、チームは一般的なアプローチとリソースを中心に調整されます。 |
| 効率化 | 世界クラスのツールとプラクティスにより、手動作業が削減され、安全なパスが簡単なパスになります。 |
| 先駆的な | プラクティスは、業界を定義し、予測可能であり、必要に応じて継続的に進化しています。 |
戦略的アプローチ
組織は、ビジネス コンテキストに応じてさまざまな方法で機能モデルを使用できます。 柔軟性が必要なチームもあれば、速度を最適化するチームもあれば、強力なコンプライアンスとリスクコントロールに優先順位を付けるチームもあります。
- アジャイル DevSecOps: DevSecOps プラクティスを確立、更新、または統合する組織の柔軟性を重視しながら、速度と有用な標準のバランスを取ります。
- 高速 DevSecOps: 配信効率を自動化、簡素化、改善する確立されたプラクティスを持つ組織の速度を強調します。
- セキュリティ優先の DevSecOps: 厳しく規制された環境またはミッション クリティカルな環境で活動する組織のコンプライアンスとリスク削減を重視します。
現在のプラクティスを評価し、将来の目標を設定する
モデルを使用して、作業を行うユーザーと共に軽量の自己評価を実行します。 目標は、今日の共有された正直な画像と、明日のための合意された方向性です。
空白のグラフから始める
空の機能モデル グラフを使用して、現在の状態とターゲットの状態をキャプチャします。
詳細な参照グラフを使用する
各ステージが機能領域全体でどのような外観であるかを説明するときは、詳細なグラフを参照として使用します。
現在の状態をマークする
各機能領域について、ステージの説明について説明し、現在のプラクティスに最も適したステージをマークします。
マークをつなぐ
6 つの領域にマークを接続して、現在のプロファイルを視覚化します。
ターゲット ステージをマークする
計画期間を通して、各機能領域に到達するターゲット ステージをマークします。
段階的な変更を計画する
段階的な変更を計画する。 一度に 1 つのステージを進めることは、通常、一度にどこでも先に進もうとするよりも耐久性が高くなります。
組織や脅威の状況の進化に合わせて、進捗状況を追跡し、ターゲットを調整するために定期的に再評価します。
ガイドの質問を使用して優先順位を設定する
次に投資する場所を選択する場合は、ガイドの質問を使用して、各機能領域の会話に集中します。
- 組織と文化: 少数の所有者が所有する後期ゲートではなく、セキュリティを共同責任と誇りの源にするにはどうすればよいですか?
- 標準とガバナンス: チームを遅くすることなく、エンジニアリング システムを保護する明確で十分に理解された標準を確立するにはどうすればよいでしょうか。
- 計画と設計: データと分析情報によって情報を得て、セキュリティで保護された設計を計画とアーキテクチャの既定値にするにはどうすればよいですか?
- 開発とテスト: コードが出荷された後ではなく、コードが記述されるときに問題が見つかり、修正されるように、セキュリティを残したままにするにはどうすればよいですか?
- リリースとデプロイ: 依存関係からデプロイまで、リリースをセキュリティで保護され、反復可能で、信頼できる状態にするにはどうすればよいですか?
- 運用と監視: 運用環境のシステムとテナントに対する脅威を検出、耐え、復旧するにはどうすればよいでしょうか。
顧客プロファイルの例
次の例は、実際の顧客プロファイルが機能領域全体で不均等な成熟度を示し、次に投資の優先順位を決定する場所を特定する方法を示しています。
