コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み

コンテナイメージのスキャン、IaCのセキュリティチェック、CI/CDへのセキュリティゲート。これらのシフトレフトによる対策をすべて実施していても、防ぎきれない脅威があります。コンテナが実際に稼働している「ランタイム」の瞬間に発生する攻撃です。

Teslaのクラウド環境がKubernetes侵害を受けた事例が示すように、攻撃者は必ずしもアプリケーションコードのゼロデイだけを狙うわけではありません。設定ミスのあるコンテナインフラ、露出した認証情報、不十分なランタイム制御を連鎖的に悪用し、侵害を拡大させるケースがあります。ワークロードは正常に稼働しているように見えても、その内部で何が起きているかを把握できていなければ、攻撃に気づくことは困難です。

本記事では、コンテナランタイムセキュリティの本質、OSSのFalcoがリアルタイム検知を実現する仕組み、最新の回避攻撃であるSyscall Evasionへの対応、そしてSysdig SecureによるFalcoの商用拡張まで、技術的に深掘りして解説します。コンテナセキュリティの全体像については、「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」もあわせてご参照ください。

コンテナランタイムセキュリティとは何か

「ランタイム」とはコンテナが稼働している瞬間のこと

コンテナのライフサイクルは、「ビルド → デプロイ → 稼働（ランタイム）→ 停止・破棄」という流れで進みます。シフトレフトが主に対象とするのは、ビルドやデプロイの段階です。

一方、コンテナランタイムの観点では、runC、containerd、CRI-OといったOCI（Open Container Initiative）準拠のランタイムが、Linuxのcgroupsとnamespaceを活用し、各コンテナにプロセス、ネットワーク、ファイルシステムの分離を提供しています。ただし、すべてのコンテナはホストOSのカーネルを共有しているため、カーネルレベルの脆弱性が悪用されれば、その分離が突破される可能性があります。

ランタイムセキュリティとは、この「コンテナが動いている瞬間」に発生する異常挙動をリアルタイムに検知し、必要に応じて封じ込めにつなげる仕組みです。たとえば、不審なプロセス起動、異常なファイルアクセス、想定外のネットワーク通信、権限昇格の試みなどが対象になります。

OSSのFalcoは、こうした異常挙動の検知を担う代表的なツールです。一方、検知をトリガーにした自動封じ込めや、脆弱性管理との連携、フォレンジックなどは、Sysdig Secureのような商用プラットフォームが補完する領域です。

なぜシフトレフトだけでは防げないのか

ビルド時スキャンが生成するCVEリストには、イメージ内に存在していても、実際にはメモリにロードされず、実行もされないライブラリに関する検出結果が多数含まれます。従来の脆弱性管理では、すべてのCVEを同じように扱うため、SREやDevSecOpsチームに膨大な対応コストが発生していました。

さらに、ビルド時点でクリーンだったイメージであっても、稼働中には次のようなリスクが発生します。

• レジストリ保管中に新たなゼロデイ脆弱性が公開される
• 攻撃者がコンテナ侵入後、悪意あるバイナリやツールをダウンロード・実行する
• KubernetesのService Accountを悪用し、クラスタ内で横断侵害を行う
• AIエージェントがプロンプトインジェクションにより、意図しない操作を実行する

Sysdigが提唱する555ベンチマーク、すなわち「5秒以内の検知、5分以内のトリアージ、5分以内の対応」は、クラウドセキュリティにおける非常に重要な指標です。しかし、攻撃が数秒で完結するケースでは、「検知してから人間が対応する」というアプローチだけでは間に合わないことがあります。ランタイムで検知した時点で、すでに認証情報が窃取されていたり、横断侵害が始まっていたりするケースも現実に存在します。

ここで重要なのは、「検知が無意味」なのではなく、「検知だけでは不十分」だという点です。攻撃が数秒で進行する以上、現在のランタイムセキュリティには、検知と同時に自動で封じ込める仕組みが求められます。

Falcoによるリアルタイム検知を起点にしながら、Sysdig SecureのDrift Controlやプロセス強制終了などの自動応答を組み合わせることで、数秒で完結する攻撃にも対抗しやすくなります。つまり、シフトレフトは第一の防波堤であり、ランタイムセキュリティは稼働中の攻撃を検知・封じ込める第二の防衛線です。両者を組み合わせて初めて、コンテナセキュリティは実効性を持ちます。

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

システムコール監視がランタイムセキュリティの核心

システムコールとは何か

プロセスがOSカーネルに対して行う操作要求を「システムコール（Syscall）」と呼びます。ファイルの読み書き、ネットワーク通信の確立、新しいプロセスの起動、メモリの確保など、コンテナ内部で発生する多くの挙動は、最終的にシステムコールとして表れます。

アプリケーションログやネットワークメタデータは、攻撃の「結果」を示す情報です。一方、システムコールを監視すれば、攻撃者が実際に行った「行為そのもの」をカーネルレベルでリアルタイムに捕捉できます。これが、コンテナランタイムセキュリティにおいてシステムコール監視が重要視される理由です。

システムコール回避攻撃——「見えない」攻撃の台頭

従来のランタイムセキュリティツールは、システムコールの監視を前提として設計されてきました。しかし近年、この前提を突く「Syscall Evasion（システムコール回避攻撃）」が注目されています。

代表的な手法が、io_uringの悪用です。io_uringはLinuxカーネルに組み込まれた非同期I/O機構で、本来はディスクやネットワーク操作を高速化するために設計されました。しかし攻撃者は、io_uringを通じて従来のシステムコール監視フックをバイパスし、ファイルアクセスやネットワーク通信を「見えない」形で実行できることを実証しています。

2025年4月、セキュリティ企業ARMOが、io_uringだけで動作するPoCルートキット「Curing」を公開しました。検証では、syscallフックに強く依存する複数のランタイム検知ツールが、その挙動を捉えられないことが示されています。Falcoはデフォルトルールだけでなくカスタムルールを用いた場合でもio_uring経由の操作を検知できず、Tetragonも標準設定では検知できませんでした（Kprobesやeログフックを手動で設定すれば検知は可能です）。Microsoft Defenderも各種の悪意ある操作を検知できなかった一方、検知できた製品も存在し、すべてのツールが回避されたわけではありません。

重要なのは、これがあくまで限定条件下のPoCであり、各ベンダーがその後すぐに対応を進めている点です。FalcoはLSMフック（KRSI：Kernel Runtime Security Instrumentation）をeBPFで利用する仕組みを追加し、io_uring経由のファイル・ネットワーク操作を観測できるよう機能拡張を進めました。Sysdig Secureでも、io_uringの不審な利用を検知する専用ルールが提供されています。この一件は、「syscall監視だけに依存しない、多層的な検知設計が必要だ」という教訓を浮き彫りにしました。

その他の主な回避手法としては、次のようなものがあります。

• Direct Syscall / libcバイパス：標準Cライブラリを経由せず、カーネルに直接Syscallを発行することで、libcフックベースの監視を回避する
• vDSOハイジャック：カーネルがユーザー空間にマップする仮想動的共有オブジェクトを悪用し、Syscall監視を欺く
• Living-off-the-land（LotL）：curl・wget・bash・pythonといったOS標準のツールを悪用し、攻撃用バイナリを新たに持ち込まずに既存ツールだけで目的を達成することで、ドリフト検知やバイナリベースの検知を回避する

これからのランタイムセキュリティでは、「標準的な監視では見えない攻撃が存在する」ことを前提に、カーネルレベルで深い可視性を持つツールを選択することが重要です。

AIワークロード環境におけるSyscall Evasionリスクについては、「AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点」でも解説しています。

Falcoとは何か——OSSランタイムセキュリティの業界標準

FalcoがCNCFで果たす役割

Falcoは、CNCF（Cloud Native Computing Foundation）がホストするオープンソースのランタイムセキュリティプロジェクトです。元々Sysdigが開発し、2018年にCNCFへ寄贈されました。現在は、Kubernetesなどと同じくCNCFの最上位ステージである「Graduated」プロジェクトに認定されており、コンテナランタイムセキュリティ領域におけるOSSの事実上の標準として広く使われています。

関連するお知らせ：Cloud Native Computing Foundation（CNCF）がFalcoを「卒業」プロジェクトに認定

Falcoの核心は、Linuxのシステムコールをリアルタイムで監視し、定義済みのルール（Falco Rules）に基づいて異常な挙動を即座に検知する点にあります。クラウドプロバイダーが提供するログベースの監視や、サンプリングされたメトリクスとは異なり、Falcoはカーネルレベルで発生する挙動を高い粒度で可視化します。

Falcoのルールエンジンの仕組み

Falco Rulesは、YAML形式で記述されるルールセットです。主に「condition（検知条件）」と「output（アラート出力）」で構成されます。conditionでは、コンテナ内のプロセス、ファイル、ネットワークに関するシステムコールのフィルタリング条件を定義し、条件に合致した場合にoutputで指定した形式のアラートを出力します。

代表的なFalcoルールの例は次のとおりです。

• コンテナ内でbashやshが起動された
  正規のアプリケーションコンテナではシェルが起動しないため、攻撃者によるインタラクティブシェル取得の試みとして検知する
• 想定外のIPアドレスへのアウトバウンド通信
  既知のエンドポイント以外に通信を確立した場合、C&Cサーバーへの接続として検知する
• privilegedコンテナからホストファイルシステムへアクセスした
  コンテナエスケープの試みとして検知する
• 本番コンテナで新規バイナリがダウンロード・実行された
  コンテナドリフトとして検知する

Falco Rulesはカスタマイズ可能です。たとえば、特定のコンテナが定期的に外部APIを呼び出すなど、環境固有の正常な挙動をホワイトリスト化することで、ノイズを削減し、検知精度を高めることができます。

OSS版Falcoが抱える現実的な課題

Falcoはランタイムセキュリティの標準ツールとして非常に強力ですが、組織規模で運用する場合には、いくつかの現実的な課題があります。

• YAML管理の複雑化
  コンテナ数やサービス数が増えるほど、ルールのメンテナンス工数が増大し、誤検知のチューニングに多くの時間がかかる
• io_uringへの対応遅延
  最新のSyscall Evasion攻撃手法に対して、OSS版のルールやドライバー更新が後手に回るケースがある
• アラートのノイズ問題
  デフォルトルールのままでは多数のアラートが発生し、SREチームがアラート疲れに陥る可能性がある
• 自動応答機能の欠如
  不審な挙動を検知しても、自動でコンテナを隔離したり、プロセスを停止したりする機能は標準では提供されておらず、別途実装が必要になる

SREチームがOSS版Falcoだけで大規模な本番環境を運用するには、相応のエンジニアリング工数と、Falcoルールに関する深い知識が必要です。

eBPFがランタイムセキュリティを変えた理由

eBPFとは何か

eBPF（extended Berkeley Packet Filter）は、Linuxカーネル内で安全にプログラムを実行できる仕組みです。カーネルのソースコードを変更したり、危険なカーネルモジュールをロードしたりすることなく、システムコール、ネットワークパケット、プロセスの挙動をカーネルレベルでリアルタイムにトレースできます。

従来のカーネルモジュールベースの監視手法と比べ、eBPFには主に3つの利点があります。

第1に、カーネル内で直接動作するため、処理オーバーヘッドを抑えやすい点です。第2に、eBPFプログラムはカーネルにロードされる前に安全性が検証されるため、カーネルクラッシュのリスクを低減できます。第3に、システムコールだけでなく、io_uringのような非同期I/O機構を含む広範なカーネルイベントを観測する土台を提供できる点です。

ただし、eBPFは「使えば自動的にすべての回避攻撃が見える」万能の仕組みではありません。eBPFはあくまでカーネルイベントを取得するための基盤であり、実際にどのイベントを、どの粒度で、どのように取得するかは各ツールの実装に依存します。

そのため、「eBPF採用＝Syscall Evasion対策済み」とは言えません。io_uringのような新しい攻撃面をどこまでカバーできるかは、eBPFドライバーの設計と、継続的なメンテナンスの品質によって決まります。

eBPFによってできること・注意すべき点

eBPFを活用したランタイムセキュリティツールは、次のような可視化を実現します。

• io_uringを含む広範なカーネルイベントの可視化
• コンテナ、プロセス、ネットワークのトレース
• 「どのコンテナの、どのプロセスが、どのファイルにアクセスし、どの通信を行ったか」の把握
• 本番環境への影響を抑えたカーネルレベルの監視

ただし、これらはeBPFを使えば自動的に手に入るものではありません。どこまで深く、正確に可視化できるかは、eBPFドライバーの設計と継続的なメンテナンスに左右されます。

Sysdigは長年にわたりeBPFの実装に投資しており、io_uringなどの最新の回避攻撃にも対応した深いカーネル可視化を提供しています。

ランタイムセキュリティで検知できる主な攻撃パターン

ここでは、実際の本番環境でランタイムセキュリティが検知する代表的な攻撃パターンを整理します。いずれも、シフトレフトだけでは対応しきれないランタイム固有のリスクです。

コンテナドリフト

イミュータブルなコンテナの原則は、「デプロイ後は変更しない」ことです。本番コンテナに本来存在しないはずのバイナリが実行された状態を「コンテナドリフト」と呼びます。典型例は、攻撃者がコンテナに侵入した後、curlやwgetを使って攻撃ツールをダウンロードし、実行するケースです。

コンテナドリフトの検知は、ランタイムセキュリティの基本であり、非常に効果的な機能です。デプロイ時のイメージから逸脱した挙動を即時に検知し、Sysdig SecureのDrift Controlのような自動応答機能と組み合わせることで、不審なバイナリの実行をブロックし、侵害の連鎖を早期に断ち切ることができます。

C&Cサーバーへの不審な通信

コンテナへの侵害後、攻撃者は外部のCommand & Control（C&C）サーバーへの通信チャネルを確立しようとします。正規のアプリケーションが通信するエンドポイントは、ある程度事前に把握できます。そのため、想定外のIPアドレスやドメインへのアウトバウンド通信は、Falcoルールによって検知できます。

権限昇格・横断侵害

privilegedモードで起動したコンテナからのホストファイルシステムへのアクセス、Kubernetes APIへの不審な呼び出し、ServiceAccountトークンを悪用したクラスタ内横断などは、コンテナ侵害後に見られる典型的な攻撃連鎖です。ランタイムセキュリティは、システムコールレベルでこれらの試みを捕捉し、被害が拡大する前にアラートや自動応答につなげます。

AIワークロード特有のランタイムリスク

LLMコンテナ内での異常なAPIコール、想定外のファイルアクセス、AIエージェントによる予期しないバイナリ実行も、システムコールレベルで検知できます。

AIワークロードならではのリスクとしては、次のようなパターンが挙げられます。

• プロンプトインジェクション経由のコード実行
  外部入力に仕込まれた指示により、AIエージェントがcurlやwgetを呼び出し、外部から悪意あるスクリプトを取得・実行してしまうケース。ランタイム上では、想定外のバイナリ起動や未知のエンドポイントへのアウトバウンド通信として現れます。
• LLMjacking
  窃取した認証情報を使い、攻撃者が他者のLLM基盤や高価なGPUインスタンスを不正利用するケース。想定外のモデルAPI呼び出しや課金の急増が検知の手がかりになります。
• モデル・重みファイルの窃取
  本来読み出されないはずのモデルファイルやチェックポイントへの異常なファイルアクセスとして現れます。
• GPU環境特有の挙動
  GPUデバイスへの不審なアクセスや、推論コンテナからの想定外のプロセス起動が該当します。

AIワークロードでは、「正常な推論処理のシステムコールパターン」をベースラインとして定義し、そこからの逸脱を検知する設計が特に有効です。

AIワークロード固有のランタイムリスクの詳細については、「AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点」をご参照ください。

Sysdig Secure：FalcoをCNAPPへと発展させた商用プラットフォーム

Sysdig Secureは、OSS Falcoの開発元であるSysdigが提供する商用プラットフォームです。Falcoのランタイムセキュリティエンジンを中核にしながら、CWPPおよびCNAPPの機能群を統合しています。

ランタイム保護のCNAPPカテゴリであるCWPPの入門解説については、「CWPP（Cloud Workload Protection Platform）とは？」をご参照ください。

OSS版Falcoとの差分は、主に次の5点に整理できます。

1. io_uring対応：Syscall EvasionをカバーするeBPFドライバー

Sysdigは、eBPFドライバーへの深い実装投資により、io_uringを悪用したSyscall Evasion攻撃に対応しています。OSS版Falcoでは検知が難しいケースがある最新の回避手法にも、Sysdig独自のDeep Kernel可視化によって対処します。

eBPFベースのインストルメンテーションにより、システムコール、プロセス、ファイルアクセス、ネットワークアクティビティを、最小限のオーバーヘッドで監視できます。

2. Runtime Insightsによるノイズ削減と脆弱性優先度の精度向上

ランタイムデータの価値は、検知だけにとどまりません。「いま実際にどのコンテナで、どのパッケージが動いているか」という実行時の事実は、ビルド時に積み上がった脆弱性アラートの優先順位付けにも直結します。

Sysdig SecureのRuntime Insightsは、この「検知」と「リスク管理」をつなぐ機能です。なお、Runtime InsightsはFalcoそのものの機能ではなく、Sysdig Secureがランタイムテレメトリを活用して提供する分析機能です。

Runtime Insightsは、本番環境で実際に動いているパッケージ情報と、イメージスキャン結果を掛け合わせます。ディスク上には存在していても、メモリにロードされないライブラリや、到達不能なコードパスに関するCVEの優先度を下げることで、脆弱性アラートのノイズを大幅に削減し、環境によっては98%に達するケースもあります。

これにより、「Criticalが1,000件ある」という状態から、「本当に対応すべき10〜20件」に絞り込みやすくなります。SREチームは、数の多いアラートではなく、実際に悪用される可能性が高いリスクに集中できます。

3. 自動応答：検知から封じ込めまでの時間を短縮

OSS版Falcoは、検知とアラートに特化しています。一方、Sysdig Secureは、検知後の自動応答機能を統合しています。

代表的な機能は次のとおりです。

• Drift Control
  本番コンテナへの不審なバイナリ実行を自動ブロックする
• プロセス強制終了
  C&C通信を確立しようとするプロセスなどを自動停止する
• ネットワーク遮断
  侵害されたコンテナのネットワークアクセスを即座に遮断する
• フォレンジック証跡の自動保全
  コンテナが破棄される前に、SCAPキャプチャでシステムコールレベルの証跡を保存する

数秒で進行する攻撃に対抗するには、検知だけでなく、検知をトリガーにした封じ込めまで自動化することが重要です。

4. Falco Feedsとフォレンジック機能

Sysdig TRT（Threat Research Team）が継続的に分析する最新の脅威インテリジェンスは、Falco Feedsとして自動配信されます。LLMjacking、io_uring悪用、新しいコンテナエスケープ手法に対応したFalcoルールが最新状態に保たれるため、セキュリティチームが個別にルールをメンテナンスする工数を削減できます。

フォレンジック面では、コンテナが破棄された後でも、「いつ、どのプロセスが、何をしたか」を事後的に再現できるSCAPキャプチャ機能が役立ちます。インシデント調査を効率化し、システムコールレベルの証跡から原因を追跡できます。

さらに、ビルド時のSBOM、署名、来歴情報と組み合わせることで、ランタイムの検出結果を特定のイメージ、レイヤー、ソースコンポーネントまで遡って確認できます。

5. Sysdig Sage™によるAI支援

Sysdig Sage™は、検知されたインシデントの深刻度判定、根本原因の特定、対応手順の提案をAIが支援する機能です。

複雑なシステムコールのトレースを手動で解析し続けるのではなく、AIによる分析支援を活用することで、SREやセキュリティチームは重大インシデントへの対応に集中しやすくなります。

Sysdig SecureのCWPP・CNAPP機能の全体像については、「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」のSysdig Secureセクションをご参照ください。また、AWS GuardDutyやGCP Security Command Centerといったクラウド標準ツールだけではランタイム検知が不十分になり得る理由については、「AWS/GCP標準ツールでは守れない？Falcoを超えるSysdig Secureによるセキュリティの新常識」で解説しています。

ランタイムセキュリティの運用設計：SREが押さえるべきポイント

正常な挙動のベースライン定義

効果的なランタイムセキュリティの前提は、「何が正常か」を定義することです。

各コンテナ、各サービスにおける正常なシステムコールパターン、通信先、プロセス起動のプロファイルをあらかじめ把握しておくことで、逸脱を異常として検知しやすくなります。新しいサービスを本番投入する際には、一定のプロファイリング期間を設け、正常な挙動のベースラインを確立することが推奨されます。

アラートレベルの設計とオンコール連携

すべてのFalcoアラートをオンコールに通知すると、SREチームのアラート疲れを招きます。重要なのは、深刻度に応じて通知先と対応方法を分けることです。

たとえば、次のような3段階の設計が考えられます。

• Critical（即時対応）
  コンテナエスケープの試み、権限昇格、C&C通信の確立など。PagerDutyなどで即時ページングする
• Warning（翌営業日対応）
  想定外のネットワーク通信やドリフト検知など。Slackチャンネルへ通知する
• Info（記録のみ）
  正常範囲内の軽微な逸脱。ダッシュボードに記録する

Drift Controlによるバイナリブロックやネットワーク遮断などの自動応答と組み合わせることで、オンコール担当者が対応する前に初動を自動化できます。これにより、MTTRの短縮にもつながります。

なお、検知後のインシデント対応プロセス全体や、72時間以内対応などのSLAを含む運用体制の設計については、「DevSecOpsとコンテナセキュリティ」をご覧ください。アラート設計の詳細については、「SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法」をご参照ください。

Runtime Insightsをシフトレフトにフィードバックする「閉じたループ」

ランタイムセキュリティとシフトレフトは、別々に機能するものではありません。両者をフィードバックループとしてつなぐことで、コンテナセキュリティの実効性が高まります。

本番環境で「実際に動いているパッケージ」の情報をCI/CDパイプラインのイメージスキャンにフィードバックすれば、スキャン結果の優先度精度を高めることができます。

「ビルド時にシグナルを取り、ランタイムで検証し、次のビルドに反映する」。この継続的な信頼のループが、クラウドネイティブ環境におけるコンテナセキュリティを機能させる鍵になります。

このフィードバックループのビルド側、つまりCI/CDパイプラインでの具体的な実装については、「シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド」をご参照ください。

まとめ｜「見えない」を「見える」にすることがランタイムセキュリティの本質

コンテナランタイムセキュリティとは、コンテナが稼働している瞬間に発生する脅威をカーネルレベルで可視化し、リアルタイムに検知し、封じ込めにつなげる仕組みです。

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

• ランタイムセキュリティとは：シフトレフトだけでは防げない、コンテナ稼働中の攻撃をリアルタイムに検知・封じ込める防衛線です。その核心は、システムコール監視にあります。
• Falcoとは：システムコール監視を実現するOSSの事実上の標準であり、CNCFのGraduatedプロジェクトとして、ランタイム検知のエンジンに広く使われています。
• Falcoの限界：OSS版単体では、YAMLルールの管理コスト、アラートノイズ、自動応答の欠如、io_uringのようなSyscall Evasionへの対応遅延といった運用課題が残ります。
• Sysdig Secureによる補完：io_uring対応の深いeBPF実装、Runtime Insightsによる脆弱性アラートノイズの大幅な削減、検知をトリガーにした自動応答、フォレンジック、AI支援を統合し、FalcoをCNAPPレベルの運用へ発展させます。

冒頭で触れたTeslaのKubernetes侵害事例が示すように、ワークロードが「正常に稼働している」ことと、「その中で何が起きているかを把握できている」ことは別です。ビルド時の対策をすり抜け、稼働中のコンテナで攻撃が連鎖した場合、ランタイムの可視化がなければ、攻撃に気づくことすらできません。

「見えないものは守れない」。この原則のもと、システムコールレベルの深い可視化を起点としたランタイムセキュリティの構築が、クラウドネイティブ時代の防御の要になります。

CWPP入門、AWS/GCP標準ツールとの違い、AIワークロードのセキュリティをあわせて読み進めることで、ランタイム検知と封じ込めの全体像をより深く理解できます。

関連記事

• コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像
• シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド
• CWPP（Cloud Workload Protection Platform）とは？クラウドワークロードを守る最新セキュリティ基盤
• AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点
• SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法
• AWS/GCP標準ツールでは守れない？Falcoを超えるSysdig Secureによるセキュリティの新常識
• CDR（Cloud Detection and Response）とは｜クラウドを守るリアルタイム防御とSysdigのアプローチ