クラウドネイティブ環境を守るには、迅速な対応が不可欠です。
クラウドセキュリティが人間のスケールの限界に達しつつあることについては、私たちはこれまでも繰り返し指摘してきました。2026年初頭には、明らかな変化が起きました。React2Shellのような攻撃が、脆弱性の公開からわずか数時間後に発生するようになったのです。しかもこれは孤立した事例ではありませんでした。Sysdig Threat Research Team（TRT）は、AIインフラツールを標的とした複数の脆弱性でも同様のパターンを確認しています。それだけでなく、攻撃はより自動化が進み、端から端まで完全にAI主導になりつつあります。私たちはAI支援攻撃がわずか8分で管理者権限を獲得した事例や、認証情報がわずか3分で窃取された事例を確認しています。Sysdig TRTはまた、JADEPUFFERについても報告しています。これは、破壊的なデータベース恐喝プレイブックを自律的に実行する、初のエージェント型ランサムウェア攻撃です。
だからこそ、セーフティネットとしてランタイムセキュリティの重要性がますます高まっているのです。迅速な自動対応を実現するには、質の高いランタイム検知が欠かせません。
ステートフル検知がノイズを削減
セキュリティチームは、時間内に対応できず苦戦することが少なくありません。大量の課題に埋もれ、誤検知のトリアージや個々のセキュリティイベントの調査に多くの時間を費やしているのが実情です。
従来の検知エンジンは、セキュリティイベントを単独で捉える傾向にあります。例えば、コンテナ上でターミナルシェルが開かれるとフラグを立てますが、それが開発者によるアプリのデバッグなのか、悪意ある攻撃者によるものなのかを判断するコンテキストは持ち合わせていません。その調査は結局、他のアラートを確認して何が起きたかを追跡できるセキュリティエンジニアに委ねられることになります。
ステートフル検知は、この状況を根本から変えます。
- 単一の検知が複数のアクションを相関付け、攻撃者が何を行ったかを再構成することで、検知された挙動が悪意あるものである確度を高めます。
- このコンテキストにより、アナリストに届く前の段階で、正当な操作と悪意ある挙動を切り分けられます。
- 結果として、ステートフル検知はトリアージすべきアラート件数を減らします（ノイズ削減）。
- アラートにこれらの相関情報が含まれるため、調査のスピードも向上します。
先ほどの「コンテナ上でシェルを開く」という例で言えば、この行為自体は開発者がワークロードをデバッグする際の日常的な操作である可能性があります。また、/tmpへの書き込みも正当な操作である場合があります。しかし、シェルを開き、バイナリを/tmpにダウンロードし、それを実行するという一連の流れとなると、ほぼ間違いなく攻撃に該当します。
ステートフル検知の仕組み
Sysdigの Falco エージェントにおけるステートフル検知は、次のような形になります。
このルールは、コンテナ内でターミナルシェルが開かれ、それを使ってパッケージマネージャーでソフトウェアがインストールされた場合を検知します。
Observation（観測）は、SysdigがSecureにおいて Falco ルールに追加した拡張機能で、ステートフルな評価を表します。
- macro: spawned_process
condition: (evt.type in (execve) and evt.dir=< and evt.arg.res=0)
- observation: Launch Process
condition: spawned_process
source: syscall次に、2つの観測が関連しているかどうかをどう判定するかを定義します。例えば、両者が同じプロセスIDを持っているかどうかなどです。
- obs_link_fields: same_session
fields:
- [proc.sid, proc.sid]そして、Falco ルール上でobs.occursとobs.linkを使って、これらの観測を利用できます。
- rule: Spawn Package Management Program Below Container Exec
desc: Detect an attempt to run a package management program from a container exec
condition: >-
obs.occurs["Terminal shell in container"]=true and
obs.link["Terminal shell in container-->Spawn Package Management Program, same_session"]=true…ステートフル検知について詳しくは、以下をご覧ください。
ステートフル検知の導入率は高水準
私たちの2026年版クラウドネイティブセキュリティ・利用状況レポートによると、組織の70%がステートフル検知を利用しています。さらに、導入済みの組織では、クラウド環境全体の91%にわたって適用されています。
これほどの導入率は、この新しいパラダイムがノイズ削減と調査の迅速化においていかに画期的であるかを裏付けています。
自動対応に必要な「信頼」
組織は、セキュリティイベントに迅速に対応するうえで自動化が果たす役割を理解しています。しかし、事業運営を壊滅的に中断させかねない自動対応の導入には、まだ十分な自信を持てていません。
私たちの2026年版クラウドネイティブセキュリティ・利用状況レポートによると、組織の75%が各種ポリシーに対して自動対応アクションを設定済みです。しかし、それを実際に有効化している組織はわずか27%にとどまります。
このギャップ自体がリスクになり得ます。エージェント型脅威アクター（ATA）は迅速に行動しており、人間の判断待ちで停止するセキュリティ運用は、攻撃者のスピードに追いつけなくなってしまいます。
ステートフル検知は、組織が必要としているものかもしれません。より質の高いシグナルを提供し、検知精度を高めつつ誤検知を減らせるからです。シグナルへの信頼が生まれれば、対応への信頼も生まれます。実際、自動対応を有効化している27%の組織に目を向けると、有望な未来が見えてきます。
脅威検知アラートを受けてプロセスを強制終了するkill -9コマンドを使用する組織は140%増加しています。コンテナに関しても、一時停止や停止ではなく強制終了を選択する組織の割合が28%増加しています。
これは、こうしたチームの成熟度を示す兆候です。第一に、サービスを完全に停止させることなく、プロセスやコンテナを強制終了できるようになっています。第二に、稼働中の侵害されたコンテナのトラブルシューティングという運用上の利便性よりも、セキュリティを優先するようになっているのです。
結論
ステートフル検知は、ランタイムセキュリティに不可欠なツールになりつつあります。組織がランタイムセキュリティ導入への自信を必要としているまさにこのタイミングで、より質の高い検知を提供してくれるのです。ATAはすでに現実世界で活動しており、人間のペースを前提に構築された防御策では、AI主導の脅威に太刀打ちできません。
