SBOMがサプライチェーン攻撃を防げない理由

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

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

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

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

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

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

詳しくは「署名検証によるKubernetesデプロイメントの保護方法」をご覧ください。

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

理想を言えば、こうしたチェックはどんなソフトウェアを使う場合にも、特に本番環境にデプロイする前に実施すべきです。そして、自社のソフトウェアをパッケージ化する際にも、SBOMを生成・署名する必要があります。

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

理屈の上ではこれで完璧に見えます。何を使い、それがどこから来たのかが分かっていれば、ほとんどのサプライチェーン攻撃ベクトルから身を守れるはずです。

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

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

マヨネーズを買うとき、原材料表示を見てもそれにサルモネラ菌が含まれているかどうかは分かりません。それと同じように、開発者自身も自分のソフトウェアにマルウェアが含まれているかどうかを把握しているとは限りません。

開発者が提供するSBOMは、新しいライブラリやベースイメージ、ツールを検討する際の簡易チェックには有用です。しかし、利用者側もリポジトリ側も、実際に使っているものを確信するには、それぞれ独自のテストを実施する必要があります。コンテナやKubernetesのワークロードでは、イメージスキャナーがこうしたチェックを行うためのツールとなります。

ほとんどのコンテナレジストリは、開発者が申告した内容を補完する独自スキャンを行っていないため、そのSBOMはあくまで参考情報にすぎません。

しかし、自分自身でイメージスキャンを実施することは可能です。これをCI/CDパイプライン上で行えば、イメージが自組織のセキュリティポリシーに準拠していない場合にリリースをブロックできます。また、イメージスキャナーをKubernetesのアドミッションコントローラーと連携させることで、開発者提供の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の生成を始め、それをポリシー評価の入力として活用することもできますし、自社ソフトウェアに添えてユーザーとの信頼構築に役立てることもできます。世の中はいずれこの流れに追いついてくるはずであり、今始めておけば、その時点で一歩リードできているでしょう。