Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
「セキュリティは開発が終わってから確認するもの」——そんな時代は終わりました。コンテナ環境では、一つのイメージが数百・数千のポッドに展開されるため、本番稼働後に脆弱性を修正するコストは開発時の数十倍にも膨れ上がります。CI/CDによる高頻度デプロイが当たり前になった今、「検知してから直す」という後手の対応はもはや機能しません。
本記事では、Shift Leftの定義から、CI/CDパイプラインへの具体的な組み込み方、よくある落とし穴と解決策、そしてSysdigによる実践まで、DevSecOpsエンジニアとSREが今すぐ使える知識を体系的に解説します。コンテナセキュリティの全体像については「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」をあわせてご参照ください。
シフトレフト（Shift Left）とは何か
「左にずらす」の意味
Shift Leftとは、ソフトウェア開発ライフサイクル（SDLC）を「設計・開発（左）→ テスト・ビルド → デプロイ → 本番運用（右）」という時系列で捉えたとき、セキュリティチェックをできるだけ左側——つまり早い段階——に移動させるアプローチです。
従来のウォーターフォール型開発では、セキュリティ検査はリリース直前のフェーズで行われることが多く、発見された問題の修正コストが高くなりがちでした。Shift Leftはこの構造を変え、コードを書く段階・ビルドする段階・PRをレビューする段階それぞれにセキュリティゲートを組み込むことで、問題を発見・修正するコストを根本から下げます。
なお、Shift Leftと対になる概念が「Shield Right」です。Shield Rightはコンテナが実際に稼働しているランタイム段階での防御を指します。両者は競合するものではなく、「Shift Leftで未然に防ぎ、Shield Rightで侵害を即時検知・封じ込める」という役割分担で、コンテナセキュリティの全体を支えます。
なぜコンテナ時代にShift Leftが重要なのか
コンテナ環境でShift Leftが特に重要な理由は、脆弱性の「爆発半径（Blast Radius）」がVMとは比較にならないほど大きいからです。VMでは一台のサーバーが侵害されても被害は局所的ですが、コンテナでは同一イメージから生成された数百・数千のポッドが一斉に影響を受けます。ビルド時に一つの脆弱なイメージが通過してしまえば、それが本番全体に広がります。
さらに、CI/CDによる高頻度デプロイ（1日に数十回のデプロイも珍しくない）は、「本番稼働後に気づいて修正する」サイクルをほぼ不可能にしています。Sysdigの555ベンチマーク（5秒以内の検知、5分以内のトリアージ、5分以内の対応）は、業界でも極めて高速な対応指標です。しかしそれでも、コンテナへの侵害が数秒〜数十秒で完結してしまう攻撃に対しては、「検知してから対応する」というアプローチ自体が根本的な解決策にはなりません。ランタイムで検知できても、その瞬間にはすでに認証情報が奪われていたり、横断侵害が始まっていたりするケースが現実に存在します。だからこそ、「そもそも脆弱なイメージやリスクのある設定を本番環境に持ち込まない」というShift Leftが第一の防波堤となります。ランタイムセキュリティ（Shield Right）はその後の検知・封じ込めを担う第二の防衛線であり、両者が揃って初めてコンテナセキュリティは完成します。
シフトレフトで防げる脅威・防げない脅威
Shift Leftはコンテナセキュリティの万能薬ではありません。何を防げて、何を防げないかを理解することが、Shield Rightとの正しい役割分担につながります。
シフトレフトで防げるもの
- コンテナイメージに混入した既知のCVE：ビルド時スキャンで発見し、本番展開前にブロック
- IaCの設定ミス：S3バケットの意図しない公開・過剰なIAMロール・Kubernetes RBAC不備をデプロイ前に検出
- CI/CD環境への認証情報の混入：GitHubリポジトリへのAPIキー・シークレットの誤コミットを自動検出
- OSSライブラリのサプライチェーンリスク：依存ライブラリへのバックドア混入や既知の悪意あるパッケージの検出
シフトレフトだけでは防げないもの（シールドライトとの役割分担）
一方で、以下のリスクはビルド時スキャンでは対応できません。
- コンテナ稼働中に発生するランタイム攻撃（不審なプロセス起動・異常な通信）
- デプロイ後に公開されたゼロデイ脆弱性の悪用
- AIエージェントのプロンプトインジェクションや実行時の権限昇格
- io_uringなどのシステムコール回避攻撃（Syscall Evasion）
CI/CDパイプラインへのセキュリティ組み込み：4つのステージ
Shift Leftは「一度設定すれば終わり」ではありません。開発フローの各ステージに継続的なセキュリティゲートを分散して配置することが重要です。コミット時・PR時・ビルド時・デプロイ時——それぞれの段階で異なる種類の検査を組み込むことで、問題を最も早い段階で、最も低いコストで検出できます。
ステージ１｜コード・依存ライブラリのスキャン（SCA）
SCA（Software Composition Analysis）は、アプリケーションが依存するOSSライブラリの脆弱性・ライセンスリスクを自動検出する手法です。開発者がコードをコミットした瞬間、またはPRを作成した段階で自動的にスキャンが走り、問題のある依存関係を即座にフィードバックします。
SCAと合わせて重要なのが、SBOM（Software Bill of Materials：ソフトウェア部品表）の生成です。SBOMは「このコンテナイメージに何が含まれているか」を一覧化したものであり、新しい脆弱性が発見された際に影響範囲を即座に特定できます。
特にAIワークロードでは、LangChainやTransformersといったOSSフレームワークへの依存度が高く、これらのライブラリに混入した脆弱性が本番AIインフラに直接持ち込まれるリスクがあります。AIライブラリを含むSBOM管理の詳細については「AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点」をご参照ください。
ステージ２｜コンテナイメージスキャンと継続的なレジストリ監視
コンテナイメージのビルド後、デプロイ前に既知のCVEスキャンを実行することはShift Leftの基本です。しかし、ここで見落とされがちな重要な視点が2つあります。
一つ目は「スキャン結果のノイズ問題」です。コンテナスキャンを実施すると、数百〜数千件の脆弱性が検出されるのは珍しくありません。しかし、その大部分はイメージ内に存在はするものの、実際にはランタイムで実行されていないライブラリに関するものです。すべてを修正しようとすれば開発チームが疲弊し、本当に危険な脆弱性を見逃すリスクが生じます。Sysdig Runtime Insightsを活用することで、実際に稼働中のパッケージのみに絞り込み、脆弱性アラートを最大98%削減できます。
二つ目は「レジストリへの継続スキャン」です。CI/CDパイプライン通過時点ではクリーンだったイメージも、レジストリに保管されている間に新たな脆弱性（ゼロデイを含む）が公開されることがあります。ビルド時だけでなく、レジストリ内の全イメージを継続的にスキャンし、Admission Control（Kubernetesへのデプロイ時に脆弱なイメージをブロックするポリシー）と連携させることで、「古いイメージが知らぬ間に本番で動き続ける」リスクを防ぎます。
アラートノイズの削減と優先度設計の詳細については「SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法」をご参照ください。
ステージ３｜IaCセキュリティとPolicy as Code（PaC）
Infrastructure as Code（IaC）は、TerraformやCloudFormation・Kubernetes ManifestでインフラをコードとしてGit管理する手法です。IaCのセキュリティスキャンは、クラウドリソースが実際にデプロイされる前に設定ミスを検出できる点で、Shift Leftの中でも特に費用対効果が高い対策です。
代表的なIaCリスクとして、S3バケットの意図しない公開設定・セキュリティグループの過剰許可・Kubernetes Namespace間の権限分離不足・Dockerfileでのroot実行などが挙げられます。PRレビュー時にIaCスキャン結果を自動コメントとして投稿するワークフローを組み込むことで、開発者は自分のコードレビューの流れの中でセキュリティ指摘を受け取れます。
さらに一歩進んだアプローチが「Policy as Code（PaC）」です。PaCとは、組織共通のセキュリティ基準——「本番環境ではprivilegedコンテナを禁止する」「すべてのS3バケットはパブリックアクセスをブロックする」といったルール——をコードとして定義し、CI/CDパイプラインに自動適用する考え方です。人間が手動でレビューするのではなく、ポリシー自体がコードとして管理され、すべての環境に一貫して適用されます。Sysdig Secureでは、IaCスキャンとクラウド上の実際の設定状態（CSPM）を一元管理することで、「コードに書いたポリシー」と「実際に動いている状態」の乖離を継続的に検出できます。
ステージ④｜シークレット管理とサプライチェーン保護
APIキーや認証情報がGitHubリポジトリやCI/CD設定ファイルに誤ってコミットされるリスクは、クラウド環境侵害の主要な入口の一つです。特にAIワークロードでは、LLM APIへのアクセスキーが環境変数にベタ書きされるケースが多く、LLMjackingの主要な侵入経路となります。
シークレットスキャンツールをCI/CDに組み込み、コミット前・PR前の段階で認証情報の混入を自動検出することが有効です。さらに、AWS Secrets ManagerやHashiCorp Vaultなどの外部シークレット管理ツールとの連携により、シークレットをコード・設定ファイルから完全に切り離す設計が推奨されます。
サプライチェーン保護の観点では、コンテナイメージへの署名と検証も重要です。信頼できるパイプラインでビルドされたイメージのみを本番にデプロイするための信頼チェーンを確立することで、悪意あるイメージの混入を防ぎます。
よくある落とし穴と対処法
Shift Leftの導入を試みた多くの組織が、ツールを入れただけでは機能しないという壁に直面します。実運用でよく見られる3つの落とし穴と解決策を整理します。
落とし穴1：「スキャンはしているが誰も直さない」問題
セキュリティチームがスキャンツールを導入して脆弱性を報告するものの、実際の修正は開発チーム任せになり、何も解決されないまま積み上がっていくパターンです。根本原因は「誰が・いつまでに・何を直すか」というSLAと役割分担が明確でないことにあります。
解決策は3つです。第一に、ランタイム情報を活用した優先度フィルタリング——実際に稼働中のパッケージに絞り込み、修正すべき件数を現実的な数に削減すること。第二に、脆弱性の深刻度に応じたSLA設定（例：CriticalかつIn-useは72時間以内に対応）。第三に、修正方法を自動提案するツールの活用です。Sysdig Sage™は検出された脆弱性に対してAIが優先順位と具体的な修正手順を提示し、開発チームが「何をすればいいかわからない」という状況を解消します。
落とし穴 2：「本番直前にのみスキャンしている」問題
CI/CDパイプラインの最終ステージ（デプロイ直前）だけにセキュリティゲートを置いているケースです。この設計では、問題が発見されるのがリリースギリギリのタイミングとなり、修正のために開発サイクル全体が止まります。開発チームからは「セキュリティがリリースの邪魔をする」という不満が生まれ、ゲートを形骸化させる圧力につながります。
解決策は、セキュリティゲートを各ステージに分散配置することです。コミット時（シークレットスキャン）・PR時（SCA・IaCスキャン）・ビルド時（イメージスキャン）・デプロイ時（Admission Control）という形で、各段階で検出できる問題を早期に処理することで、最終ゲートへの負荷を大幅に下げられます。
落とし穴3：「開発者の手を止めてしまう」問題
Shift Leftが失敗する最大の原因のひとつが、セキュリティツールが開発者のワークフローを中断させてしまうことです。開発者が使い慣れたGitHubのPR画面やIDEとは別のセキュリティダッシュボードを開かなければ結果を確認できない設計では、セキュリティが「別の仕事」になってしまいます。
開発者体験（Developer Experience）を損なわないShift Leftの鍵は、結果を開発者が普段いる場所に届けることです。具体的には、PRに対してセキュリティスキャン結果を自動コメントとして投稿する・IDEプラグインでコーディング中にリアルタイムフィードバックを提供する・修正方法をコード提案の形で表示する——といったアプローチが有効です。Sysdigは開発者が手を止めずにセキュリティを担保できるよう、GitHub Actions・GitLab CI・Jenkinsへのネイティブ統合と、開発者向けフィードバックの自動化を提供しています。
Sysdigによるシフトレフトの実践
Sysdig Secureは、OSS Falcoを核としたCNAPPプラットフォームとして、Shift Leftに必要な機能をCI/CDに深く統合する形で提供しています。
CI/CDへのネイティブ統合
GitHub Actions・GitLab CI・Jenkinsへのネイティブ統合により、既存のパイプラインにSysdigのスキャン機能をプラグイン形式で追加できます。新しいツールを覚えることなく、開発者が普段使っている環境の中でセキュリティゲートが機能します。
Runtime Insightsをビルド時スキャンにフィードバック
Sysdigの最大の差別化点の一つは、ランタイムの情報をShift Leftにフィードバックできる点です。本番環境で「実際に動いているパッケージ」の情報をイメージスキャン結果と掛け合わせることで、脆弱性の優先度を飛躍的に精度よく設定できます。「Critical件数1,000件」が「対応必須10〜20件」に絞り込まれることで、開発チームは具体的なアクションを取れるようになります。
IaCスキャンとCSPMの一元管理
Sysdig SecureはIaCスキャン（コードの段階の設定ミス検知）とCSPM（クラウド上の実際の状態の継続監視）を一つのCNAPPプラットフォームで管理します。コードから実行環境まで一貫したポリシー適用（Policy as Code)を実現し、設計時と運用時のセキュリティギャップや設定ドリフトを継続的に可視化・検出します。Sysdig Sage™による修正提案の自動化
Sysdig Sage™は、検出された脆弱性・設定ミス・ポリシー違反に対して、AIが優先順位の根拠と具体的な修正手順を自動提示します。「何から直すべきか」「どう直せばいいか」という2つの問いに同時に答えることで、セキュリティ担当と開発担当の間のコミュニケーションコストを大幅に削減します。
まとめ｜Shift LeftはDevSecOpsの「出発点」
Shift Leftとは、セキュリティを開発プロセスの「最後の関門」から「各ステージに組み込まれた継続的な仕組み」へと変える考え方です。4つのステージを整理すると以下のようになります。
- ステージ1：SCA・SBOM——依存ライブラリとOSSリスクをコミット・PR段階で検出
- ステージ2：イメージスキャン＋継続的レジストリ監視——ビルド時とレジストリ保管中の両方をカバー
- ステージ3：IaCセキュリティ＋Policy as Code——設定ミスをデプロイ前に検出し、組織ポリシーを自動適用
- ステージ4：シークレット管理・イメージ署名——認証情報漏洩とサプライチェーン汚染を防ぐ
ただし、Shift Leftはコンテナセキュリティの「出発点」であり、それだけでは不十分です。ゼロデイ脆弱性・ランタイム攻撃・AIエージェントの異常動作といったリスクには、Shield Right（ランタイムセキュリティ）との組み合わせが必要です。
まず今日できるアクションとして、自社のCI/CDパイプラインの各ステージにセキュリティゲートが存在するかを棚卸しすることをお勧めします。どのステージが手薄かを把握することが、Shift Left導入の最初の一歩です。
関連記事
- コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像
- AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点
- SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法
- コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み（近日公開）
- DevSecOpsとコンテナセキュリティ｜SREが知っておくべき運用設計の考え方（近日公開）