見えない依存関係と、検証できるということ

2020年の SolarWinds、2021年の Log4Shell、2024年の xz-utils バックドア。この三件は「サプライチェーン攻撃」という同じ見出しで括られることが多い。根本原因はそれぞれ違う。同じカテゴリで語ることで、実効性のある対策が見えにくくなっている。

SolarWinds：ビルド環境が標的だった

SolarWinds Orion への攻撃で狙われたのはソースコードではなくビルド環境だった。攻撃者は内部ビルドサーバーに侵入し、ソースは正規のまま、ビルドプロセスで悪意あるコードを注入した。

この構図が厄介なのは、ソースコードレビューでも SBOM の照合でも検出できない点にある。リポジトリ上のコードは正しい。出荷されるバイナリだけが違う。守るべき対象はコードではなくビルドパイプラインの完全性だった、と事後にわかる類の攻撃である。

Log4Shell：攻撃者はいなかった

CVE-2021-44228 は根本的に別物だ。Apache Log4j の JNDI ルックアップ機能に設計上の欠陥があり、ログとして記録される文字列から任意のリモートコード実行が可能だった。侵入者はいない。欠陥は Log4j のコード自体に長年存在していた。

被害が広範だったのは Log4j が Java エコシステムに深く組み込まれていたためである。ここでは SBOM がはっきり効いた。発覚直後、SBOM を運用していた組織と依存関係の手動棚卸しから始めた組織では、対応完了までの時間に桁違いの差が出ている。

xz-utils：信頼そのものを取りに来た

CVE-2024-3094 は三つ目のパターンになる。攻撃者は数年かけて xz プロジェクトのメンテナとして信頼を獲得し、正規のコミット権限を得たうえでバックドアを注入した。「Jia Tan」名義で活動した個人ないし集団は、既存メンテナが疲弊していく過程で徐々に責任を引き継いでいる。

コードレビュー体制でもビルドパイプラインの完全性でも、この攻撃は防げない。SBOM に記録されるのは正規のリリースであり、バックドアはリリース物内部の暗号化された領域に隠されていた。攻撃対象はオープンソースの信頼モデルそのものだった。

対策を一本化すると穴が残る

米国大統領令14028以降、SBOM は連邦調達要件として広まった。既知の脆弱性が発覚したときに自組織のどの製品が依存しているかを高速に判定できる、という価値ははっきりしている。それは Log4Shell 型への対策であって、他の二件にはほとんど効かない。SBOM 万能論は一つの対策を過剰に一般化している。

もうひとつ、依存関係を可視化する仕組みを持つ組織が、脆弱性通知に対応する体制まで持っているとは限らない。GAO の連邦システム調査や Linux Foundation の Core Infrastructure Initiative レポートは、可視化された脆弱性の相当割合が数ヶ月から数年放置されている状況を繰り返し指摘してきた。原因は技術的な難しさではなくリソース配分の優先度で、パッチ適用は新機能を止めることを意味するため事業側から後回しにされる。レガシー刷新で要件凍結が成立しないのと同じ構造だ。プラットフォームチームの責務として明確化しない限り、可視化された問題は可視化されたまま残る。

多層防御を張れば全パターンに対応できる、という反論はある。SLSA や Sigstore による署名インフラは実際、複数の攻撃パターンを同時にカバーする方向で設計されている。ただし問題は実装コストと運用の継続性で、SLSA Level 3 相当のビルド完全性を実装している組織は公開情報からは限定的にしか確認できない。理念と実装状態のあいだにある距離を埋めないまま「多層防御があるから安全」と言うことが、対策の混同を再生産している。少なくとも既知脆弱性への対応時間、ビルドパイプラインの完全性、メンテナの信頼性評価を別々の項目として管理する。出発点はそこになる。