2026年版の最小要素で見直すSBOMの作り方と脆弱性管理での使い方

緊急度の高い脆弱性が公表された日、多くの組織が最初にぶつかるのは「その部品を自社が使っているのか」という問いです。直接インストールした覚えがなくても、別のライブラリの内側に取り込まれていることがあり、資産管理台帳を引いても答えが出ません。経済産業省の手引も、資産管理の対象が開発者の直接利用する上位コンポーネントに偏りやすく、内包されて間接的に使われる下位のコンポーネントは対象外になりがちだと指摘しています。台帳と脆弱性情報を突き合わせるだけでは、間接的な影響を検知できないという構造の問題です。

SBOM(Software Bill of Materials、ソフトウェア部品表)は、この問いに機械処理で答えるための成果物です。ソフトウェアを構成する部品と依存関係を、機械が読める一覧として書き出しておき、新しい脆弱性が出たときに検索できる状態にします。2026年7月29日には、この部品表に最低限書くべき内容を定めた国際ガイダンス「2026 Minimum Elements for a Software Bill of Materials (SBOM)」が公表され、翌30日に経済産業省と内閣官房国家サイバー統括室が共同署名したことを公表しました。2021年に米国NTIAが定めた最小要素を、SBOMツールの進歩を踏まえて更新したものです。

この記事は、SBOMという成果物そのものに何を書くのか、どの工程で作るのか、そして作ったあとに脆弱性情報とどう突き合わせ、調達と契約でどう扱うのかを整理します。想定読者は、ソフトウェアの脆弱性管理を担当する開発者と運用者です。記述は経済産業省、CISA、IPA、SPDX、CycloneDXの公式資料にもとづき、事実は執筆時点(2026年8月3日)に確認できた範囲に限ります。依存ライブラリの更新自動化やSCAツールの選び方は別記事で扱っているため、ここでは触れません。

依存の深さが「使っているか」への即答を妨げる#

現代のソフトウェアは、直接指定した数個のライブラリの背後に、数百から数千の間接依存を抱えます。開発者が意識しているのは最上位のごく一部で、その下の階層は普段まったく見えません。この見えなさが、緊急時にそのまま応答の遅さへ変わります。

経済産業省の実証では、SBOMを作成して管理しておくことで、コンポーネントの脆弱性が発見された際に影響の有無を特定するまでのリードタイムを短縮でき、脆弱性が残留するリスクと対応工数の低減につながることが確認されています。逆に言えば、SBOMがない状態では、各プロジェクトのビルド設定を人手で開いて回る作業が、影響調査のたびに発生します。対象が10製品あれば10回、100製品あれば100回です。

ここで押さえておきたいのは、SBOMが攻撃を止める仕組みではないという点です。CISAの2026年版最小要素も、SBOMはソフトウェアと供給網の安全に関するすべての懸念を解決するものではなく、リスクを踏まえた意思決定を可能にするために必要な一歩だと書いています。SBOMが変えるのは、脆弱性が出たあとの初動の速さと確からしさです。ここを取り違えると、導入の効果を測る指標を間違えます。

供給元の侵害そのものへの備えは、SBOMとは別の対策が要ります。攻撃経路の全体像は関連記事で整理しています。

あわせて読みたい

サプライチェーン攻撃の構造と防御の考え方。ソフト・ハード・サービス経由の侵入をどう減らすか

導入の議論でつまずきやすいのが費用対効果です。経済産業省の実証では、SBOMを導入する際の初期工数は大きいものの、SBOMツールを活用することで負担が軽減され、手作業での部品管理と比べれば工数は小さくなることが確認されています。同時に、対象とするソフトウェアやシステムの全体構成を把握できていない場合、ツールの適用範囲を適切に設定できず、効果的なリスク管理にならないという課題も挙げられています。範囲を決めないまま導入すると、初期工数だけを払って効果が出ない形になりやすい、ということです。

なお、SBOMを公開すると攻撃者に手の内を教えることになる、という懸念をよく聞きます。IPAの手引きは、米国NTIAの「SBOM Myths vs. Facts」を引きながら、攻撃者はSBOMがなくても攻撃可能であり、SBOMは防御者のためのロードマップとして機能するため透明性の利点が上回る、という整理を紹介しています。あわせて、SBOMを作る行為と、それを外部へ公開する行為は別であり、作成者は自らの裁量で共有範囲を決められるとも書かれています。作ることと公開することを切り分けて考えると、議論が前に進みます。

2026年版の最小要素に何が並ぶのか#

SBOMに何を書くべきかは、長らく2021年7月に米国NTIAが公表した最小要素が基準でした。2026年版はこれを置き換えるもので、CISAとNSA、FBIに加えて日本の経済産業省と国家サイバー統括室を含む各国の当局が共同で作成しています。経済産業省の発表によれば、共同署名に参加したのは日本と米国のほか、オーストラリア、カナダ、チェコ、フランス、ドイツ、インド、イタリア、韓国、オランダ、ニュージーランド、ポーランド、スロバキアの12か国で、あわせて計14か国の当局等です。文書自体はバージョン2.1として、2021年の初版と2025年8月の草案を経て2026年7月29日に発行されました。

最小要素は、SBOM文書に載せるデータフィールドと、組織がSBOMをどう扱うかを定めるプラクティスとプロセスの2本立てです。データフィールドはさらに、SBOM文書そのものを説明するSBOMメタデータと、部品を説明するコンポーネントデータに分かれます。

2021年版からの変化のうち、実務に効くものを3つ挙げます。

1つ目は、新設された項目群です。SBOM作成主体の署名、データフォーマット名とバージョン、生成コンテキスト、ツール名とバージョン、SBOMバージョン、コンポーネントのハッシュ値とハッシュアルゴリズム、コンポーネントライセンスが加わりました。このうち署名とハッシュ値は、混同されがちですが役割が違います。SBOM作成主体の署名は、SBOM作成主体に帰属する電子署名だと定義されており、その電子署名を付けたと主張する主体が実際に署名したこと、および署名の生成後に情報が変更されていないことについて保証を与えると説明されています。つまり、SBOM文書そのものの出どころの確認と改変検知を担います。一方のコンポーネントのハッシュ値は、実行可能な成果物にハッシュ関数を適用した出力値で、ハッシュアルゴリズムはその値を計算したアルゴリズムを記録する項目です。こちらはSBOMに記載された部品と実際の実行可能な成果物を照合する用途で、SBOM文書の完全性を確かめる値ではありません。ガイダンスは、SBOM作成者が実行可能な成果物にアクセスできない場合は値が不明であることを示すべきだとしています。ライセンスの追加について、ガイダンスは、部品のライセンスがその条件に沿った適正な利用を助け、著作権侵害の主張に関するリスクの管理に役立つことを理由として挙げています。

2つ目は、深さの扱いが変わったことです。2026年版は、2021年版の「Depth」が最上位の依存についてのみ構成部品の情報を捉えるものとして定義されていたと説明し、この要素を「Coverage(カバレッジ)」へ置き換えたとしています。2026年版が示すCoverageは、推移的依存を含め対象ソフトウェアを構成するすべての部品の情報を含めるべきであり、最低限の深さは定めない、というものです。同じ部品でもメタデータの異なる複数のインスタンスがある場合は、依存関係とともに個別に列挙すべきだとも書かれています。変更点の説明では、依存関係情報に求める深さの程度を定める代わりに、垂直方向の広がりに加えて水平方向の広がりも含める形でCoverageを定義したと述べています。ガイダンスは、脆弱性管理の立場から見て、SBOMにその部品が載っていなければ新たに報告された脆弱性は自社に影響しないと受け手が結論できる状態を例として挙げています。

3つ目は、アクセス制御が単独の要素から外れ、配布と提供の要素へ吸収されたことです。共有そのものを止める設計ではなく、権限のある相手との共有や信頼できるセキュリティツールへの取り込みを妨げない範囲でアクセス制御を掛ける、という整理になりました。

名前が変わったことで意味が明確になった項目もあります。2021年版の「サプライヤー名」は、2026年版で「コンポーネント提供主体」へ置き換えられました。ガイダンスは、サプライヤーという語が実務では曖昧で、とくにソフトウェアの流通業者の扱いをめぐって解釈が分かれていたと説明しています。提供主体はその部品を作った主体を指し、SBOMを作った主体である「SBOM作成主体」とは別の項目です。自社製品のSBOMを自社で生成すれば両者は一致し、第三者が解析してSBOMを起こした場合は一致しません。オープンソースについて提供主体がはっきりしない場合は、来歴が不明であることを明示すべきだとされています。空欄で流すのではなく、追跡できないという事実を記録に残す設計です。

2026年版の最小要素は、CISAとNSA、FBI、および経済産業省を含む各国当局の連名で2026年7月29日に発行されました。文書は「これらの最小要素は新たな要求事項を作るものではなく、組織がSBOMをどう生成し、どう要求すべきかを精緻化するものである」と述べ、オープンソースソフトウェア、AIソフトウェア、SaaSを含むすべてのソフトウェアを適用範囲としています。

日本語で確認したい場合は、経済産業省の手引ver 2.0が参考になります。ただし、この手引が参照している最小要素はNTIAの2021年版です。手引の記述と2026年版のあいだには、深さとカバレッジの扱いや、ライセンスと署名の追加といった差があるため、読むときは版の違いを意識してください。

SPDXとCycloneDXのどちらで出すか#

最小要素は「何を書くか」を定めますが、「どう書くか」は定めていません。ここを担うのがデータフォーマットです。2026年版の最小要素は、ソフトウェアエコシステムの関係者が現在広く使う2つのフォーマットとしてSPDXとCycloneDXを挙げ、どちらも国際的な公開プロセスの産物であり、機械処理可能かつ人が読める形式だと説明しています。

SPDXはThe System Package Data Exchangeの略で、Linux Foundationのプロジェクトとして運営されています。ISO/IEC 5962:2021としてSPDX 2.2.1が国際標準になっており、公式の仕様ページが現行版として掲げるのは3.0系ですが、こちらはISO規格にはなっていません。3.0系ではモデルが関心領域ごとのプロファイルに分かれます。仕様が有効なプロファイルとして列挙しているのは、Core、Software、SimpleLicensing、ExpandedLicensing、Security、AI、Dataset、Build、Extension、そして軽量版のLiteです。ライセンス識別子の体系(SPDX License List)は事実上の共通語になっており、2026年版最小要素もコンポーネントライセンスの記述にSPDXのライセンス識別子を使うことを勧めています。

CycloneDXはOWASP Foundationのプロジェクトで、Ecma InternationalのTC54とともに仕様を進めています。公式の仕様ページによれば、現行版は1.7で2025年10月21日にリリースされ、標準としては、CycloneDX 1.7を対象とするECMA-424の第2版が2025年12月10日に公開されています(第1版は2024年6月)。ソフトウェアのSBOMに加えて、SaaSBOM、HBOM(ハードウェア)、CBOM(暗号)、AI/ML-BOMといった派生を同じ体系で扱え、脆弱性とその悪用可能性を記述する領域を仕様の内側に持っているのが特徴です。

選び分けの現実解は、要求元に合わせることです。調達側や規制側から形式を指定されているならそれに従い、指定がないなら社内のツールが素直に読み書きできるほうを選びます。2026年版最小要素は、組織は広く使われていて相互運用でき機械処理可能なSBOM形式であれば受け入れるべきだとする一方、新しいソフトウェアについては非推奨(deprecated)とされた版のフォーマットで生成されたSBOMを受け取ることは避けるべきだとしています。どちらを選ぶかより、非推奨版を惰性で使い続けないことのほうが実害に直結します。

軽量な選択肢もあります。IPAの手引きは、簡易的なSBOMの作成と管理を目的としたSPDX-Liteやツール独自の形式が存在するとしたうえで、自動化と相互共有という点ではSPDX、CycloneDX、SWIDタグの3つの形式が広く普及していると述べています。社内だけで完結する台帳なら簡易形式でも回りますが、供給網をまたいで渡す前提なら普及した形式へ寄せるほうが後の手戻りが少なくなります。

なお、同じフォーマットを使っていれば情報が漏れなく連携できる、とは限りません。IPAの手引きは、同一のSBOMフォーマットを使っていても生成ツールの実装が異なると出力される情報に実装固有の傾向が生まれ、共有時の情報の欠落やエラーが起きる場合があると指摘しています。相手のSBOMを取り込む運用に入るときは、実データで読み込み試験をしてから本番の流れに乗せてください。

ビルド工程で作り、生成した時点を記録する#

SBOMは、リリースのたびに機械が作り直す前提の成果物です。手作業で維持しようとすると、依存が変わるたびに台帳が古びます。経済産業省の実証では、医療機器分野の歯科用CTを対象にした事例で、手動と比較して99パーセント以上の工数削減が確認されたと報告されています。IPAの手引きも、小規模なソフトウェアであっても依存関係にあるOSSが多いため、ツールを用いることが現実的だとしています。

作る場所として素直なのは、CI/CDのビルド工程です。ビルドの入力(ロックファイルやマニフェスト)と出力(成果物)が同じ場所にそろっており、そこで生成すればバージョンの取り違えを抑えやすくなります。取り違えを実際に防ぐには、生成したSBOMと成果物を同じリリース識別子や成果物のダイジェストで結び付けて保管し、あとから両者を突き合わせられるようにしておく必要があります。2026年版最小要素の「頻度」の要素も、ソフトウェアの各バージョンや更新ごとに対応するSBOMを持つべきで、新しいビルドやリリースを出すときには変更を反映した新しいSBOMも生成すべきだとしています。SBOMは成果物と一対一で対応する添付物だと考えると、置き場所と保管期間も決めやすくなります。

届け方も同時に決めておく必要があります。2026年版の「配布と提供」は、SBOMを必要とする相手へ速やかに届けられる状態にすべきだとしたうえで、共有の手段としてインストールに同梱する形、バージョン固有のURLで参照できるようにする形、データベースへのAPIを用意する形、公開リポジトリに置く形を挙げています。どれを選ぶかは相手との関係で決まりますが、成果物のバージョンとSBOMが確実に対応づく方法を選ぶのが要点です。バージョンを含まないURLに最新版だけを置く運用にすると、過去のリリースについて問われたときに答えられなくなります。

2026年版で新設された「SBOM生成コンテキスト」は、この工程の話をそのままデータにしたものです。SBOM作成者がどのライフサイクル段階で、どんなデータを手にして生成したのかを記録する項目で、ガイダンスは「ビルド前」「ビルド」「ビルド後」といった一般的な表現でも満たせるとしています。ソースコードから生成したSBOMはビルド前、バイナリ解析ツールが生成したSBOMはビルド後、という区別です。

この区別が効くのは、解析手法によって見えるものが変わるからです。IPAの手引きは、ツールによるコンポーネント解析の手法を、パッケージマネージャやビルドツールのメタデータを読む依存関係検出、シグネチャやハッシュ値を照合するコードマッチング、ソースコード内の文字列を拾う文字列検出の3つに整理しています。依存関係検出は網羅性が高く誤検出が少ない一方、コピーして貼り付ける形で持ち込まれた依存は拾えません。残る2つは逆で、拾える範囲が広い代わりに誤検出が増えます。経済産業省の実証では、バイナリファイルだけを対象にしたスキャンの結果が、通常スキャンで検出されたコンポーネント数と比べて1割程度しか検出されなかった事例も報告されています。生成コンテキストを書き残す価値は、受け取った側が「このSBOMはどこまで見えているものか」を判断できることにあります。

同じ理由で、解析する環境も結果を左右します。経済産業省の実証では、開発環境でスキャンした場合に、実際には製品で使われないアンインストール用パッケージまで検出された例が報告されています。本番の成果物に対して、本番と同じ条件で生成するのが基本です。CI/CDへの組み込みの考え方は、関連記事もあわせて参考になります。

あわせて読みたい

DevSecOps入門。CI/CDにセキュリティを組み込むSAST・DAST・SCA・シークレットスキャン

作っただけでは脆弱性は減らない#

SBOMは部品の一覧であって、危険の一覧ではありません。CISAの2026年版最小要素も、SBOM単体はソフトウェア構成部品に関するデータであり、分析によって初めてリスクに関する洞察へ変わると結論で述べています。したがって運用の形は、SBOMと脆弱性情報を突き合わせる仕組みを、SBOMの生成とは別に用意することになります。

突合の実装には、大きく3つの選択肢があります。脆弱性データベースのWeb UIを人手で引く方法、APIを使ってCPEやPURLといった部品識別子をキーに機械的に照合する方法、そして脆弱性管理機能を持つツールに任せる方法です。IPAの手引きは、Web UIは件数が増えると実運用に耐えられない可能性があり、API連携は導入に専門的なスキルと工数がかかるうえ運用と改修が続くとして、まずは既存ツールの利用検討を推奨しています。人的リソースと検知精度の両面から見て現実的だという整理です。

ツールに任せる場合の注意点も、同じ手引きが挙げています。利用するSBOMツールによっては脆弱性DBとの紐づけを行わないものがあること、有償ツールでは継続的なライセンス費用が必要になること、そしてツールが持つ独自の脆弱性DBが自社の使うコンポーネントを収録していない恐れがあることです。選定時には、自社が実際に使っているエコシステムの部品がそのツールのDBで引けるかを、実データで確かめてください。カタログ上の対応言語の数より、手元のロックファイルを読ませたときの検出結果のほうが判断材料になります。

ここで効いてくるのが、最小要素のコンポーネント識別子です。2026年版は、少なくとも1つのソフトウェア識別子を含めるべきだとし、CPEやPURLといった一般的な識別子の使用を求めています。加えて、UUIDや組織固有の識別子、コミットハッシュ、OmniBORやSWHIDのような内在的識別子も含められるとし、複数ある場合はすべて含めるべきだとしています。識別子の質は、突合の精度を左右する主な要因の1つです。名前とバージョンの文字列だけで照合すると、同名異物や表記ゆれで簡単に取りこぼします。ここまでに挙げた脆弱性データベースの収録範囲、部品の検出漏れ、バージョンの誤認、別名や表記ゆれへの対応といった要因と重なって、突合の結果の確からしさが決まります。

一方で、SBOMを入れると検出される脆弱性はむしろ増えます。IPAの手引きは、SBOMを活用することで理論上はそのソフトウェアに含まれる既知の脆弱性をすべて検出でき、その結果として優先付けや修正にかかるリソースの不足が加速すると予想しています。件数が増えた状態で全件対応を目指すと運用が破綻するため、優先度付けの仕組みを先に用意しておく必要があります。深刻度と悪用実績を組み合わせた優先度付けの考え方は、関連記事で詳しく扱っています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

依存ライブラリの更新をどう回すか、SCAツールをどう選ぶかについては、次の記事が対応します。

あわせて読みたい

依存ライブラリ管理とSCA。SBOMで攻撃面を把握する

VEXで「影響しない」を伝える#

検出された脆弱性が、その製品では実装条件によって悪用できない場合があります。脆弱なコンポーネントを取り込んでいても、脆弱性のある関数を呼んでいなければ攻撃が成立しない、といった状況です。この「含んでいるが影響しない」を機械が読める形で伝えるのが、VEX(Vulnerability Exploitability eXchange)です。

CISAのVEX最小要件は、VEXが脆弱性に対する製品やコンポーネントの状態を示すものだと定義し、状態として次の4つを規定しています。

• not_affected(影響しない): 修正も緩和も必要ない
• affected(影響する): 修正や緩和のための行動が推奨される
• fixed(修正済み): 対象製品には修正が入っている
• under_investigation(調査中): 作成者らが調査中で最終判断に至っていない

not_affectedを主張するときは、理由を添えることが求められます。理由(justification)として定義されているのは、脆弱なコンポーネントを含んでいない、含んでいるが脆弱なコードが存在しない、脆弱なコードが実行経路に入らない、脆弱なコードは攻撃者が制御できない、製品内の緩和策がすでに悪用を防いでいる、の5種類です。理由を付けない場合は、なぜ影響しないのかを説明する影響記述(impact statement)を必ず添えなければならないと定めています。affectedの場合は、修正や緩和のための行動を記述した行動記述(action statement)を1つ含めることが必須です。

VEXは特定の形式に縛られません。CISAの文書は、その作成時点(2023年4月)でCSAF、CycloneDX、OpenVEXがVEX文書を含んだり生成したりできるとしています。CSAFはOASISが管理するセキュリティアドバイザリの機械可読形式で、ベンダーが公表するアドバイザリをそのまま自動処理に載せる用途に向きます。2026年版の最小要素も、VEXやCSAFのようなセキュリティアドバイザリが、リスクのあるソフトウェアコンポーネントの範囲を絞り込むことで脆弱性管理の効率を高めうると述べています。

CISAの「Minimum Requirements for Vulnerability Exploitability eXchange (VEX)」は2023年4月に公表された文書で、VEXはSBOMや脆弱性データベース、セキュリティアドバイザリと統合するよう設計されているが、それらを必要とはしない、と明記しています。VEX文書はソフトウェアの供給者だけでなく第三者も作成できます。また、明示されていない既定の状態を想定したり暗示したりしない、とも述べています。

最後の一文は運用上の含意が大きい部分です。VEXに記載がないことは「影響しない」を意味しません。記載のない脆弱性は、単に判断が示されていないだけです。供給者から受け取ったVEXを取り込むときは、この非対称性を前提に、記載のないものを未評価として扱う設計にしてください。

検出漏れと過検知にどう向き合うか#

SBOMツールの出力は完全ではありません。経済産業省の実証では、シンボリックリンクやランタイムライブラリのようにスキャン対象に含まれない部品が検出されなかった例、バージョン情報が誤って検出された例、ツールのデータベースに存在しないOSSが検出されず手動での追加が必要になった例などが確認されています。SBOMツールで検出された部品とパッケージマネージャで抽出した部品が一致しないケースも報告されています。

対処の方向は2つあります。1つは、手動での精査を挟むことです。IPAの手引きは、手動でコンポーネント解析結果を精査すればSBOMの精度は向上するとしたうえで、精査には膨大な工数がかかり運用負荷が増えるため、自社の運用が負荷に耐えられるかを考慮したうえで実施することを勧めています。全数を精査するのではなく、重要度の高い製品や外部公開の資産に絞る、という判断が現実的です。

もう1つは、不明であることを不明のまま書くことです。2026年版最小要素の「不明情報の明示」は、データフィールドの情報を提供できない場合に、それがSBOM作成者にとって未知なのか、それとも意図的に伏せているのかを明示すべきだと求めています。セキュリティに関わる理由で伏せた情報については、受け手が問い合わせられる手順を用意すべきだとも書かれています。空欄のまま出すと、受け取った側はその部品が存在しないのか、調べていないのかを区別できません。「わからない」を明示的なデータとして記録することが、受け手の判断材料になります。

受け取ったSBOMの確からしさを確かめる方法についても、ガイダンスが検証の項で触れています。作成主体の署名は、作成された時点のSBOMがそのまま届いたことを保証しますが、記載内容が正確で網羅的であることまでは保証しません。正確性やカバレッジ、完全性の確認は署名とは別の性質の話で最小要素の範囲外だとしたうえで、オープンソースのリポジトリやバイナリ解析ツールを使い、SBOMに記載されていない部品を検出する方法があると述べています。調達側が受け取ったSBOMを検証する現実的な手段は、いまのところこの種の突き合わせです。

過検知への対処では、突合の誤りとVEXの守備範囲を分けて考える必要があります。使っていない部品を検出した、バージョンを取り違えたといった突合の誤りは、SBOMや脆弱性データベースの側の元データを直す問題で、VEXで打ち消すものではありません。VEXが担うのは、正しく検出された脆弱性について、自社製品で影響があるかどうかを機械可読な形で伝えることです。自社製品では悪用できないと判断したものは、理由を選んでnot_affectedとして記録します。

ただし、VEXを書くだけで検出結果のノイズが減るわけではありません。VEX文書を読み込んで判定済みのものを表示から外せるツール側の対応があって初めて、次回以降に確認する件数が減ります。取り込みに対応していないツールを使っている場合は、VEXを作っても一覧は同じままです。判断の根拠を記録に残すこと自体は、監査への説明にもなります。

調達と契約でSBOMをどう扱うか#

SBOMは、作る側と便益を得る側がずれやすい成果物です。経済産業省の手引ver 2.0は、サプライチェーンを通じた部品の受発注では、SBOMを作成してコストを負担する側と、SBOMを取得して脆弱性管理を効率化する側が別に存在するため、負担するコストと得られる便益に非対称性があると指摘しています。取引契約でSBOMに対する要求と責任を明確にし、それに応じた対価の支払いを定めないと、適正な水準まで普及しないという見立てです。

CISAの2026年版最小要素も、同じ方向を向いています。プラクティスとプロセスの各要素について、SBOMを求めたり提供したりするあらゆる方針、契約、取り決めの中で、組織はこれらの要素を明示的に扱うべきだと述べています。フォーマットや頻度、カバレッジといった項目は、技術の話であると同時に契約の話でもあるということです。

手引ver 2.0の付録「SBOM取引モデル」は、開発委託契約書と発注仕様書でSBOMについて規定すべき主な事項を、区分ごとに整理しています。この付録が想定する読者は、受発注者のあいだでSBOMに関する要求や責任、コスト負担の規定を定める取引契約に関わる法務担当者と開発者です。手引は、この取引モデルがIPAやJEITAなどから公開されているソフトウェア開発のモデル契約書と組み合わせて使われることを前提とし、責任と保証に関わる項目はそれらを踏まえて整理したと説明しています。既存のモデル契約書を置き換えるものではなく、SBOMに関する条項を足すための材料だと理解すると、位置づけを誤りません。項目名と趣旨を要約すると次のようになります。

手引はこれらの項目に基礎と発展のレベルを付けており、基礎に分類されているのはSBOMフォーマット、部品ID標準、SBOM最小要素、対象サプライヤ契約形態、サードパーティ部品の事前合意、共有方法、SBOM更新、契約不適合責任、損害賠償、見積の10項目です。すべてを一度に契約へ書き込むのではなく、まず基礎の項目から合意する、という進め方が想定されていると読めます。なお、この取引モデルは各社が自社の契約条項を作るための参考例として示されたものであり、そのまま条文として使えるものではありません。実際の条項は法務の確認を経て作成してください。

規制の側からもSBOMの提出を求める動きが紹介されています。2026年版最小要素は、各国の関連文書を挙げるくだりで、欧州連合のサイバーレジリエンス法(Regulation (EU) 2024/2847)がデジタル要素を持つ製品の製造者に対して技術文書の一部としてSBOMの提供を求めている、と記載しています。経済産業省の発表も、本ガイダンスの中で同法がデジタル要素を有する製品の製造者に規制当局へのSBOMの提供を義務付けていることが示されている、と説明しています。いずれもガイダンスの記載を紹介したもので、どの製品にどの時期からどこまでの義務がかかるかまでは書かれていません。欧州向けに製品を出す事業者は、契約要求としてのSBOMに加えて規制要求としてのSBOMも検討の対象になりますが、具体的な義務の範囲や条件は規則本文と所管当局の案内で各社が確認してください。

小さく始めるための手順#

この順序の肝は、対象を絞った状態で「生成、突合、判断の記録」の3つが一巡することです。全社展開を先に決めてしまうと、突合の運用が固まる前に大量の検出結果が積み上がり、対応の見通しが立たなくなります。1製品で一巡させてから広げるほうが、結果的に早く回ります。

運用チェックリスト#

まとめ#

SBOMは、緊急の脆弱性が出たときに「使っているか」を人手の調査ではなく検索で答えるための成果物です。2026年7月に公表され日本を含む14か国の当局が共同署名した最小要素は、この成果物に最低限書くべき内容を、データフィールドとプラクティスの両面から定めています。作成主体の電子署名とコンポーネントのハッシュ値を新たに加え、推移的依存まで含むカバレッジを求め、生成した時点を記録させるという変更は、いずれも「受け取った側がどこまで信用してよいか」を判断できるようにするための調整です。

作るところまでで止めても脆弱性は減りません。脆弱性データベースとの突合を自動で回し、増える検出結果に優先度を付け、悪用できないものをVEXとして理由付きで記録するところまでが一続きの運用です。そして、供給網をまたぐ場面では、フォーマットとカバー範囲、更新頻度、責任とコスト負担を契約に書くことで初めて、必要な品質のSBOMが継続して届きます。まずは1製品でこの一巡を作り、そこから対象を広げていくのが確実です。なお、契約条項や規制対応の具体的な判断は事案ごとに変わるため、自社の法務や専門家に確認したうえで進めてください。