Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
この記事は、コンテナセキュリティを開発の「ビルド／テスト段階」から強化するための実践ガイドです。CI/CDパイプラインへのセキュリティ組み込み、ビルド時スキャン、IaC／Policy as Code、シークレット管理など、「脆弱性やリスクのある設定を本番に持ち込ませない」ための対策を体系的に解説します。
コンテナが実際に動き出した後の検知・封じ込め、つまりランタイムセキュリティについては「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」で詳しく扱います。また、SLAやアラート設計を含む運用・インシデント対応の考え方は「DevSecOpsとコンテナセキュリティ｜SREが知っておくべき運用設計の考え方」で解説しています。
「セキュリティは開発が終わってから確認するもの」——そうした考え方は、クラウドネイティブな開発環境では通用しにくくなっています。コンテナ環境では、一つのイメージが数百・数千のポッドに展開されることがあります。そのため、本番稼働後に脆弱性が見つかった場合、影響範囲の調査、緊急対応、再デプロイ、関係部門との調整が必要になり、開発時に修正するよりも対応コストが大きくなりがちです。
さらに、CI/CDによる高頻度デプロイが当たり前になった現在、「本番で検知してから直す」という後手の対応だけでは限界があります。必要なのは、脆弱なイメージ、設定ミス、シークレット混入、過剰権限といったリスクを、できるだけ早い段階で発見し、本番環境に持ち込ませない仕組みです。
本記事では、Shift Leftの定義から、CI/CDパイプラインへの具体的な組み込み方、よくある落とし穴と対処法、そしてSysdigによる実践まで、DevSecOpsエンジニアとSREが現場で使える知識を整理します。コンテナセキュリティ全体の考え方については、「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」もあわせてご参照ください。
シフトレフト（Shift Left）とは何か
「左にずらす」の意味
Shift Leftとは、ソフトウェア開発ライフサイクル（SDLC）を「設計・開発（左）→ テスト・ビルド → デプロイ → 本番運用（右）」という時系列で捉えたとき、セキュリティチェックをできるだけ左側、つまり早い段階に移動させるアプローチです。
従来の開発プロセスでは、セキュリティ検査はリリース直前や本番導入前にまとめて実施されることが多く、そこで問題が見つかると修正コストが高くなりがちでした。Shift Leftはこの構造を変え、コードを書く段階、PRをレビューする段階、ビルドする段階、デプロイする段階のそれぞれにセキュリティゲートを組み込むことで、問題を早く見つけ、早く直せる状態を作ります。
Shift Leftと対になる考え方として、本番稼働後の検知・防御を重視する「Shift Right」または「Shield Right」があります。本記事では、コンテナが実際に稼働しているランタイム段階での防御を「Shield Right」と位置づけます。
Shift LeftとShield Rightは競合するものではありません。Shift Leftで本番に持ち込まれるリスクを減らし、Shield Rightで実行時の攻撃や異常挙動を検知・封じ込める。この役割分担によって、コンテナセキュリティ全体の実効性を高めることができます。
なぜコンテナ時代にShift Leftが重要なのか
コンテナ環境でShift Leftが特に重要になる理由は、脆弱性の「爆発半径（Blast Radius）」が大きくなりやすいからです。
仮想マシン（VM）中心の環境では、一台のサーバーに問題があっても、影響範囲は比較的限定されることがありました。一方、コンテナ環境では、同じイメージから生成された多数のコンテナやポッドが一斉に影響を受ける可能性があります。ビルド時に脆弱なイメージが通過してしまえば、そのイメージが本番環境全体に展開されるリスクがあります。
また、CI/CDによる高頻度デプロイでは、リリース後に問題を見つけて手作業で修正する運用は現実的ではありません。デプロイのスピードが上がるほど、セキュリティも同じスピードで組み込まれている必要があります。
そのため、Shift Leftは「本番で攻撃を検知する前段階の防波堤」として重要です。脆弱なイメージ、リスクのある設定、シークレット混入、過剰権限などを事前に減らすことで、ランタイム防御に持ち込まれるリスクの母数を下げる役割を担います。
ただし、Shift Leftは実行時攻撃そのものを検知する仕組みではありません。コンテナ稼働中の不審なプロセス起動、異常通信、システムコール回避、デプロイ後に公開された新たな脆弱性の悪用などには、Shield Right、つまりランタイムセキュリティが必要です。
侵害が数秒で進行する攻撃に対してランタイム検知がなぜ重要なのか、また「5秒以内の検知、5分以内のトリアージ、5分以内の対応」を目指す555ベンチマークの詳細は、「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」で詳しく解説しています。
シフトレフトで防げる脅威・防げない脅威
Shift Leftはコンテナセキュリティの万能薬ではありません。何を防げて、何を防げないのかを理解することが、Shield Rightとの正しい役割分担につながります。
Shift Leftで防げるもの
Shift Leftで主に防げるのは、本番環境に持ち込まれる前に検出できるリスクです。
代表的なものは、コンテナイメージに含まれる既知のCVEです。ビルド時にイメージスキャンを実行し、ポリシーに違反する脆弱性が見つかった場合は、デプロイ前にブロックできます。
IaCの設定ミスもShift Leftの重要な対象です。S3バケットの意図しない公開、過剰なIAMロール、Kubernetes RBACの不備、Dockerfileでのroot実行などは、デプロイ前のコードレビューやCI/CDスキャンで検出できます。
また、GitHubリポジトリやCI/CD設定ファイルにAPIキーやシークレットが誤って含まれるリスクも、コミット時やPR時のスキャンで検出できます。OSSライブラリのサプライチェーンリスクについても、SCAやSBOMによって、脆弱な依存関係や既知の悪意あるパッケージを早期に把握できます。
Shift Leftだけでは防げないもの
一方で、Shift Leftだけでは対応できないリスクもあります。
たとえば、コンテナ稼働中に発生する不審なプロセス起動、異常な外部通信、権限昇格の試行、システムコール回避などは、ビルド時スキャンでは検知できません。これらはランタイム環境で実際に発生する挙動であり、Shield Rightによるリアルタイム検知が必要です。
また、ビルド時点では問題がなかったイメージでも、デプロイ後に新たなCVEが公開されたり、攻撃コードが出回ったりすることがあります。この場合も、レジストリの継続スキャンやランタイム環境での検知・優先度付けが必要になります。
AIエージェントへのプロンプトインジェクションや実行時の権限昇格、io_uringなどを悪用したシステムコール回避攻撃も、実行時の振る舞いを見なければ検知が困難です。こうしたランタイムリスクへの対応は、「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」で詳しく扱っています。
CI/CDパイプラインへのセキュリティ組み込み：4つのステージ
Shift Leftは、「一度スキャンツールを入れれば終わり」という取り組みではありません。コミット時、PR時、ビルド時、デプロイ時のそれぞれに、適切なセキュリティゲートを分散して配置することが重要です。
問題をできるだけ早い段階で検出できれば、修正コストは下がります。逆に、本番直前のゲートだけに依存すると、問題が見つかったときにリリース全体が止まり、開発チームとセキュリティチームの摩擦が大きくなります。
ここでは、CI/CDに組み込むべき代表的な4つのステージを整理します。
ステージ1｜コード・依存ライブラリのスキャン（SCA／SBOM）
SCA（Software Composition Analysis）は、アプリケーションが依存するOSSライブラリの脆弱性やライセンスリスクを自動検出する手法です。開発者がコードをコミットしたタイミング、またはPRを作成した段階でスキャンを実行することで、問題のある依存関係を早期に把握できます。
SCAとあわせて重要なのが、SBOM（Software Bill of Materials：ソフトウェア部品表）の生成です。SBOMは、コンテナイメージやアプリケーションに含まれるコンポーネントを一覧化するもので、新しい脆弱性が公開された際に「どのシステムが影響を受けるのか」を迅速に確認するための基盤になります。
SBOMの作成フォーマット（SPDX／CycloneDX）、VEXを使った優先度設計、サプライチェーン攻撃への備え方については、「SBOMとは？SolarWinds以降のサプライチェーン攻撃にどう備えるか — シフトレフトの中核実装」で詳しく解説しています。
特にAIワークロードでは、LangChainやTransformersなどのOSSフレームワークへの依存度が高くなります。これらのライブラリに脆弱性や不正な依存関係が混入すると、本番AIインフラに直接影響する可能性があります。AIライブラリを含むSBOM管理の詳細は、「AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点」をご覧ください。
ステージ2｜コンテナイメージスキャンと継続的なレジストリ監視
コンテナイメージのビルド後、デプロイ前に既知のCVEスキャンを実行することは、Shift Leftの基本です。TrivyやGrypeなどのスキャナを使い、ベースイメージ、OSパッケージ、アプリケーションライブラリに含まれる脆弱性を検出します。
ただし、コンテナイメージスキャンでは、しばしば数百〜数千件の脆弱性が検出されます。そのすべてを同じ優先度で修正しようとすると、開発チームは疲弊し、本当に危険な脆弱性への対応が後回しになる可能性があります。
ここで重要になるのが、ランタイム情報を使った優先度付けです。イメージ内に存在するパッケージのうち、実際に本番環境で使われているものに絞り込めれば、対応すべき脆弱性を現実的な件数に減らせます。Sysdig Runtime Insightsを活用すると、稼働中のパッケージ情報とスキャン結果を組み合わせ、修正対象の優先度を判断しやすくなります。
もう一つ重要なのが、レジストリへの継続スキャンです。CI/CDパイプライン通過時点では問題がなかったイメージでも、レジストリに保管されている間に新たなCVEが公開されることがあります。そのため、ビルド時だけでなく、レジストリ内のイメージを継続的にスキャンし、最新の脆弱性情報に基づいて再評価する必要があります。
この継続スキャンは、Admission Controlと組み合わせることで「最後の関門」として機能します。
Admission Controlの動作イメージ
- ビルド時にイメージスキャンを実行する
- スキャンを通過したイメージをレジストリに保管する
- 保管中に新たな脆弱性が公開される
- Kubernetesへのデプロイ指示が出る
- Admission Controllerが最新のスキャン結果を確認する
- ポリシー違反があればデプロイをブロックする
この仕組みにより、ビルド時に一度クリーンと判定されたイメージでも、デプロイ直前に最新状態を再評価できます。Kubernetes標準のAdmission ControllerやValidatingWebhookConfigurationを活用することで、既存クラスターにも組み込みやすい点が特徴です。
コンテナイメージスキャンの実装詳細、ベースイメージ戦略、In-Use判定による優先度設計については、「コンテナイメージスキャンとは？数千件の脆弱性を「直すべき数件」に絞る実践ガイド」で詳しく解説しています。アラートノイズ削減と優先度設計については、「SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法」もご参照ください。
ステージ3｜IaCセキュリティとPolicy as Code（PaC）
Infrastructure as Code（IaC）は、Terraform、CloudFormation、Kubernetes Manifestなどを使い、インフラ構成をコードとして管理する手法です。IaCセキュリティは、クラウドリソースやKubernetesリソースが実際に作成される前に、設定ミスを検出できる点で、Shift Leftの中でも特に効果の高い対策です。
代表的なIaCリスクには、S3バケットの意図しない公開、セキュリティグループの過剰許可、Kubernetes Namespace間の権限分離不足、privilegedコンテナの許可、Dockerfileでのroot実行などがあります。これらは、PRレビュー時にIaCスキャンを自動実行し、結果をPRコメントとして返すことで、開発者が通常のレビューの流れの中で確認できます。
さらに一歩進んだアプローチが、Policy as Code（PaC）です。PaCとは、「本番環境ではprivilegedコンテナを禁止する」「すべてのS3バケットでパブリックアクセスをブロックする」「特定のNamespaceでは外部公開を禁止する」といった組織共通のセキュリティ基準をコードとして定義し、CI/CDやKubernetes Admission Controlに自動適用する考え方です。
人間が手動でレビューするだけでは、環境ごとのばらつきや見落としが発生します。ポリシーをコード化し、Gitで管理し、自動適用することで、組織全体に一貫したルールを適用できます。
Sysdig Secureでは、IaCスキャンとクラウド上の実際の設定状態を確認するCSPMを一元管理できます。これにより、「コード上では安全に見える設定」と「実際にクラウド上で動いている状態」の乖離、つまり設定ドリフトを継続的に検出できます。
tfsec、Checkov、TerrascanといったIaCスキャナの使い分け、OPA／Conftest／Kyvernoによるポリシー強制、ドリフト検知の実装パターンについては、「IaCセキュリティとPolicy as Codeとは？コードの段階で構成ミスを止める実装ガイド」で詳しく解説しています。
ステージ4｜シークレット管理・イメージ署名・サプライチェーン保護
APIキーや認証情報がGitHubリポジトリ、Dockerfile、Kubernetes Manifest、CI/CD設定ファイルに誤って含まれるリスクは、クラウド環境侵害の主要な入口の一つです。特にAIワークロードでは、LLM APIキーやクラウド認証情報が環境変数や設定ファイルに直接書かれるケースがあり、LLMjacking（LLM APIを不正に乗っ取り、攻撃者が費用を利用者に負担させる手口）などの不正利用につながる可能性があります。
まず必要なのは、シークレットスキャンをコミット前、PR時、CI/CD実行時に組み込むことです。APIキー、トークン、秘密鍵、クラウド認証情報などがコードに混入していないかを自動検出し、リポジトリに入る前、または本番に近づく前にブロックします。
ただし、シークレットスキャンだけでは不十分です。根本的には、AWS Secrets Manager、HashiCorp Vault、Google Secret Manager、Azure Key Vaultなどの外部シークレット管理基盤を使い、シークレットをコードや設定ファイルから切り離す設計が必要です。
さらに、サプライチェーン保護の観点では、コンテナイメージへの署名と検証も重要です。信頼できるCI/CDパイプラインでビルドされたイメージだけを本番環境にデプロイするために、イメージ署名、署名検証、Admission Controlを組み合わせることで、悪意あるイメージや改ざんされたイメージの混入を防ぎます。
このステージでは、単に「シークレットを検出する」だけではなく、認証情報をコードから分離し、ビルド成果物の信頼性を検証し、デプロイ可能なイメージを制御するところまで含めて設計することが重要です。
よくある落とし穴と対処法
Shift Leftは、ツールを導入するだけでは定着しません。実運用では、スキャン結果が放置されたり、開発者の作業を妨げたり、最終ゲートだけが重くなったりする問題が起こりがちです。
ここでは、Shift Left導入時によくある3つの落とし穴と、その対処法を整理します。
落とし穴1：「スキャンはしているが誰も直さない」
セキュリティチームがスキャンツールを導入し、脆弱性レポートを出しているものの、実際の修正は開発チーム任せになり、対応されないまま積み上がっていくパターンです。
根本原因は、「誰が、いつまでに、何を直すのか」が明確になっていないことです。スキャン結果を出すだけでは、セキュリティは改善されません。修正の優先度、対応期限、責任分担まで設計して初めて、Shift Leftは機能します。
対処法は大きく3つあります。
はじめに、ランタイム情報を使って優先度を絞り込むことです。実際に稼働中のパッケージや外部公開されているワークロードに関係する脆弱性を優先することで、対応すべき件数を現実的な数に削減できます。
次に、深刻度に応じたSLAを設定することです。たとえば「CriticalかつIn-Useの脆弱性は72時間以内に対応する」といったルールを定め、チーム間で合意しておく必要があります。72時間SLAを軸とした運用設計や責任分担の詳細は、「DevSecOpsとコンテナセキュリティ｜SREが知っておくべき運用設計の考え方」で扱います。
最後に、修正方法を開発者に分かりやすく提示することです。開発者が負担に感じるのは、「脆弱性を指摘されること」だけではありません。「どう直せばよいかを調べる時間」が大きな負担になります。Sysdig Sage™は、検出された脆弱性や設定ミスに対して、優先順位の根拠に加え、Dockerfileの修正案、依存ライブラリのアップデートコマンド、IaCテンプレートの修正例などを提示します。これにより、開発者は「何から直すべきか」「どう直せばよいか」を把握しやすくなります。
落とし穴2：「本番直前にのみスキャンしている」
CI/CDパイプラインの最終ステージ、つまりデプロイ直前だけにセキュリティゲートを置いているケースです。
この設計では、問題が見つかるのがリリース直前になります。修正にはコード変更、再ビルド、再テスト、再レビューが必要になるため、リリース全体が止まりやすくなります。その結果、開発チームからは「セキュリティがリリースの邪魔をしている」と見なされ、ゲートを回避したり、形骸化させたりする圧力が生まれます。
対処法は、セキュリティゲートを各ステージに分散配置することです。前述の4つのステージ（コミット・PR・ビルド・デプロイ）それぞれに適切なゲートを置き、問題を早期に処理することで、最終ゲートへの負荷集中を防げます。
落とし穴3：「開発者の手を止めてしまう」
Shift Leftが失敗する大きな原因の一つが、セキュリティツールが開発者のワークフローを中断させてしまうことです。
開発者が使い慣れたGitHubのPR画面やIDEとは別に、セキュリティ専用のダッシュボードを開かなければ結果を確認できない設計では、セキュリティ対応が「別の仕事」になってしまいます。これでは、Shift Leftは現場に定着しません。
開発者体験（Developer Experience）を損なわないためには、セキュリティ結果を開発者が普段いる場所に届けることが重要です。具体的には、PRにスキャン結果を自動コメントする、IDEプラグインでコーディング中にフィードバックする、修正方法をコード提案として提示する、といったアプローチが有効です。
Sysdigは、GitHub Actions、GitLab CI、JenkinsなどのCI/CD環境と連携し、既存の開発ワークフローにセキュリティチェックを組み込みやすくします。開発者が別の画面に移動しなくても、普段の作業の中でセキュリティ指摘を確認できるようにすることが、Shift Left定着の鍵になります。
Sysdigによるシフトレフトの実践
Sysdig Secureは、コンテナ、Kubernetes、クラウド環境を対象とするCNAPPプラットフォームとして、Shift Leftに必要な機能をCI/CDやクラウド環境と連携させて提供します。ここでは、Shift Leftの文脈で特に重要なポイントを整理します。
CI/CDへの統合
Sysdig Secureは、GitHub Actions、GitLab CI、JenkinsなどのCI/CD環境に統合できます。既存のパイプラインにスキャン機能を組み込むことで、開発者が普段使っているワークフローの中で、イメージスキャンやセキュリティゲートを実行できます。
新しい運用フローを別途作るのではなく、既存のCI/CDにセキュリティを組み込むことで、開発スピードを保ちながらリスクを減らすことができます。
Runtime Insightsをビルド時スキャンにフィードバック
Sysdigの特徴の一つは、ランタイムの情報をShift Leftにフィードバックできる点です。
一般的なイメージスキャンでは、イメージ内に存在する脆弱性が一覧で表示されます。しかし、その中には実際には本番環境で使われていないパッケージも含まれます。すべてを同じ優先度で扱うと、アラートが増えすぎ、開発チームが対応しきれなくなります。
Sysdig Runtime Insightsは、本番環境で実際に稼働しているパッケージやワークロードの情報をスキャン結果と組み合わせることで、優先的に対応すべき脆弱性を絞り込みます。これにより、「検出件数は多いが、どれから直すべきか分からない」という状態から、「まず対応すべき脆弱性が分かる」状態へ移行できます。
Runtime Insightsの検知エンジン側の仕組みや、eBPF、Falco、ノイズ削減の考え方については、「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」で詳しく解説しています。
IaCスキャンとCSPMの一元管理
Sysdig Secureでは、IaCスキャンとCSPMを一元的に管理できます。
IaCスキャンは、TerraformやKubernetes Manifestなど、コードとして管理されている設定の問題をデプロイ前に検出します。一方、CSPMはクラウド上で実際に動いているリソースの設定状態を継続的に監視します。
この2つを組み合わせることで、コード段階での設定ミスだけでなく、デプロイ後に発生した設定ドリフトも把握できます。たとえば、IaC上では安全な設定になっていても、クラウドコンソール上で手動変更が加えられた場合、その差分を検出し、修正につなげることができます。
Shift Leftを実践するうえでは、コードの段階で止めることに加え、実際のクラウド環境と乖離していないかを継続的に確認することが重要です。
Sysdig Sage™による修正提案の自動化
Sysdig Sage™は、検出された脆弱性、設定ミス、ポリシー違反に対して、優先順位の根拠や具体的な修正案を提示するAIアシスタントです。
たとえば、Dockerfileの修正案、依存ライブラリのアップデートコマンド、IaCテンプレートの修正例などを提示することで、開発者が「何を直すべきか」「どう直せばよいか」を判断しやすくします。
Shift Leftの現場では、セキュリティチームが問題を検出しても、開発チームがすぐに修正できなければ改善は進みません。Sysdig Sage™は、検出から修正までの距離を縮め、セキュリティ担当と開発担当のコミュニケーションコストを下げる支援をします。
まとめ｜Shift LeftはDevSecOpsの起点
Shift Leftとは、セキュリティを開発プロセスの「最後の関門」から、「各ステージに組み込まれた継続的な仕組み」へと変える考え方です。
本記事で整理した4つのステージは次のとおりです。
ただし、Shift Leftはコンテナセキュリティの起点であり、それだけで十分ではありません。ビルド後・デプロイ後に新たに判明した脆弱性、ランタイム攻撃、AIエージェントの異常動作などには、Shield Right、つまりランタイムセキュリティとの組み合わせが必要です。
実行時検知の詳細は「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」、SLAと運用設計の詳細は「DevSecOpsとコンテナセキュリティ｜SREが知っておくべき運用設計の考え方」で詳しく解説しています。
まず今日できるアクションとして、自社のCI/CDパイプラインを「コミット／PR／ビルド／デプロイ」の4段階に分け、それぞれにSCA、SBOM、イメージスキャン、IaCスキャン、シークレット検出、Admission Controlのどれが組み込まれているかを棚卸ししてみてください。
どのステージが手薄かを把握することが、Shift Left導入の最初の一歩です。