Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年2月25日にTaradutt Pant が投稿したブログ(https://www.sysdig.com/blog/eliminating-runtime-blind-spots-how-cleanstart-and-sysdig-build-continuous-trust-across-the-container-lifecycle)を元に日本語に翻訳・再構成した内容となっております。
コンテナセキュリティのパラドックス
コンテナの導入は、ソフトウェアの構築と提供の方法を変革しました。しかし、そのスピードと柔軟性は同時に攻撃対象領域を劇的に拡大させました。チームが公開レジストリからベースイメージを取得する際、単に機能を継承するだけではありません。そのイメージに組み込まれたあらゆる脆弱性、設定ミス、潜在的なバックドアも引き継ぐのです。
単一の侵害された依存関係が、従来のスキャナーが警告を発するはるか前に、開発、ステージング、本番環境へと静かに伝播する可能性があります。
Tesla の Kubernetes 侵害は、この逆説を明確に示しています。攻撃者はアプリケーションコードのゼロデイを悪用したのではありません。その代わりに、設定ミスのあるコンテナインフラストラクチャ、露出した認証情報、不十分なランタイム制御を悪用してコンピュートリソースを乗っ取りました。ワークロードは稼働していましたが、ランタイムでその悪用を早期に検知するために十分に監視している者はいませんでした。
このパターンは決して珍しいものではありません。
SolarWinds、Log4j、xz バックドアといった著名なインシデントが示しているように、現代のサプライチェーン攻撃はソースコードで止まりません。攻撃者はビルドシステム、CI/CD パイプライン、サードパーティ依存関係、そして稼働中のランタイム環境を同時に標的にします。静的スキャンは昨日のリスクを見つけます。ランタイム専用ツールは異常を検知しますが、それをビルドやサプライチェーンの発生源まで遡って追跡するために必要なコンテキストを欠いていることが少なくありません。
その結果は、見慣れた危険な状態です。
- セキュリティチームが CVE ノイズに圧倒される
- ソフトウェアデリバリーパイプライン全体にわたる断片的な可視性
- 構築、署名、承認されたものが実際に本番環境で安全に実行され、動作していることを証明する検証可能な方法がない
そこで、CleanStartとSysdigのパートナーシップによって方程式が変わります。
ビルド時のハードニング、暗号学的な来歴、およびイメージの信頼性を、深いランタイムインテリジェンスと強制適用と組み合わせることで、CleanStart と Sysdig はコンテナセキュリティにおける最も危険なギャップ、すなわちビルドとランタイムの間にある盲点を解消します。
コンテナライフサイクル全体にわたる攻撃対象領域の理解
現代のコンテナ侵害は、単一の弱点を悪用することはほとんどありません。代わりに、攻撃者はビルドからランタイムに至るコンテナライフサイクルの複数の段階にまたがるギャップを連鎖させます。
コンテナサプライチェーンにおけるビルド時のリスク
リスクは、アプリケーションが実行されるはるか以前から引き継がれていることが多くあります。一般的なビルド時のリスクには、次のようなものがあります。
- 継承された脆弱性：パブリックなベースイメージには、数百の既知のCVEが含まれていることがよくある
- 依存関係の汚染：悪意のある、または侵害されたパッケージがオープンソースエコシステムに導入される
- ビルドシステムの侵害：コードの挿入や改ざんを目的としてCI/CDパイプラインが標的にされる
- トレーサビリティの欠如：ソフトウェアがいつ、どのように、誰によってビルドおよび署名されたのかについての暗号学的証明がない
トレーサビリティがなければ、チームはそのイメージが組織での使用において安全で信頼できるものであるかどうかを確信を持って検証することができません。これは、ソフトウェアサプライチェーンの基盤にある信頼を損ないます。サプライチェーンが好まれる攻撃ベクトルとなっているのは、まさにこの信頼が検証されるのではなく、しばしば前提とされているためです。
ランタイムリスク:悪用可能性が実際に問題となる場合
コンテナが稼働すると、リスクは理論上のリスクから実際の悪用可能性に移ります。攻撃者は次のような実行時リスク要因を悪用する可能性があります。
- 構成ドリフト：承認された強化済みの状態から逸脱するコンテナ
- 権限昇格：過剰な権限や誤設定されたアイデンティティにより悪用が可能になること
- 横方向移動：侵害されたコンテナがワークロード間のピボットに利用されること
- ゼロデイ悪用：パッチ適用前の脆弱性が本番環境で悪用されること
重要なのは、イメージに存在するすべての脆弱性が実際のランタイムリスクを意味するわけではないということです。
従来の脆弱性管理では、すべてのCVEを同等に扱い、チームに何千もの検出結果への対応を強いてきました。その多くは、実際にはロードされることも、実行されることも、到達可能であることもないライブラリに関連しています。その結果、実際には悪用不可能な問題にエンジニアリングの労力が費やされる一方で、本当に危険なリスクは優先順位付けされていないアラートの中に埋もれたままとなります。
ランタイムの現実:使用中の脆弱性は CVE の数よりも重要
ランタイムで重要なのは実行コンテキストですが、その詳細を把握することはしばしば困難です。
チームは以下を特定するのに苦労しています。
- ディスク上には存在するが、メモリにロードされることのないライブラリにおける脆弱性
- 到達不能、または入力にさらされていないコードパスにおけるCVE
- 修復サイクルを消費する低リスクの検出結果
- 本番環境で実際に実行されるもの
ビルドタイムスキャナーだけではこれらの質問に答えることはできません。
ビルドセキュリティとランタイムセキュリティの間のギャップ
ビルド時のセキュリティとランタイムのセキュリティの間の断絶は、危険な盲点を生み出します。
ビルド時のスキャナーは膨大なCVEリストを生成しますが、どのコンポーネントが本番環境で実行されているのかについての洞察は提供しません。ランタイムツールは不審な挙動を検知できる場合がありますが、それを特定のイメージ、ビルドプロセス、またはソースコミットにさかのぼって追跡するためのコンテキストを欠いていることがよくあります。
継続的な信頼の連鎖がなければ：
- セキュリティチームはノイズに溺れる
- エンジニアリングチームは明確な修復の優先順位を失う
- 組織は、ビルドされ、承認され、署名されたものが実際に実行されているものであることを証明できない
ランタイムインテリジェンスが方程式を変える理由
ランタイムインテリジェンスは、この可視性のギャップを埋めます。ランタイムテレメトリを使用中のコンテキストと組み合わせると、チームは次のことを判断できます。
- どの脆弱なライブラリが実際にメモリに読み込まれているか
- どのプロセス、バイナリ、システムコールが実行されるか
- どの脆弱性が実際の攻撃経路にさらされているか
- どのCVEの優先順位を下げても問題ないのか
これにより、組織は最も重要な場所、つまりリスクが高く使用中の脆弱性への修復作業に集中できます。
ランタイムインテリジェンスは、アラートの疲労を軽減し、パッチ適用を迅速化し、脆弱性の未処理ログと本番リスクを軽減します。これにより、ボリュームベースのスキャンから、リスクベースのランタイム主導型の修復への移行が可能になります。
CleanStart:ソース側での信頼の確立
CleanStartはコンテナのセキュリティに第一原則から取り組みます。 清潔な基礎から始めることで、下流のリスクが大幅に軽減されます。 これは、いくつかの重要な機能によって実現されます。
ほぼゼロの CVE ベースイメージ
CleanStart は、リリース時点で既知のCVEフットプリントがほぼゼロの、強化されたコンテナベースイメージを提供します。これは見せかけではなく、アーキテクチャ上の取り組みです。
- 最小限の設計:必要なコンポーネントのみが含まれています
- 継続的な強化:CIS ベンチマークと業界のベストプラクティスの適用
- スキャンと検証済み:リリース前の脆弱性とマルウェアのスキャン
- 安全さを重視した署名: 暗号署名により、改ざんの検証と検出が可能になります
SLSA に準拠したビルドプロビナンス
CleanStart は、密閉的で再現可能なビルドを強制し、暗号学的に署名された来歴を生成することで、Supply-chain Levels for Software Artifacts（SLSA）の原則に準拠しています。
- Hermetic ビルド：同一の入力から決定論的な出力を生成するよう設計された、分離された再現可能なビルド
- 来歴アテステーション：次の事項を文書化する、暗号学的に署名されたメタデータ:
- ソースリポジトリとコミット
- ビルドシステムと構成
- ビルド時に解決される依存関係
- ビルダー ID とタイムスタンプ
- 検証可能な管理チェーン:監査人は、何がビルドされたかだけでなく、どのようにビルドされたかを検証できます
Distroless および最小構成のイメージ
CleanStartは、開発用イメージにデバッグツールと、必須のランタイムコンポーネントのみを対象としたプロダクショングレードのディストロレスイメージを提供します。
シェルはありません。パッケージマネージャーはありません。不要なユーティリティはありません。
カスタムイメージビルド
CleanStart Portalを通じて、チームは次のような社内標準に合わせたイメージをリクエストできます。
- オペレーティングシステムとバージョン
- アプリケーションランタイム (Node.js、Python、Java、Go など)
- アーキテクチャ (x64、ARM64)
- コンプライアンスプロファイル (FIPS、CIS 強化)
必要以上のものでもそれ以下でもありません。
CleanStartとSysdigは緊密に結合されたフィードバックループを形成し、コンテナライフサイクル全体のセキュリティ体制を強化します。
ビルドからランタイムまでのトレーサビリティ
CleanStart は、ソフトウェア部品表（SBOM）、暗号学的な来歴アテステーション、および脆弱性スキャン結果を生成します。Sysdig はこのメタデータを活用して、デプロイされたイメージが検証済みのビルドと一致していることを検証し、ランタイムの検出結果を正確なコンポーネントのバージョンと関連付け、不審な挙動を特定のイメージ、レイヤー、およびソースコンポーネントに帰属させます。
ランタイムからビルドまでのフィードバック
Sysdig のランタイムインサイトは、実際には使用されていないパッケージを特定し、ランタイムで積極的に標的とされている脆弱性を優先し、実環境での挙動に基づいて検知ポリシーを洗練させることで、将来のビルドに反映されます。
検証済みのデプロイゲート
CleanStartとSysdigを組み合わせることで、次のことが可能になります。
- 導入時のアドミッションコントロールによるイメージ署名検証
- デプロイメント前の来歴検証
- リスクベースの脆弱性ゲート
- ポリシーに対する継続的なコンプライアンスチェック
Sysdig：ランタイムにおける脅威の検知、予防、およびフォレンジック
CleanStartはビルド時に信頼を確立しますが、Sysdigはランタイムを詳細に可視化することで信頼を本番環境にも広げています。
SysdigはeBPFベースのインストルメンテーションを使用して、システムコール、プロセス、ファイルアクセス、ネットワークアクティビティを最小限のオーバーヘッドと正確なワークロードアトリビューションで監視します。
Falco は、ランタイムセキュリティのための CNCF 標準であり、予期しないプロセス実行、不審なファイルシステムアクセス、悪意のあるネットワーク接続、権限昇格の試み、およびコンテナエスケープ手法を検知するために、振る舞いベースのルールを適用します。
Sysdig はさらに、使用中のパッケージを悪用可能性、権限、インターネットへの公開状況、およびライブ検知と関連付けることで、実際のランタイム露出に基づいて脆弱性の優先順位付けを行います。ランタイムドリフト検知は、不正なバイナリ、構成の改ざん、暗号通貨マイニング活動、および永続化メカニズムも特定します。
まとめ
コンテナセキュリティは、ビルド時の問題でもランタイムの問題でもありません。その両方です。
CleanStart と Sysdig は連携して、ソースから本番環境に至るまでの継続的な信頼の連鎖を確立します。CleanStart は、イメージがクリーンかつ検証可能な形でビルドされることを保証します。Sysdig は、それらのイメージが本番環境で安全に動作していることを保証し、ランタイムインテリジェンスをより強固なビルドへとフィードバックします。
その成果は、単にセキュリティが向上することではありません。証明可能なセキュリティです。
組織は、自社のソフトウェアがどのようにビルドされ、現在どのように動作しているのかを正確に示すことができます。ソフトウェアサプライチェーン攻撃が加速する時代において、この証明はもはや任意ではありません。
ソースから本番環境までクラウドワークロードを保護する方法について、さらに詳しく知りたいですか？
ホワイトペーパー『Your Cloud Security Strategy is Backward』をダウンロードしてください。