DevSecOpsとコンテナセキュリティーーSREが知っておくべき運用設計の考え方

DevSecOpsは、開発前のシフトレフトから本番稼働後のランタイム対応まで、コンテナのライフサイクル全体にまたがる取り組みです。本記事ではそのなかでも、SREやプラットフォームエンジニアが特に押さえておくべき「運用設計」に焦点を当てます。

ここでいう運用設計とは、単なるツール設定ではありません。誰が、いつ、何を、どの基準で対応するのか。つまり、役割分担、責任範囲、SLA、エスカレーション、フィードバックループを含む、組織的なセキュリティ運用の設計を指します。

とりわけ重要になるのが、「本番で実行中のCritical脆弱性を72時間以内に対応する」という72h SLAです。スキャンで検出されたすべての脆弱性を同じ優先度で扱うのではなく、Runtime In-Use、すなわち実際に本番で使われているかどうかを判断軸に加えることで、現実的かつ効果的な対応優先度を設計できます。

「シフトレフトを導入したが、開発者から『スキャンツールがうるさすぎて開発が進まない』と苦情が出ている」――こうした課題を抱えるSREやプラットフォームエンジニアは少なくありません。セキュリティを強化しようとするほど開発速度が落ち、結果としてツールが形骸化していく。この矛盾を解消する考え方がDevSecOpsです。

DevSecOpsとは、セキュリティをセキュリティチームだけに任せるのではなく、開発・運用・セキュリティのすべての関係者が連帯責任を持つアプローチです。しかし、コンテナ、Kubernetes、AIエージェントが当たり前になった現在、必要なのは「ツールを入れること」ではなく、ライフサイクル全体をどう運用としてつなぐかです。

本記事では、DevSecOpsをSRE視点の運用設計として捉え、役割分担、RACI、SLA、体制、フィードバックループの観点から体系的に解説します。

DevSecOpsとは何か――「運用設計のまとめ役」としての位置づけ

DevOpsは、開発と運用を統合し、継続的なデリバリーを実現するためのアプローチです。計画、コーディング、ビルド、テスト、デプロイ、運用を継続的なループとして設計し、開発者と運用担当者がソフトウェアデリバリ全体に責任を持つことを促します。

DevSecOpsは、このDevOpsにセキュリティを組み込む考え方です。重要なのは、セキュリティを後付けで追加しないことです。アプリケーション完成後にレビューする従来型のモデルでは、問題の発見が遅れるほど修正コストが膨らみ、リリース直前の手戻りがチーム全体を疲弊させます。

DevSecOpsはこの構造を変え、セキュリティをソフトウェアデリバリの各段階に組み込みます。ただし、その本質は個別ツールの導入ではありません。シフトレフト、CI/CD、Policy as Code、Admission Control、ランタイム検知、インシデント対応をひとつの運用フローとしてつなぎ、「誰が・いつ・何を・どのSLAで担うか」を設計することにあります。

つまりDevSecOpsは、コンテナセキュリティの各施策をつなぐ「運用設計のまとめ役」です。本記事では、このつなぎ方に焦点を当てます。

コンテナ時代にDevSecOpsの運用設計が重要になる理由

コンテナ環境でDevSecOpsが特に重要になる理由は、脆弱性や設定ミスの影響範囲が短時間で広がりやすいためです。同じコンテナイメージが数百、数千のPodやサービスに展開される環境では、脆弱なイメージが本番に混入した瞬間、そのリスクは一気に複数の環境へ波及します。

さらに、ソフトウェア・サプライチェーン攻撃のリスクも高まっています。攻撃者は、アプリケーションコードだけでなく、ベースイメージ、OSSライブラリ、CI/CDパイプライン、レジストリなど、開発・配布プロセスの上流を狙います。汚染されたベースイメージが一度取り込まれれば、それを利用するすべての環境にリスクが広がります。

このような環境では、「後でセキュリティを確認する」というアプローチは機能しません。KubernetesのRBAC、IAM、ネットワークポリシー、コンテナイメージ、ランタイム挙動は、開発チームだけでも、セキュリティチームだけでも、運用チームだけでも管理しきれないからです。

必要なのは、ライフサイクル全体を横断する運用設計です。Plan・Code、Build・Test、Deploy、Runtime・Operateの各段階を分断せず、検出結果、責任者、対応期限、再発防止策をひとつの流れとして設計することが、コンテナ時代のDevSecOpsには欠かせません。

コンテナを狙う具体的な攻撃手法の詳細は「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」を、コンテナを対象とした脅威の全体像は「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」をご覧ください。

SREが担うDevSecOpsの役割

セキュリティインシデントをサービス停止インシデントとして捉える

従来、SREの主な関心は可用性、信頼性、MTTRの最小化にありました。しかしクラウドネイティブ環境では、セキュリティインシデントがそのままサービス停止やSLO違反につながるケースが増えています。

ランサムウェアによるシステム停止、認証情報の窃取によるAPIの不正利用、コンテナ侵害による計算リソースの無断使用などは、いずれもサービスの信頼性を損ないます。つまり、セキュリティインシデントはSREにとっても運用インシデントです。

この認識に立つと、SREはランタイムセキュリティの第一応答者として重要な役割を担います。検知、トリアージ、影響範囲の把握、封じ込め、復旧、ポストモーテムまでを、通常のインシデント対応と同じように設計する必要があります。

なお、ランタイムインシデントに対する初動対応と、脆弱性修正のSLAは分けて考える必要があります。例えば、進行中の攻撃に対しては数秒から数分単位の検知・理解・対応が求められます。一方で、本番で実行中のCritical脆弱性に対しては、修正、緩和策、一時的な回避策を72時間以内に実施する、といった別の時間軸で管理します。

この2つを混同しないことが、現実的な運用設計の第一歩です。

Dev・Sec・Opsの役割分担を明確にする

DevSecOpsを機能させるには、各ロールの責任範囲を明確にしつつ、同じ情報を見られる状態を作ることが重要です。「誰が何を担当するか」だけでなく、「誰が同じリスク状況を見て判断しているか」を揃えることが、協働の起点になります。

開発者は、コードレビュー時のSCA、IaCチェック、シークレット管理、PR上でのスキャン結果の確認と修正対応を担います。主戦場はシフトレフト段階です。

セキュリティ担当は、ポリシー策定、ツール選定、検知ルールの設計、リスク評価、インシデント対応方針、コンプライアンス管理を横断的に担います。

SREや運用チームは、ランタイム監視、アラートのトリアージ、封じ込め、フォレンジック、MTTRの最小化、自動応答フローの設計と維持を担います。

重要なのは、これらをサイロ化させないことです。Secが脆弱性を報告するだけ、Devが修正を後回しにするだけ、SREがランタイムアラートに追われるだけ、という状態では、誰もボールを持っていない脆弱性が生まれます。共通のダッシュボード、共有されたSLA、明文化された責任分担が、この分断を防ぎます。

RACI設計とSLA設計――「宙に浮く脆弱性」を生まないために

DevSecOpsが機能しない組織では、脆弱性の責任が曖昧になりがちです。スキャンツールがCritical脆弱性を検出しても、SecはDevに報告し、DevはSREに影響確認を依頼し、SREは「本番に影響がなければSec判断で」と返す。その間に、危険なリスクが放置されてしまいます。

この問題を解消するには、RACIとSLAをセットで設計する必要があります。

RACIマトリクスで責任の所在を明確にする

RACIは、対応に関わる役割を次の4つに分ける考え方です。

• Responsible：実行責任者
• Accountable：説明責任者
• Consulted：相談先
• Informed：報告先

脆弱性対応であれば、例えば次のように設計できます。

Responsibleは、修正コードを書く開発者です。Accountableは、Secのリスク評価を踏まえ、サービス影響や運用観点から最終判断するサービスオーナー、SRE、テックリード、またはプロダクト責任者です。Consultedは、脆弱性のリスク評価や修正方針を提言するセキュリティ担当です。Informedは、対応状況を把握するプロダクトオーナーやマネジメント層です。

ポイントは、リスクの大きさをSecが評価し、運用上の現実解をSREやテックリードが判断し、最終的な責任者を明確にすることです。これにより、「誰がボールを持っているか」が曖昧なまま脆弱性が放置される状態を防げます。

深刻度別SLAを定義する

RACIが「誰が」を決める仕組みだとすれば、SLAは「いつまでに」を決める仕組みです。両方が揃ってはじめて、開発チームは何をいつまでに直すべきかを自律的に判断できます。

推奨するSLAの考え方は次のとおりです。

このなかで特に重要なのが、「Critical×Runtime In-Useは72時間以内」という基準です。すべてのCritical脆弱性を同じ期限で直そうとすると、開発チームは疲弊し、SLAそのものが形骸化します。そこで、本番で実際に使われているかどうかを判断軸に加えます。

Runtime In-Useとは、脆弱性を含むパッケージやコンポーネントが、実際に本番環境で実行されている状態を指します。実行されていない脆弱性は、現時点では攻撃者が悪用できる経路が限られるため、優先度を一段下げて評価できます。ただし、将来的に実行される可能性があるため、対応不要になるわけではありません。

この絞り込みによって、72h SLAは「達成不能な理想論」ではなく、「本当に危険なリスクに集中するための現実的な基準」になります。

72h SLAを機能させる3つの条件

72h SLAを運用に根付かせるには、次の3つが必要です。

1つ目は、Runtime In-Use判定の自動化です。どの脆弱性が本番で実行中なのかを自動的に把握できなければ、SLAの対象を定義できません。

2つ目は、SLAタイマーとチケット管理の連動です。Runtime In-UseのCritical脆弱性が検出された時点でチケットを起票し、72時間のカウントを開始します。RACIで定めたResponsibleにアサインし、Accountableへのエスカレーション経路も明確にします。

3つ目は、SLA遵守率のKPI化です。「Runtime In-Use脆弱性の72時間以内対応率」をダッシュボードで可視化し、月次または四半期でレビューします。遵守率が低い場合は、母集団が広すぎるのか、体制が不足しているのか、承認プロセスが遅いのかを見直す必要があります。

72h SLAは、単なる数値目標ではありません。RACI、Runtime In-Use判定、72時間という期限が噛み合ってはじめて機能する、DevSecOps運用設計の中核です。

DevSecOps運用設計：ライフサイクル4フェーズの責任とプロセス

DevSecOpsは、ツールを導入するだけでは機能しません。コンテナのライフサイクルを、Plan・Code、Build・Test、Deploy、Runtime・Operateの4フェーズに分け、それぞれの責任とプロセスを設計する必要があります。

フェーズ1｜Plan・Code段階――設計時の責任を決める

セキュリティは、設計・コーディングの段階で組み込むほど修正コストを抑えられます。運用設計の観点では、脅威モデリング、公開範囲、扱うデータ、最小権限のIAM設計などを、誰がレビューし、誰が承認するのかを明確にすることが重要です。

また、開発者が安全な選択肢を自然に選べる環境を整えることも欠かせません。IDEプラグイン、承認済みベースイメージ、標準化されたIaCモジュール、セキュアなCI/CDテンプレートなどを用意することで、開発者の負担を増やさずにセキュリティを組み込めます。

フェーズ2｜Build・Test段階――シフトレフトを運用に接続する

ビルド・テスト段階は、シフトレフトの主戦場です。SAST、SCA、DAST、IAST、SBOM生成、イメージスキャンなどのセキュリティゲートをCI/CDに組み込みます。

ただし、検出するだけでは不十分です。重要なのは、検出結果をRACIとSLAに接続することです。どの検出結果をブロック対象にするのか。どのリスクをチケット化して後続対応に回すのか。誰が修正し、誰がリスクを承認するのか。これらを決めなければ、スキャン結果は単なるノイズになります。

SBOMもこの段階で重要な役割を果たします。新たな脆弱性が公開された際に、どのイメージにどのコンポーネントが含まれているかを把握できれば、影響範囲の特定が速くなります。これは、サプライチェーン攻撃への備えとしても有効です。

フェーズ3｜Deploy段階――ポリシー違反を本番に入れない

デプロイ段階では、「ビルドされたものが改ざんなく本番に届くこと」と、「ポリシーに違反するデプロイを止めること」の両方が重要です。

イメージ署名では、信頼できるCI/CDでビルドされたイメージに署名し、KubernetesのAdmission Controlで署名検証を強制します。これにより、未承認のイメージや改ざんされたイメージが本番に入ることを防げます。

Policy as Codeでは、「本番ではprivilegedコンテナを禁止する」「S3バケットのパブリックアクセスを禁止する」「特定のラベルがないリソースをデプロイさせない」といった組織共通のポリシーをコードとして定義します。CI/CDとAdmission Controlに自動適用することで、人手によるレビューに依存せず、一貫性と監査可能性を確保できます。

この段階で重要なのは、コード上のポリシーと実環境の状態に差分がないかを継続的に確認することです。IaCスキャンとCSPMを連携させることで、コードに書かれた理想状態とクラウド上の実際の状態の乖離を検出できます。

フェーズ4｜Runtime・Operate段階――検知・対応・証跡保全を設計する

デプロイ後のコンテナを守るのが、ランタイムセキュリティです。シフトレフトで防ぎきれなかったゼロデイ脆弱性、コンテナドリフト、ラテラルムーブメント、C&C（Command and Control）通信などは、本番稼働中の挙動を監視して初めて検知できます。

運用設計の観点では、検知から対応までの流れを明確にする必要があります。Falcoのようなランタイム検知エンジンで不審なシステムコールを検知し、必要に応じてプロセス停止、ネットワーク遮断、隔離、フォレンジック取得へつなげます。

コンテナは短命であり、破棄されると攻撃の痕跡が失われることがあります。そのため、インシデント発生時に証跡を自動的に保全し、後から調査できる仕組みが重要です。これは、MTTRの最小化を担うSREにとっても重要な責務です。

AIエージェント時代のDevSecOps運用

LLMやAIエージェントがCI/CDパイプラインやKubernetes運用に組み込まれるようになると、DevSecOpsの運用設計にも新たな観点が必要になります。

従来のRunbookやSOARによる自動化は、あらかじめ定義された手順を実行する決定論的な仕組みでした。一方、LLMやAIエージェントは確率的に判断し、状況に応じて異なるツールを呼び出します。プロンプトインジェクションによって意図しない判断をする可能性もあります。

そのため、AIエージェントは「常に侵害され得る制御ロジック」として扱う必要があります。運用設計の基本は、判断補助はAIに任せ、実行は人間または検証済みRunbookが担うことです。

AIには、ログやアラートの相関分析、優先度の提案、影響範囲の整理、修復案の提示を担わせます。一方で、インフラへの影響が大きい操作、権限変更、ネットワーク遮断、本番反映などには、人間の承認ステップを設けます。

また、AIの入出力、参照データ、ツール呼び出し、判断根拠、承認履歴を追跡できるようにすることも重要です。AIエージェントは、もはや単なる補助ツールではなく、SREが監視すべきシステム構成要素の一部です。

DevSecOpsを組織に根付かせるための実践ステップ

DevSecOpsはツールの問題ではなく、文化と設計の問題です。導入したものの機能していない組織では、次の4ステップで立て直すことが有効です。

ステップ1：目標とKPIを定義する

まず、DevSecOpsで何を改善したいのかを明確にします。MTTRの短縮、デプロイ前のCritical脆弱性削減、コンプライアンス対応の自動化、ランタイムインシデント対応の高速化など、目標によって優先すべき施策は変わります。

KPIの例としては、次のようなものがあります。

• セキュリティアラート解消までの平均時間
• イメージスキャンで検出されるCritical・High件数の月次推移
• Runtime In-Use脆弱性の72時間以内対応率
• Runtime In-Use脆弱性の平均対応時間
• セキュリティインシデントによるサービス停止時間

特に、72h SLA遵守率は、DevSecOpsが実運用に根付いているかを測る重要な指標です。

ステップ2：自動化を起点にする

手動のセキュリティチェックはスケールしません。チームが大きくなるほど、手動レビューだけでは見落としや対応遅れが増えます。

優先して自動化すべきなのは、CI/CDのセキュリティゲート、Admission Control、チケット起票、SLAタイマー、証跡取得、一次トリアージなどです。これにより、人間は本当に判断が必要なリスクに集中できます。

ただし、自動化への過信は禁物です。インフラへの影響が大きい操作には、Human-in-the-loopを設ける必要があります。

ステップ3：IDPにセキュリティを組み込む

IDP、つまりInternal Developer Platformは、開発者が安全かつ高速にビルド・デプロイするためのセルフサービス基盤です。DevSecOpsを根付かせるには、セキュリティを「強制」するのではなく、開発者が自然に使える形で提供することが重要です。

具体的には、次のようなゴールデンパスを整備します。

• セキュリティゲートを組み込んだCI/CDテンプレート
• 承認済みベースイメージのカタログ
• ポリシー準拠のTerraformやHelmチャート
• 開発者向けのセキュリティダッシュボード
• PR画面から確認できる脆弱性とSLA残時間

開発者がデフォルトで安全な選択肢を取れる状態を作ることで、「スキャンがうるさい」という摩擦を減らしながら、セキュリティを開発フローに組み込めます。

ステップ4：フィードバックループを作る

DevSecOpsは、一度設計したら終わりではありません。Build・Test段階のシフトレフトと、Runtime・Operate段階のランタイム対応をつなぎ、継続的に改善する必要があります。

ランタイムで得た知見は、シフトレフトに戻します。本番で実際に使われているパッケージをもとに、スキャン結果の優先度を調整すれば、実行されていない脆弱性への対応工数を削減できます。

インシデントのポストモーテムも、ポリシーや検知ルールに反映します。「どうすれば防げたか」をルール化し、CI/CDやAdmission Control、Falcoルールに組み込むことで、同じ失敗の再発を防ぎます。

KPIも定期的にレビューします。72h SLA遵守率、平均対応時間、アラート件数、誤検知率などを振り返り、運用の成熟度を継続的に高めます。

SysdigによるDevSecOpsの実践

Sysdig Secureは、OSS Falcoを核としたCNAPPプラットフォームとして、DevSecOpsの各フェーズを支援します。本記事の文脈で重要なのは、個別機能ではなく、それらをRACI、72h SLA、フィードバックループに接続できる点です。

開発前のシフトレフトでは、GitHub Actions、GitLab CI、Jenkinsなどと連携し、SBOMスキャン、IaCチェック、イメージスキャンをCI/CDに組み込めます。

デプロイ段階では、Admission Controlによるポリシーベースのデプロイ制御や、IaCスキャンとCSPMの一元管理により、コード上の設定と実環境の状態の乖離を検出できます。

ランタイム段階では、Falcoによるシステムコール監視、eBPFベースの検知、Drift Control、SCAPフォレンジックなどにより、本番環境で発生する不審な挙動を検知・調査できます。

また、Runtime Insightsにより、本番で実際に稼働しているパッケージをもとに脆弱性の優先度を判断できます。これにより、72h SLAの対象を「本当に対応すべきCritical」に絞り込み、開発・運用チームの負荷を抑えながらリスクを低減できます。

AIエージェント対応の観点では、Sysdig MCPサーバーがリアルタイムの脅威検知データやランタイムコンテキストへのアクセスを提供します。Sysdig Sage™は、インシデントのトリアージ、根本原因分析、修復提案をAIで支援し、SREやDevSecOpsチームの対応負荷を軽減します。

Sysdigを活用することで、シフトレフト、デプロイ制御、ランタイム検知、フォレンジック、AI支援を個別機能としてではなく、DevSecOpsの運用設計に接続できます。

まとめ｜DevSecOpsは「ツール」ではなく「運用設計」

DevSecOpsとは、セキュリティをセキュリティチームのサイロから解放し、Dev・Sec・Opsすべての関係者が連帯責任を持つための運用設計です。

本記事のポイントを整理します。

• DevSecOpsは、シフトレフトからランタイム対応までをひとつにつなぐ運用設計である
• SREは、セキュリティインシデントをサービス信頼性の問題として捉える必要がある
• RACIは「誰が対応するか」を明確にし、SLAは「いつまでに対応するか」を明確にする
• Critical×Runtime In-Useを72時間以内に対応する72h SLAは、現実的な優先度設計の中核になる
• IDPにセキュリティを組み込むことで、開発者の摩擦を減らしながらDevSecOpsを根付かせられる
• AIエージェント時代には、「判断補助はAI、実行は人間または検証済みRunbook」という境界線が重要になる

次のアクションとして、まずは自社のDevSecOpsパイプラインを棚卸しし、どのフェーズが手薄かを確認してください。特に、「本番で実行中のCritical脆弱性に72h SLAを適用できているか」は、SREが最初に確認すべき重要なチェックポイントです。

関連記事

• コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像
• CNAPPとは何か？クラウドネイティブ時代に求められるセキュリティの新常識
• シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド
• コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み
• MCP時代のAIエージェントをどう守るか——SRE / DevSecOpsのための設計・脅威モデル・実装指針
• SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法
• CDR（Cloud Detection and Response）とは｜クラウドを守るリアルタイム防御とSysdigのアプローチ