なぜSBOMはサプライチェーン攻撃を防げていないのか?

本文の内容は、2026年9月24日にJavier Martínezが投稿したブログ (URL) を元に日本語に翻訳・再構成した内容となっております。

ソフトウェア部品表(SBOM)は、ほとんどのサプライチェーン攻撃を防ぐ可能性を持っています。

SBOMは、ソフトウェアにおける「原材料リスト」のようなものであり、署名やアテステーションとともに、トレーサビリティを可能にします。含まれる情報には、次のようなものがあります。‍

• 誰がそのソフトウェアを作成したか(帰属)。
• そのソフトウェアがどこから来たか(出自)
• そのソフトウェアに何が含まれているか。

標準化されたフォーマットは、CNAPPツール間でこの情報を共有するための理想的な手段でもあります。

しかし、ソフトウェアの完全性を適切に検証するモチベーションの欠如と、開発者向けツールにおけるサポートの不足が、SBOMの有用性を制限しています。

それでは、ソフトウェアライフサイクルにおけるSBOMの役割と、その普及を妨げている要因を分析していきましょう。

ソフトウェアライフサイクルにおけるSBOM

ソフトウェア開発は、おおよそ次のように進みます。誰かがいくつかのライブラリやツールを取り、それらをコードと組み合わせて、新しいソフトウェアを作り上げます。そしてこれは連鎖でもあります。誰かがそのソフトウェアを取り込み、その上にさらに新しいものを構築するのです。

コンポーネント間にこれほど多くの依存関係があると、小さなコンポーネントで発生した一つのインシデントが、数百万台のシステムを危険にさらす可能性があります。これは、ほとんどのコンピューターシステムで使用されているオープンソースの暗号化ライブラリであるOpenSSLで実際に起きていることです。OpenSSLの脆弱性は、しばしば世界的なセキュリティリスクへと発展します。

この潜在的な影響の大きさこそが、サプライチェーン攻撃を悪意ある攻撃者にとって非常に魅力的なものにしているのです。

ソフトウェアアテステーションは、ほとんどのサプライチェーン攻撃からインフラストラクチャーを保護するうえで非常に有効です。アテステーションは、SBOMを含む構造化データであり、加えて出自の情報や脆弱性のリストといった任意のデータも含むことができます。アテステーションは、開発者やソフトウェアリポジトリによって署名することができます。

コンテナイメージのアテステーションは、docker scout attestを使ってダウンロードし、検証することができます。

詳細は、署名検証でKubernetesのデプロイメントをセキュアにする方法をご覧ください。

コンテナイメージのダイジェストをそのアテステーション署名と照合して検証することで、誰かがイメージを改ざんしたか、あるいはリポジトリを偽装したかを判断できます。ただし、この検証には限界があることに注意してください。リポジトリ自体やその鍵が侵害されているケースには対応できません。

理想的には、この検証はどのソフトウェアを使用する前にも、特に本番環境にデプロイする前に実施すべきです。そして、自社のソフトウェアをパッケージ化する際には、SBOMを生成し署名することも必要です。

Kubernetesの開発においては、このライフサイクルはおおよそ次のようになります。

理論上は、これは非常に理想的に見えます。何を使用しているか、それがどこから来たのかを把握できるからです。これにより、ほとんどのサプライチェーン攻撃ベクトルから保護されます。

では、なぜSBOMの普及率はこれほど低いのでしょうか?SBOMがサポートと実効性を獲得するうえで直面している課題を、いくつか見ていきましょう。

課題1:ツールサポートの不整合

デジタル署名を扱ったことがある人なら誰でも、それに伴う苦労を知っているはずです。

多くのソフトウェア開発ツールがアテステーションをサポートしていますが、開発者チームとインフラチームの間でこれらすべてのツールを連携させるには、ある程度のセットアップとコマンドラインとの奮闘が必要です。このシステムを実装しても、企業環境や大規模なチームには容易には拡張できません。

これは悪循環を生み出します。ツールのサポートがなければ普及率は低くなり、その低い普及率が、ツールサポートを進める動機にもつながらないのです。

しかし、ツールから十分なサポートがあれば、デジタル署名はほぼ透過的なものになります。その良い例が、Appleのノータリゼーション(notarization)システムです。Appleの開発者向けツールは、開発者に代わってアプリを自動的に生成し、署名し、ノータリゼーションを行います。これはSBOMを生成するわけではありませんが、署名の扱いをほぼシームレスに処理します。

課題2:すべてのSBOMを信頼できるわけではない

マヨネーズを購入する際、その原材料リストを見ても、サルモネラ菌が含まれているかどうかは分かりません。同じように、開発者も自分のソフトウェアにマルウェアが含まれているかどうかを知ることはできません。

開発者が提供するSBOMは、新しいライブラリやベースイメージ、ツールなどを検討する際の簡易チェックには有効です。しかし、ユーザーとリポジトリの両方が、自分たちが使用しているものを確実に把握するためには、独自のテストを実施する必要があります。コンテナおよびKubernetesのワークロードについては、イメージスキャナーがこのチェックを行うためのツールとなります。

ほとんどのコンテナレジストリは、開発者が宣言した内容を補完する独自のスキャンを実施していないため、それらのSBOMは単なる参考情報にとどまります。

しかし、独自にイメージスキャンを実施することは可能です。CI/CDパイプラインでこれを行うことで、イメージが組織のセキュリティポリシーに従っていない場合にリリースをブロックできます。また、イメージスキャナーをKubernetesのAdmission Controllerと連携させることで、開発者が提供するSBOMを補完する包括的なSBOMを生成し、問題のあるイメージが本番環境に到達するのを防ぐことができます。

課題3:脆弱性は時間とともに変化する

イメージスキャナーが検出する対象の一つが、既知の脆弱性です。

その情報を基に、重大かつ悪用可能な脆弱性を含むコンテナイメージのデプロイをブロックするという判断が可能になります。実際、一部のツールは、生成するSBOMに脆弱性情報を含めるようになってきています。

しかし、一度のスキャンだけでは十分ではありません。新たな脆弱性は日々発見されているため、イメージに対して継続的にチェックを行う必要があります。SBOMに脆弱性情報が記載されていても、その情報をそのまま信用してはいけません。そのスキャンがいつ実施されたのかを確認し、独自のチェックでそのSBOMを補完してください。

幸いなことに、一部のCNAPPプラットフォームは、すでにこれを代わりに行ってくれます。

• イメージに何が含まれているか、そしてその脆弱性を把握するために、初期スキャンを実行します。
• スキャン結果を、インフラストラクチャーからのコンテキスト情報で補完します。
• この情報をSBOM形式で保存するため、新たな脆弱性を探すためにイメージを再スキャンする必要がありません。

課題4:内部の脅威

最後に、SBOMは悪意ある攻撃者が内部アクセス権を持っているケースには対応できません。

これは、Axiosのnpmパッケージで発生したインシデントのように、チームメンバーが侵害された結果である場合もあれば、従業員が偽者であり、悪意を持った組織的なグループのために働いている場合もあります。いずれの場合も、攻撃者はこの内部アクセスを利用して、あなたのソフトウェアに悪意あるペイロードを隠すことができます。

最も深刻なインシデントの一つが、2024年のXZ Utilsにおけるバックドアです。XZ Utilsは、ほとんどのサーバーや開発マシンにインストールされているリモートアクセスユーティリティであるOpenSSHで使用されているライブラリです。ある悪意あるコントリビューターが、数年にわたって有用なコードを提供し続けた後、突如としてバックドアを紛れ込ませました。

残念ながら、こうした悪意あるペイロードを検出するにはしばしばコードを実行する必要があり、従来のイメージスキャナーはこの種の動的な攻撃を検査しません。さらに、AIを不用意にコード生成に使用すると、ノイズが増え、異常なコードの検出がより難しくなります。

だからこそ、SBOMとアテステーションだけでは新たな脆弱性を検出するには不十分であり、追加のチェックを導入する必要があるのです。

幸いなことに、AIはソフトウェアの脆弱性を発見する力も発揮し始めています。つまり、CI/CDパイプラインにおいてイメージスキャナーと並行してAIを実装することで、内部の脅威を検出できる可能性があるということです。

まとめ

SBOMは、CNAPPの各コンポーネント間で情報を共有するための標準的な手段です。

ソフトウェアサプライチェーンは信頼の連鎖であり、その一つひとつのつながりが重要な意味を持ちます。この連鎖に関わるすべての人が、自らのチェックを実施し、その結果をSBOMを通じて伝え、署名済みのアテステーションによって自らの正当性を証明する必要があります。

これらはすべて自主的な取り組みであるため、組織はしばしば必要なチェックを導入していません。また、ソフトウェア開発ツールにおけるサポートの不足もあります。これらすべての結果として、あまりにも多くのSBOMが本来持つべき有用な情報を保持していないのです。

しかし、だからといってSBOMを諦めるべきというわけではありません。食品、健康、産業といった、私たちの社会を支える他の基盤と同様に、ソフトウェアにおけるサプライチェーンの信頼性を確保するためには、規制が必要です。

SBOMが不完全なものであっても、それは自社のインフラストラクチャーにとって依然として非常に価値のあるツールです。イメージスキャナーでSBOMの生成を始め、それをポリシー評価ツールへの入力として利用することもできますし、自社のソフトウェアとともにSBOMを提供し、ユーザーとの信頼を構築することもできます。世界はいずれ追いついてくるはずですが、その時にはあなたは一歩先を行っているはずです。