私たちはソフトウェアサプライチェーンのセキュリティにおいて着実な進歩を遂げ、ソフトウェアコンポーネントの可視性、真正性、ビルドの完全性を高めてきました。この進歩の多くは大統領令14028号にさかのぼるもので、この命令をきっかけに政府機関や請負業者、企業各社はSBOM、署名、来歴管理への投資を進めてきました。
これらはすべて重要な取り組みですが、それだけでは十分とは言えません。
現在のソフトウェア信頼モデルは、リスクを決定づける肝心の問いにまだ踏み込めていません。それは「このコードは実行された場合、何ができるのか」という問いです。
AIがマルウェアの生成速度や規模、多様性を変えつつある今、この盲点はますます無視できないものになっています。トロント大学の研究チームは、ネットワークを移動しながら攻撃戦略を適応させられるAI駆動型ワームを実証しました。固定された脆弱性を悪用する従来型のワームとは異なり、このプロトタイプは新たな攻撃経路を推論し、システムごとに挙動を調整できます。
2026年6月に発表されたサイバーセキュリティに関するAI大統領令も、こうした連邦政府レベルの懸念を反映しています。しかし問題は政策の範囲にとどまりません。AIが人間によるレビューの速度を上回るペースでコードを生成・改変・展開する現在、従来の信頼モデルはもはや不十分なのです。
私たちはもはや、ソフトウェアの正体や出所、あるいは過去に見たものと似ているかどうかだけを根拠に、ソフトウェアを信頼することはできません。
可視性は信頼ではない
SBOMは重要な問いに答えてくれます。「このソフトウェアの中身は何か」という問いです。
ビルドの中身を把握していなければ、組織は依存関係やオープンソースへの露出、既知の脆弱なコンポーネントを管理することはできません。
しかし、構成要素は挙動そのものではありません。
パッケージの依存関係ツリーがクリーンであっても、危険な動作を行う可能性はあります。アプリケーションが想定通りのライブラリだけで構成されていても、認証情報へのアクセスや永続化、水平展開、ファイルの改変、データの窃取を試みることは十分にあり得るのです。
SBOMはセキュリティチームが構成要素を把握する助けにはなりますが、ソフトウェアが実行時に何をするかまでは予測できません。ここで重要なのが文脈です。ファイル削除はディスククリーンアップツールであれば正当な動作かもしれませんが、オフィス文書のマクロであれば致命的な問題になり得ます。認証情報へのアクセスはパスワードマネージャーでは想定内の動作ですが、パッケージの依存関係の中で行われるなら話は別です。
ここに構成要素ベースの信頼モデルの限界があります。ソフトウェアの中身を知っていても、実行時に何ができるかまでは分からないのです。
真正性は安全性を意味しない
署名と来歴管理は、また別の問いに答えるものです。このソフトウェアの発行者は誰かを検証できるか。出所を確認できるか。ビルドが想定された手順に沿って行われたかを判断できるか、という問いです。
これらの管理策は完全性、説明責任、コンプライアンス、監査可能性を高めてくれます。しかし真正性は信頼性と同じものではありません。
署名されたソフトウェアであっても、悪意ある挙動をする可能性はあります。信頼できるベンダーのアップデートが侵害されることもあります。正当なビルドプロセスであっても、企業ポリシーに反する成果物が生成されることもあります。AIコーディングエージェントが、機能的には正しく動作しながら、意図しないセキュリティ上の問題を招くコードを生成することもあり得ます。
多くのセキュリティプログラムは、ソフトウェアが署名済みであること、承認されたパイプラインを経由していること、既知のリポジトリに由来することをもって、安全だとみなしてしまっています。これは最初のフィルターとしては妥当かもしれませんが、最終的な判断基準とするのは危険です。
こうしたアプローチは、ソフトウェアの変化が緩やかで、悪意あるコードに認識可能な特徴があった時代には理にかなっていました。しかし現在、AIはかつてない速度でコードを生成・改変・展開しています。ソフトウェアの出所を検証するだけでは、それを実行すべきかどうかまでは分からないのです。
欠けている第4の柱
政府のサプライチェーンセキュリティフレームワークは、ソフトウェアの出所、完全性、ビルドプロセスに関する必須の管理策を体系化する上で役立ってきました。しかし、まだ十分に対応できていないのが挙動という観点です。
ソフトウェアサプライチェーンのセキュリティは今や、次の4つの問いに答える必要があります。ソフトウェアの中身は何か。出所は信頼できるか。どのようにビルドされたか。そして、何ができるのか、という問いです。
この4つ目の問いが、セキュリティの成否をますます左右するようになっています。なぜなら、ソフトウェアは実行するユーザー、ワークロード、サービスアカウント、あるいは自動化の実行コンテキストが持つ権限を引き継ぐからです。コードが一度実行されると、データへのアクセス、システムの改変、外部との通信、永続化の確立、セキュリティ制御の無効化、水平展開などが可能になります。
従来型のマルウェア対策では、テレメトリの収集やアラートの生成、封じ込めの実施を通じて、実行が始まった後にこうした判断を下すことが多くありました。これらの機能は今後も必要ですが、AIはタイミングの問題をさらに悪化させています。攻撃者が瞬時に亜種を生成しペイロードを変化させられる今、マルウェアの観測可能な特徴そのものが不安定になっているのです。
認識可能な特徴や既知の指標、実行後のアラートを待ってから信頼性を判断するのでは、もはや手遅れです。
ソフトウェアの正体から挙動へ、評価の軸を移す
次に取るべきステップは、既存のソフトウェアサプライチェーン管理策に挙動検証を加えることです。より強固なモデルでは、可能な限り実行前に挙動を評価します。特にサードパーティ製パッケージ、インストーラー、スクリプト、コンテナ、CI/CDの成果物、AI生成コードといったリスクの高い成果物については、この評価が重要になります。
実務上の問いも「これは見覚えがあるか」から「この挙動は許可されたものか」へと変わるべきです。そのためには、権限昇格や永続化、認証情報へのアクセス、想定外のネットワーク通信といった動作を、文脈に沿って評価する必要があります。
数年前、ゼロトラストはネットワークやデバイス、IDに対する暗黙の信頼を否定することで、セキュリティのあり方を変えました。今、同じ原則をソフトウェアの実行にも適用する必要があります。出所や署名、評判だけを理由に、いかなる成果物も無条件に信頼すべきではありません。
コードにおけるゼロトラストのモデルでは、信頼はサプライチェーンの証跡だけから引き継がれるものではありません。これらの管理策は依然として基盤ではありますが、最終的な実行時の問いには答えてくれないのです。
多くの企業は、5年前と比べればソフトウェアの中身や出所、ビルド方法についてはるかによく把握できるようになっています。むしろ難しいのは、それが実行された際に何ができるのかを見極めることなのです。
翻訳元: https://www.helpnetsecurity.com/2026/07/13/sbom-zero-trust-for-code/
