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

あるアプリケーションが依存しているライブラリの一覧を出せるかと問われて、即答できる組織は多くない。直接の依存はわかる。問題は、その依存が依存しているものであり、さらにその先である。この層は普段まったく見えず、事故が起きたときにだけ姿を現す。

二つの事故、二つの様式

2021年12月に公表された Log4Shell（CVE-2021-44228）は、Java のログ出力ライブラリ Log4j に存在した遠隔コード実行の脆弱性である。影響範囲が広かったのは、Log4j が直接依存として意識されないまま、多くの製品に間接的に取り込まれていたためだった。ここでの失敗は、誰かが悪意を持ったことではなく、誰も自分が何に依存しているか知らなかったことにある。

2024年3月に発見された xz-utils のバックドア（CVE-2024-3094）は、様式が異なる。攻撃者は数年にわたって当該プロジェクトに貢献し、メンテナとしての信頼を獲得したうえで、リリース用アーカイブに悪意あるコードを混入させた。ソースコードリポジトリと配布物のあいだに差分が置かれていたため、コードレビューだけでは検知できない構造になっていた。

前者に対しては依存の可視化が効く。後者に対しては効かない。一覧に載っていても、その一覧が正しいという保証は別途要る。

SBOM が制度化された経緯

2021年5月に発令された米国大統領令14028（Improving the Nation’s Cybersecurity）は、連邦政府へソフトウェアを納入する事業者に、部品表の提供を求める方向を示した。これを受けて NTIA が同年7月に「The Minimum Elements For a Software Bill of Materials」を公表し、含めるべき最小限の項目が定義された。

制度としての SBOM は、次の三つを分けて考えると理解しやすい。

• 生成：ビルド時に依存グラフを記録できるか
• 流通：受領側が機械可読な形式で受け取れるか
• 検証：記載内容が実際の配布物と一致していると確認できるか

調達要件が求めているのは、多くの場合ここでいう「流通」までである。生成の粒度と検証の可否は、事業者ごとに大きく開きがある。

誰が保守しているのか

Linux Foundation と Harvard の LISH による「Census II of Free and Open Source Software」は、広く使われている OSS パッケージの実態を調査した。同報告が浮かび上がらせたのは、産業全体が依存している少数のパッケージが、ごく少人数、ときには一人の無償の保守者によって維持されているという構図である。

xz-utils の事例で攻撃者が突いたのは、この構図そのものだった。疲弊した単独メンテナに協力者が現れ、権限が委譲される。この経過は、それ自体としてはオープンソースの正常な動作であり、悪意の識別を極めて難しくする。

反論：一覧は無意味ではない

SBOM は xz-utils 型の攻撃を防がない。ここから「SBOM は形式主義だ」と結論する議論があるが、これは対象を取り違えている。SBOM が答えるのは「新しい脆弱性が公表されたとき、自社の何が影響を受けるか」という問いであり、Log4Shell の対応でもっとも時間を消費したのはまさにその調査だった。

一方で、SBOM が答えない問いに SBOM で答えようとすれば、形式は整い実態は伴わないという結果になる。来歴の検証には SLSA のような枠組みが、署名には Sigstore のような仕組みが、それぞれ別に必要になる。層が違うものを一つの成果物で解こうとしないことが、この領域の設計原則である。

提出から検証へ

調達側の関心は、提出物の有無から、提出物の正確さへ移りつつある。ビルドの再現性、成果物への署名、依存グラフの自動生成。いずれも、開発基盤の側に組み込まれていなければ、事後に用意することが難しい性質を持つ。

この点で、供給網の問題は内製プラットフォームの設計と分かちがたい。誰がどのビルドパイプラインを通ったかを記録できる基盤がなければ、来歴は主張にとどまる。そして基盤の外に置かれた依存は、外部 API という形でも同じ問題を持ち込む。呼び出し先の実装は、部品表には現れない。