2026年のSBOM：賛否両論、そして大きなアンビバレンス

出典：Shutterstock経由 Gorodenkoff

ソフトウェア部品表（SBOM）は、ソフトウェア・サプライチェーンのセキュリティ問題を解決するうえで重要なツールだと喧伝されてきた。しかし、ソフトウェア・エコシステムの急速な変化と、コードのエンドツーエンドで検証されたチェーンを作る複雑さが、依然として広範な普及を阻んでいる。

例えばDockerは、同社のDocker Hardened Images（DHI）においてソフトウェアの「材料リスト」を全面的に採用している。DHIは、安全なソフトウェアコンテナを構築するための、最小限でセキュリティ重視のレシピだ。これらのイメージは不要なソフトウェアコンポーネント（アーティファクトとも呼ばれる）を最小化するためにゼロから構築されており、完全なSBOMと、Supply-chain Levels for Software Artifacts（SLSA）のレベル3を用いた来歴（プロベナンス）の証明を備える。SLSAは、ビルドの完全性をデジタルに担保し、ソフトウェアの出所を検証できるようにする仕組みである。

「私たちは、SBOMはあらゆるアーティファクトに存在すべきだと考えています。特にコンテナイメージは、しばしば数十のソフトウェアパッケージを含み、その多くがOSSコンポーネントだからです」と、Dockerのプロダクトマネジメント担当バイスプレジデントであるマイケル・ドノバン氏は語る。

しかし、企業はソフトウェアのあらゆる断片についてSBOMを作成するのに苦労している、と同氏は言う。成熟したソフトウェア開発プラクティスを持つ企業でさえ、不完全なSBOMを生成してしまう。多くのオープンソースプロジェクトが、自分たちのソフトウェア向けにサプライチェーン・アーティファクトをまだ生成していないためだ。

今年初め、米国サイバーセキュリティ・インフラセキュリティ庁（CISA）はSBOMに関するガイダンスを更新し、マニフェストにSoftware Package Data Exchange（SPDX）やCycloneDXなどの機械可読形式を含めることを求めた。これは、ソフトウェア開発パイプラインにおけるSBOMの生成と利用の自動化を支援するためである。それでもサイバーセキュリティの専門家は、SBOMがどの程度運用可能になるのかについて疑念を抱き続けた。

その結果、焦点が変わったと、組み込みシステム向けサイバーセキュリティプロバイダーであるRunSafe Securityの創業者兼CEO、ジョセフ・サンダース氏は言う。SBOMを要求する企業は、サプライヤーがSBOMを提供できるかどうかではなく、提供されたSBOMが正確で、実務で使える（アクショナブルな）ものかどうかを問うようになっているという。

「今日のSBOMの多くはライフサイクルの遅い段階で生成され、コンポーネントが実際にどう使われているかという文脈が欠けていたり、組み込みソフトウェアやコンパイル済みソフトウェアで本当に出荷される内容を反映していなかったりします」とサンダース氏は言う。「SBOMだけではリスクは下がりません。正確なSBOMは、脆弱性の特定、優先順位付け、そして最終的にはソフトウェア・サプライチェーン・セキュリティの基盤なのです。」

自社ソフトウェアを把握する

規制産業に「顧客を知る（Know Your Customer）」規定があるのと同様に、SBOMはそれに似た概念を具現化したものだ――「自社ソフトウェアを知る（Know your software）」。2021年、退任間近のバイデン政権は大統領令14028を発出し、重要ソフトウェアの購入者にSBOMを提供することを義務付けた。2年後も、SBOMはより良いソフトウェア・サプライチェーン・セキュリティの処方箋というより、義務であり続けた。

その後、欧州連合（EU）はサイバーレジリエンス法（CRA）を可決し、ソフトウェアメーカーに対し、標準化された機械可読形式でソフトウェア部品表を作成・維持することを要求した。多くのオープンソース・エコシステムも、プロジェクトやリポジトリにSBOMを組み込むためのツールやプロセスを提供し、より多くの支援を推進し始めている。

その結果、企業はソフトウェア部品表の提供を求められる未来へと引きずり込まれている、と、堅牢化されたソフトウェアイメージのプロバイダーであるCleanStartの共同創業者兼CTO、ビスワジット・デ氏は語る。

「SBOMはもはや理論ではありません。多くの規制対象やエンタープライズの購買サイクルでは、単に“あるのが当然”になっています」と同氏は言う。「必ずしも明示的な義務という形ではありませんが、実務上は非常に現実的です。コンテナは、SBOMがビルド時に簡単に生成して添付できるため、まずここに表れます。」

問題をはらむサイバーセキュリティ対策

とはいえ、問題は残る。SBOMの提供を求められている多くの企業は、ビルドプロセスの最終段階としてSBOMを生成しており、コンプライアンスのチェックボックスを埋めるために不正確なSBOMを作っている、と、ソフトウェア・サプライチェーン・セキュリティ企業Chainguardの共同創業者兼CEO、ダン・ローレンク氏は言う。来年に向けて企業がソフトウェアのセキュリティ向上を目指すとしても、SBOMはその手段ではないかもしれない、と同氏は述べる。

「米国政府の立場で、セキュリティを実際に前進させるいくつかの領域に“重み付け”できるのだとしたら、これが選ばれたのは私にはずっと不可解でした」と同氏は言う。「意味が通るケースはいくつかありますが、採用され、あらゆる場所に展開されたやり方は、［結局］混乱を増やし、『チェックボックスを埋めよう』ということへの注力を増やしただけです……実際にこれを統合して本当のセキュリティを得よう、というよりも。」

ある意味では、ソフトウェア構成解析（SCA）システムを使う方が、いくつかのコンポーネントを見落とす可能性はあるものの、独立したシステムであるがゆえにより良い場合がある、と同氏は言う。

「SBOMは人々に誤った安心感を与えかねません。攻撃はビルドシステム上で起きており、SBOMが生成されるのもそこだからです」と同氏は言う。「ある意味、最後にスキャンするブラックボックスのソフトウェアは――推測するという点では最善を尽くしているわけですが――少なくとも、すでに侵害されているかもしれない同じシステムではなく、独立したシステムがその推測を行っているのです。」

さらに、ソフトウェアの種類によっては、SBOMがシステム上のソフトウェアの状態を真に捉えられない場合がある。オープンソースコンポーネントに大きく依存することが多い組み込みデバイスでは、マニフェストが不正確になり得ると、RunSafe Securityのサンダース氏は言う。

「正確なSBOMの作成は、特にコンパイル済みソフトウェアや組み込みソフトウェアでは依然として難しい」と同氏は言う。「既存ツールでは、オープンソース、サードパーティ、プロプライエタリのコンポーネントが混在する状況を十分に捉えられず、複雑なビルドシステムがその難しさに拍車をかけるため、多くの組織は手作業のプロセスに頼らざるを得ません。」

SBOMだけではない

サプライチェーン攻撃が増加し、企業が利用しているオープンソースソフトウェアのコンポーネントが安全なのかどうか不安を抱く中、来年さらに関心が高まる主要なソフトウェア・サプライチェーン・セキュリティ施策は、ソフトウェア部品表だけではない。Supply-chain Levels for Software Artifacts、すなわちSLSA（「サルサ」と発音）も、セキュリティを懸念する開発チームにとって別の焦点となるだろう。

「市場ではSBOM以上のものへの需要が見られます。とりわけ、ビルドシステムが本番環境と同じくらい安全になることを確実にする枠組みとしてのSLSAです」とDockerのドノバン氏は言う。「組織がビルドパイプラインを保護することは極めて重要であり、SLSAフレームワークは業界にとって素晴らしい標準を示しています。より多くの組織から要望があることを私たちも耳にしています。」

11月末、Linux Foundationはサプライチェーン・セキュリティ標準の最新の大規模アップデートであるSLSA 1.2をリリースした。このアップデートでは、ビルドプロセスにおけるバイナリコンポーネントの来歴と、ソースコード開発プロセスにおける来歴をそれぞれ追跡するために、より粒度の細かいBuild TrackとSource Trackが定義されている。

そしてもちろん、材料リストという概念はAIにも適用されつつある。AIがソフトウェア、サービス、そして開発プロセスのますます一般的な構成要素になるにつれ、企業はAI部品表、すなわちAI BOMの生成を始めている。

有用なAI BOMは、AI製品の学習および構築に使用されたデータセットに関する情報（データの来歴、機微性レベル、形式など）と、AIモデルに関する情報（名称、バージョン、アルゴリズム、学習パラメータと手法、元の学習セットへのリンクなど）を捉える。さらにAI BOMには、依存関係、セキュリティ、ガバナンス、そしてプロセスを管理する人員と手順に関する情報も含めるべきだと、クラウドセキュリティプロバイダーWizが公開した説明では述べられている。

「AIシステムは常に進化しており、その結果、依存関係の更新やインフラの変更が急速に起こります」と同社は述べた。「承認なしにデータセットを入れ替える、異なるパラメータでモデルを再学習する、依存関係を脆弱なバージョンに更新する――といった小さな変化でさえ、攻撃経路を開き、ガバナンスやコンプライアンスの取り組みを損なう可能性があります。」