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

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

DevSecOpsとは、セキュリティをセキュリティチームだけに任せるのではなく、開発・運用・セキュリティのすべてのステークホルダーが連帯責任を持つアプローチです。しかしコンテナ・Kubernetes・そしてAIエージェントが当たり前になった今、DevSecOpsが求める役割分担と設計原則は新たな次元に入りつつあります。

本記事では、DevSecOpsの定義からSREが担うべき役割、4フェーズのパイプライン設計、AIエージェント時代の新しい設計原則、そして組織への定着ステップまでを体系的に解説します。コンテナセキュリティの全体像については「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」をあわせてご参照ください。

‍

DevSecOpsとは何か——DevOpsとの違い

DevOpsにセキュリティを統合したアプローチ

DevOpsは、開発（Dev）と運用（Ops）の統合により継続的デリバリーを実現するアプローチです。ソフトウェアの計画・コーディング・ビルド・テスト・デプロイ・管理を「継続的なループ」として設計し、開発者とIT運用エンジニアがソフトウェアデリバリ全体のオーナーシップを持つことを促します。

‍

しかしDevOps単体ではセキュリティには及びません。2000年代後半にDevOpsの哲学が登場した際、それは開発と運用の統合だけに焦点を当てていました。DevSecOpsはこれを発展させ、セキュリティ（Sec）をソフトウェアデリバリの各段階に統合します。コーディングの瞬間から始まり、テスト・ステージング・デプロイ・管理の各プロセスを通じてセキュリティの評価と最適化を継続する——これがDevSecOpsの中核にある考え方です。

‍

最も重要なのは「セキュリティを後付けでボルトオンしない」という設計思想です。アプリケーションが完成した後にセキュリティレビューを行う従来モデルでは、問題の発見が遅くなるほど修正コストが膨れ上がり、リリース直前の手戻りがチーム全体を疲弊させます。DevSecOpsはこの構造を根本から変え、セキュリティをすべてのステークホルダーの「連帯責任」にすることで、より少ない工数でより優れたセキュリティ成果を実現します。

コンテナ時代にDevSecOpsが特に重要な理由

コンテナ環境でDevSecOpsが特に重要になる理由は、脆弱性の「爆発半径（Blast Radius）」がVMとは比較にならないほど大きいからです。一つのコンテナイメージが数百・数千のポッドに展開されるため、脆弱なイメージが本番に混入した瞬間、被害は瞬時に全環境に広がります。

さらに深刻なのが「ソフトウェア・サプライチェーン攻撃」のリスクです。SolarWinds・Log4j・xzバックドアといった事例が示すように、攻撃者は今やベースイメージ・OSSライブラリ・CI/CDパイプライン自体を標的にします。汚染されたベースイメージが一度レジストリに取り込まれれば、それを使うすべての環境に悪意あるコードが伝播します。この「上流での汚染が下流全体に波及する」リスクへの対処が、DevSecOpsとSBOM管理の必要性を高めています。

加えて、CI/CDによる高頻度デプロイ（1日に数十回も珍しくない）は「後でセキュリティを確認する」アプローチを破綻させます。KubernetesのRBAC・IAM・ネットワークポリシーは、Devだけでも、Secだけでも管理しきれません。コンテナのライフサイクル全体を横断するDevSecOpsの設計こそが、この複雑さに対応できる唯一のアプローチです。

コンテナを狙う具体的な攻撃手法については「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」をご参照ください。

‍

SREが担うDevSecOpsの役割

SREとセキュリティの交差点

従来のSREは可用性・信頼性・MTTRの最小化を主軸としてきました。しかし現代のクラウドネイティブ環境では、サービス停止の主要因の一つがセキュリティインシデントになりつつあります。ランサムウェアによるシステム停止・認証情報の窃取によるAPIサービスの乗っ取り・コンテナへの侵害による計算リソースの無断使用——これらはすべてSLO違反を引き起こします。

‍

「セキュリティインシデントはサービス停止インシデントである」という認識への転換が、現代のSREには求められています。Sysdigが提唱する555ベンチマーク——「5秒以内の検知・5分以内の理解（コンテキスト把握）・5分以内の対応（ブロック・隔離）」——が示すように、セキュリティ対応のスピードはSREのオンコール対応と一体化しつつあります。MTTRの最小化を担うSREが、ランタイムセキュリティの第一応答者になることは、もはや自然な流れです。

Dev・Sec・Opsの役割分担と共有責任モデル

DevSecOpsを機能させるためには、各ロールが担う責任範囲を明確にしつつ、ツールとダッシュボードを共有することが重要です。「誰が何を担うか」よりも「誰が何を見ているか」を揃えることが、コラボレーションの実質的な起点になります。

• 開発者（Dev）：コードレビュー時のSCA・IaCチェック・シークレット管理・PRへのセキュリティスキャン結果の確認と修正対応
• セキュリティ担当（Sec）：セキュリティポリシーの策定・ツール選定・Falcoルールの設計・インシデント対応の主導・コンプライアンス管理
• SRE・運用（Ops）：ランタイム監視・アラートのトリアージと対応・フォレンジック調査・MTTRの最小化・自動応答フローの設計と維持

重要なのは、これらが「サイロ」ではなく「連帯」であることです。セキュリティ担当が脆弱性を報告するだけで修正はDev任せ・SREはランタイムアラートに忙殺されてSecに相談できない——こうした分断が「誰もボールを持っていない脆弱性」を生み出します。共通のダッシュボード・共有されたSLA・明文化された役割分担が、この分断を解消します。

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

多くの組織でDevSecOpsが機能しない根本原因は、「誰がボールを持っているかが不明なまま脆弱性が放置される」問題にあります。スキャンツールがCritical脆弱性を検出しても、SecはDevに報告し、DevはSREに確認し、SREは「本番に影響がなければSecの判断で」と言う——このキャッチボールが続く間に、本当に危険なリスクが積み上がっていきます。

RACIマトリクスはこの問題への直接的な解決策です。例えば脆弱性対応のRACIを以下のように設計します。

• Responsible（実行責任）：修正コードを書くDev
• Accountable（説明責任）：優先度を判定し最終決定するSRE・テックリード
• Consulted（相談先）：修正方針を提言するSec
• Informed（報告先）：対応状況を把握するプロダクトオーナー・マネジメント層

深刻度に応じたSLAも合わせて定義します。例えば「Critical かつ Runtime In-useは72時間以内、Criticalのみは1週間以内、Highは次スプリント内」という基準があることで、開発チームは「何をいつまでに直すべきか」を自律的に判断できるようになります。

DevSecOpsパイプラインの設計：4つのフェーズ

DevSecOpsは「ツールを入れれば機能する」ものではありません。各フェーズに明確な責任とプロセスを設計することで初めて機能します。コンテナのライフサイクルを「Plan・Code → Build・Test → Deploy → Runtime・Operate」の4フェーズに分け、それぞれに適切なセキュリティゲートを配置します。

フェーズ1｜Plan・Code段階——設計時のセキュリティ

セキュリティは最も早い段階、すなわち設計・コーディング時に組み込むほど修正コストが低くなります。このフェーズで重要なのは3点です。

はじめに「脅威モデリング」です。「このサービスはインターネットに公開されるか」「どの種類のデータを扱うか」「最小権限の原則に従ったIAM設計は何か」——これらを設計段階で定義することで、後フェーズでの手戻りを最小化します。

次に「開発者体験の設計」です。IDEプラグインによるリアルタイムフィードバック・セキュアなコードスニペットの提供・承認済みのベースイメージリスト——開発者がデフォルトでセキュアな選択肢を取れる環境を整えることが、DevSecOpsを文化として根付かせる第一歩です。

最後に「セキュリティ教育の継続的な提供」です。DevSecOpsはツールだけでは実現できません。開発者がSQLインジェクションやシークレット管理のリスクを理解していなければ、スキャンツールのアラートも「うるさいだけ」になります。

フェーズ2｜Build・Test段階——シフトレフトの実践

ビルド・テスト段階はシフトレフトの主戦場です。CI/CDパイプラインの各ポイントに以下のセキュリティゲートを組み込みます。

• SAST（静的解析）：ソースコード・バイナリの脆弱性・欠陥をデプロイ前に検出
• SCA（ソフトウェアコンポジション解析）：OSSライブラリの脆弱性・ライセンスリスクを自動検出。SBOM（Software Bill of Materials）を生成し、依存関係を可視化
• DAST（動的テスト）：稼働中のアプリケーションに対してセキュリティテストを実行し、静的解析では見逃した脆弱性を検出
• IAST（インタラクティブテスト）：SASTとDASTを組み合わせ、実行中のコードを分析しながら脆弱性の根本原因まで遡って特定

特にSBOMは、SolarWindsやLog4jのようなサプライチェーン攻撃への対処において中心的な役割を果たします。「このコンテナイメージに何が含まれているか」を常に把握していることが、新たな脆弱性が公開された際の影響範囲の即時特定を可能にします。

CI/CDへのセキュリティゲート組み込みの詳細については「シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド」をご参照ください。

フェーズ3｜Deploy段階——イメージ署名とPolicy as Code

デプロイ段階のDevSecOpsでは「ビルドされたものが改ざんなく本番に届く」ことの保証と、「ポリシーに違反するデプロイをブロックする」仕組みの両立が重要です。

‍

まず「イメージ署名（Image Signing）と検証」です。信頼できるCI/CDパイプラインでビルドされたコンテナイメージを暗号的に署名し、Admission Control（KubernetesへのデプロイゲートであるAdmission Webhook）で署名検証を強制します。「誰がいつどのようにビルドしたか」の来歴（Provenance）を暗号学的に証明することで、悪意あるイメージや改ざんされたイメージのデプロイを防ぎます。

‍

次に「Policy as Code（PaC）」です。「本番環境ではprivilegedコンテナを禁止する」「すべてのS3バケットはパブリックアクセスをブロックする」といった組織共通のセキュリティポリシーをコードとして定義し、CI/CDとAdmission Controlに自動適用します。人間の手動レビューに依存せず、ポリシーをコードとして管理・バージョン管理することで、一貫性と監査可能性が確保されます。

‍

Sysdig SecureはIaCスキャン（コードの段階での設定ミス検知）とCSPM（クラウド上の実際の状態の継続監視）を一元管理することで、「コードに書いたポリシー」と「実際に動いている状態」の乖離を継続的に検出します。

フェーズ４｜Runtime・Operate段階——Shield Rightの実践

デプロイ後、コンテナが稼働している瞬間（ランタイム）を守るのがShield Rightです。シフトレフトで防ぎきれなかったゼロデイ脆弱性・コンテナドリフト・ラテラルムーブメント・C&C通信——これらはすべてランタイムで初めて検知できます。

‍

Falcoによるシステムコール監視がランタイムセキュリティの核心です。「コンテナ内でbashが起動された」「想定外のIPへのアウトバウンド通信が発生した」「privilegedコンテナからホストファイルシステムへのアクセスがあった」——これらをリアルタイムに検知し、自動応答（Drift Control・プロセス強制終了・ネットワーク遮断）と組み合わせることで、555ベンチマークの「5分以内の対応」を実現します。

‍

コンテナは短命であり、破棄されると攻撃の痕跡が消えます。SysdigのSCAPキャプチャによるフォレンジック機能は「コンテナが消えた後」もシステムコールレベルの証跡を保全し、インシデント調査を「数時間から数分」に短縮します。

‍

ランタイムセキュリティの技術的詳細については「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」をご参照ください。

AIエージェント時代のDevSecOps——新しい設計原則

LLMやAIエージェントがCI/CDパイプラインやKubernetes運用に組み込まれる時代、DevSecOpsの設計原則は新たな次元に入りつつあります。従来の「決定論的な自動化」とは根本的に異なるリスクが生まれているからです。

AIエージェントが生む「非決定論的な自動化」の問題

従来のRunbookやSOARによる自動化は、入力と結果の対応関係を明示的に定義でき、設計上は決定論的な挙動に寄せることが可能でした。これに対してLLMは本質的に確率的であり、文脈に依存して振る舞います。同じ入力でも状況に応じて異なるツールを呼び出し、プロンプトインジェクションによって制御ロジックが歪められることがあります。

‍

さらに深刻なのが「権限昇格のリスク」です。AIエージェントが「効率化のために」RBACを書き換えたり、必要以上の権限を自律的に取得しようとするケースが実証されています。「正しく設計したはずの自動化」が状況次第で異なる挙動を示す可能性は、SREにとって無視できない性質の変化です。AIエージェントは「信頼できる制御ロジック」ではなく「常に侵害され得る制御ロジック」として扱う必要があります。

MCP（Model Context Protocol）が広げる攻撃面

Anthropicが提唱したMCP（Model Context Protocol）は、LLMが外部リソース（ファイル・データベース・クラウドAPI）に直接アクセスするための標準化アプローチです。MCPの普及により、AIエージェントは1つのプロンプトを起点として複数のツールを連鎖的に実行し、その実行パスは実行時の推論によって決定されます。

‍

この設計は権限の「爆発半径」を大幅に拡張します。人間が事前にすべての分岐をレビューできずに想定外の組み合わせで操作が実行され、影響範囲を完全に把握することが難しくなります。また、AIエージェントのコンテキストにはユーザー入力・外部ドキュメント・ログ・メタデータといった必ずしも信頼できない情報が混入するため、プロンプトインジェクション攻撃による制御ロジックの歪みが現実的な脅威となります。

‍

MCP時代のAIエージェントへの具体的な対策については「MCP時代のAIエージェントをどう守るか——SRE / DevSecOpsのための設計・脅威モデル・実装指針」をご参照ください。

AIエージェント時代の4つの設計原則

このリスクに対応するため、SREおよびDevSecOpsは以下の4原則を設計段階から組み込む必要があります。

原則1：認証情報は使い捨てを前提にする

静的なAPIキーや長期間有効な認証情報を前提とした設計は避けます。実行単位で最小権限を付与する短寿命トークンを採用し、自動ローテーションを前提とした設計を行います。LLMに「長く使える鍵」を持たせないことが基本原則です。

原則2：プロンプトを外部インターフェースとして扱う

プロンプトは単なる入力ではなく、外部から制御ロジックに影響を与えるインターフェースです。プロンプトインジェクションを想定内の攻撃ベクトルとして設計し、ツール呼び出しの直前に検証・制限レイヤーを挟みます。LLMの判断をそのまま実行系に流さない構造が重要です。

原則3：コンテキスト分離と最小権限の徹底

テナント・環境・ワークフロー単位でのコンテキスト分離を厳格に行い、RBACをツール実行レベルまで落とし込みます。「便利だから」という理由ですべてのデータや操作権限をエージェントに見せる設計は、事故の起点となります。

原則4：AIエージェントのオブザーバビリティを確保する（Human-in-the-loop）

どのプロンプトが・どのような推論（Chain of Thought）を経て・どのツールを実行したかを常にトレース可能にします。AIの判断を透明化し、インフラへの影響が大きい操作には必ず人間の承認ステップ（Human-in-the-loop）を設けます。AIエージェントをブラックボックスとして扱うのではなく、サーバーやDBと同様にSLOを定め、その健全性を監視すべき「主要なシステム構成要素」として管理します。

AIに「判断補助」を任せ「実行」は人間が持つ境界線

現実的かつ安全なAIエージェントの運用は、役割の分離にあります。AIには膨大なデータを横断した「調査」「相関分析」「優先度提案」を担わせ、実際の「実行」や「修復」は人間またはRunbookを介在させます。

‍

「知能のオブザーバビリティ」——ブラックボックス化しがちなAIの推論プロセスを、従来のメトリクスやログと同様に追跡・制御可能にすること——を実装することが、AI時代のSREの新たな責務です。具体的には、AIの推論の各ステップ（Chain of Thought）がどのコンテキストデータに基づいていたか・どのツールをなぜ呼び出したかをトレース可能にし、判断の根拠を事後的に検証できる仕組みを整えます。

‍

Sysdig MCPサーバーは、AIエージェントにクラウド環境のリアルタイム脅威検知データとランタイムコンテキストへのアクセスを提供します。これにより、例えばSnyk MCPサーバーが提供する「静的なリスクリスト」を、実際の稼働状況に基づいた「どの脆弱性が今インターネットから攻撃可能な状態で動いているか」という動的な知識に昇華させることができます。

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

DevSecOpsはツールの問題ではなく文化と設計の問題です。以下の4ステップは、特に「導入したが機能していない」という組織が立て直す際にも有効な実践ロードマップです。

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

DevSecOpsを採用する理由と「それで何を得たいか」を最初に明確にします。「MTTRの短縮」「デプロイ前のCritical脆弱性ゼロ化」「コンプライアンス対応の自動化」——目標によって優先するツールとプロセスは変わります。

測定可能なKPIの例として以下が挙げられます。

• デプロイからセキュリティアラート解消までの平均時間（MTTR）
• イメージスキャンのCritical・High件数の月次推移
• Runtime In-use脆弱性の対応率と対応スピード
• セキュリティインシデントによるサービス停止時間

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

手動のセキュリティチェックはスケールしません。チームが10名から100名になれば、手動レビューは破綻します。CI/CDへのセキュリティゲート・Admission Control・自動フォレンジックを優先的に自動化し、「人間の判断が必要なもの」にSREとSecの時間を集中させます。

‍

ただし「自動化すれば解決する」という過信も禁物です。AIエージェントの節で述べたとおり、自動化の暴走リスクは常に存在します。自動化できるものは自動化しつつ、インフラへの影響が大きい操作にはHuman-in-the-loopを必ず設けます。

ステップ3：IDPにセキュリティを組み込む（プラットフォームエンジニアリング）

2024〜2026年のエンジニアリング組織のトレンドとして「プラットフォームエンジニアリング」が急速に広まっています。IDP（Internal Developer Platform：内部開発者プラットフォーム）は、開発者が安全にかつ高速にアプリケーションをビルド・デプロイするためのセルフサービス基盤です。

‍

DevSecOpsを機能させる最善の方法の一つは、セキュリティを開発者に「強制」するのではなく、IDPを通じて「利用しやすい形で提供」することです。具体的には以下の「ゴールデンパス」を整備します。

• セキュアなCI/CDテンプレート：セキュリティゲートがあらかじめ組み込まれたパイプラインテンプレートを提供
• 承認済みベースイメージのカタログ：既知のCVEが除去された、組織が署名・管理するベースイメージを一元提供
• 標準化されたIaCモジュール：セキュリティポリシーに準拠したTerraform・Helmチャートのライブラリ
• 開発者向けセキュリティダッシュボード：自分のサービスのセキュリティ状態をPR画面から確認できる統合ビュー

‍

開発者がデフォルトでセキュアな選択肢を取れる環境を整えることで、「スキャンがうるさい」という摩擦をゼロにしつつ、セキュリティを自然に組み込めます。

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

DevSecOpsは一度設計したら終わりではなく、継続的な改善のループを回すことで成熟します。

• ランタイムの知見をシフトレフトに反映：本番で実際に動いているパッケージをSysdig Runtime Insightsでスキャン優先度に活用。「本番で実行されていない脆弱性」への対応工数を削減
• インシデントのポストモーテムをポリシーとFalcoルールに反映：「どうすれば防げたか」をルールとして自動化し、同じ問題の再発を防ぐ
• KPIの定期レビュー：月次・四半期ごとにKPIを振り返り、DevSecOpsの成熟度を継続的に向上させる

‍

Runtime Insightsをシフトレフトへフィードバックする仕組みの詳細は「シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド」をご参照ください。

SysdigによるDevSecOpsの実践

Sysdig SecureはOSS Falcoを核としたCNAPPプラットフォームとして、DevSecOpsの4フェーズすべてをカバーする統合ソリューションを提供しています。

• シフトレフト：GitHub Actions・GitLab CI・Jenkinsへのネイティブ統合。SBOMスキャン・IaCチェック・イメージスキャンをCI/CDに組み込み
• Deploy：Admission ControlによるポリシーベースのデプロイゲートとIaCスキャン×CSPMの一元管理
• Runtime：Falcoによるシステムコール監視・io_uring対応のeBPFドライバー・Drift Control・SCAPフォレンジック
• Runtime→シフトレフトフィードバック：Runtime Insightsにより実際に稼働中のパッケージのみに絞り込み、脆弱性アラートを最大98%削減

‍

AIエージェント対応として、Sysdig MCPサーバーはAIエージェントにリアルタイム脅威検知データとランタイムコンテキストへのアクセスを提供し、「知能のオブザーバビリティ」を実装します。Sysdig Sage™はインシデントのトリアージ・根本原因分析・修復提案をAIがサポートし、SREとDevSecOpsチームの対応負荷を大幅に削減します。

Forrester Wave CNAPP 2026 Q1・Gartner CNAPP Customers' Choice（99%推薦率）への選出が示すように、SysdigはDevSecOpsの全体像をカバーするプラットフォームとして、NTT（8,000 API・RAFTELプロジェクト）・Goldman Sachs・IBMをはじめとするグローバル企業に採用されています。

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

DevSecOpsとは、セキュリティをセキュリティチームのサイロから解放し、Dev・Sec・Opsすべてのステークホルダーの連帯責任にする文化と設計の変革です。本記事のポイントを整理します。

• DevSecOpsはDevOpsにセキュリティを統合したアプローチ。「後付けボルトオン」から「各フェーズへの組み込み」への転換が本質
• コンテナ時代の爆発半径とサプライチェーン攻撃が、DevSecOpsの必要性を加速させている
• SREはセキュリティインシデント対応の第一線に立つ存在として、MTTRの最小化とランタイムセキュリティを一体化させる
• AIエージェント時代の4原則（使い捨て認証情報・プロンプトを外部IFとして扱う・最小権限・Human-in-the-loop）が新たな設計標準になる
• IDPへのセキュリティ組み込みが、開発者の摩擦をゼロにしつつDevSecOpsを文化として根付かせる最善策

次のアクションとして、自社のDevSecOpsパイプラインのどのフェーズが手薄かを棚卸しすることから始めることをお勧めします。「Plan・Code → Build・Test → Deploy → Runtime」の4フェーズのうち、セキュリティゲートが存在しないフェーズがあれば、そこが最初に取り組むべき優先課題です。

関連記事

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

‍