SBOMとは何か（そして、SBOMなしでは出荷できない理由）？

Omdiaの2026ソフトウェアサプライチェーンセキュリティレポートによると、SBOMを生成している組織の73 %は、SBOMによって脆弱性の軽減がより効率的になると述べているが、 86 %は依然として生成プロセスが困難だと感じている。認識されている価値と運用上の困難さとの間のギャップこそが、ほとんどのチームが行き詰まるポイントである。コンテナ化されたアプリケーションを構築および保護するチームにとって、SBOMとは何か、そしてそれをどのように活用するかを理解することは、もはや選択肢ではなく必須事項となっている。

このガイドでは、SBOM（ソフトウェア部品表）の内容、ソフトウェアサプライチェーンのセキュリティにおけるSBOMの重要性、標準フォーマットとツールの仕組み、そして業界における規制と執行の今後の方向性について解説します。

SBOMとは何ですか?

すべてのソフトウェア成果物には、依存関係が伴います。Alpine Linuxをベースとしたコンテナイメージには、数十個のシステムパッケージが含まれる可能性があり、それぞれに独自のバージョン、ライセンス、およびアップストリームのメンテナーが存在する。最上位のアプリケーション層は、開発者が明示的に選択したことのないフレームワーク、ライブラリ、および推移的な依存関係を追加する。スタックが深くなるほど、基本的な質問、つまり「本番環境で実際に何が稼働しているのか？」に答えるのが難しくなります。

ソフトウェアの部品表を見れば、その疑問に答えられる。これは、ソフトウェア成果物に含まれるすべてのコンポーネント、ライブラリ、モジュールを構造化し、機械が読み取り可能な形で一覧化したものです。パッケージマニフェスト（package.jsonやrequirements.txtなど）では宣言された依存関係がリストされますが、SBOMはビルド後に解決された依存関係ツリーをキャプチャします。これには、推移的な依存関係、システムレベルのパッケージ、および各コンポーネントの起源、バージョン、ライセンスに関するメタデータが含まれます。ソフトウェアの栄養成分表示のようなものだと考えてください。

SBOMに含まれるもの

適切に作成されたSBOMには、各コンポーネントに関するいくつかのカテゴリのメタデータが含まれています。

• コンポーネント識別子:パッケージ名、バージョン、およびサプライヤー (例: openssl 3 . 1 . 4 、（OpenSSLプロジェクトによって管理されています）
• ライセンス:再配布と使用を規定するライセンスの種類 (MIT、Apache 2 . 0 、GPL)
• 依存関係：コンポーネント同士がどのように依存し合っているか（直接的および推移的な依存関係を含む）
• 固有識別子：脆弱性データベースとの相互参照を可能にするパッケージURL（purl）またはSWIDタグ
• チェックサムとダイジェスト:消費者がコンポーネントが改ざんされていないことを検証できるようにする暗号化ハッシュ
  このデータは、主にSPDXまたはCycloneDXなどのオープン標準を使用して構造化されており、機械可読性とツール、レジストリ、コンプライアンス ワークフロー間での相互運用性を維持しています。実際には、単一パッケージのSPDX SBOMエントリは次のようになります。

{
  "name": "openssl",
  "SPDXID": "SPDXRef-Package-openssl",
  "versionInfo": "3.1.4",
  "supplier": "Organization: OpenSSL Project",
  "licenseDeclared": "Apache-2.0",
  "checksums": [{ "algorithm": "SHA256", "value": "a1b2c3..." }]
}

実際のSBOMには、ベースイメージのOSパッケージからアプリケーションのランタイム依存関係に至るまで、アーティファクト内のすべてのコンポーネントに対して、このようなエントリが1つずつ含まれています。

ソフトウェアサプライチェーンのセキュリティにおいてSBOMが重要な理由

SBOM（部品表）の価値は、何か問題が発生した瞬間に明らかになる。Log 4 Shellの脆弱性が2021月に公開された際、最新のSBOMを持つ組織は、インベントリを照会して、影響を受けるすべてのイメージを数分以内に特定することができました。それらを持たないチームは、レジストリやデプロイメントマニフェスト全体にわたる依存関係を手作業で追跡するのに何日も費やした。

Sonatypeの調査によると、オープンソースのCVEの約65 %にはNVDが割り当てたCVSSスコアがなく、独自にスコアリングしたところ、 46 %が高または重大であることが判明しました。SBOMがなければ、スコアリングされていない脆弱性は見えないままです。

より迅速なインシデント対応

新しいCVEが発表されると、まず最初に問われるのは「我々はどこに脆弱性を抱えているのか？」ということだ。SBOMがあれば、その疑問に数日ではなく数秒で答えられるようになる。影響を受けるパッケージとバージョンをSBOMライブラリと照合すれば、影響範囲を即座に把握できます。SBOMと継続的な脆弱性スキャンを組み合わせることで、プロセスは自動化されます。新しいCVEは既存のSBOMと照合され、影響を受けるイメージは手動の介入なしにフラグ付けされます。

顧客事例紹介： 1億人以上のユーザーにサービスを提供するビデオストリーミングプラットフォームであるJWPは、1時間以内に400以上のリポジトリに対する脆弱性スキャンを可能にしました。SBOM（ソフトウェア部品表）をスキャンパイプラインに組み込むことで、チームは何千もの脆弱性を修正すると同時に、何万もの重要度の低い問題をフィルタリングし、ノイズを減らし、修復作業を加速させた。

規制遵守

SBOM（部品表）は、ベストプラクティスから法的要件へと移行しつつある。米国では、大統領令14028により、連邦政府機関に販売されるソフトウェアのSBOM要件が開始されました。CISAの2025最小要素ガイダンスは、有用なSBOMに何を含めるべきかを明確にすることを目的としています。EUサイバーレジリエンス法（EU CRA）は、同様の要件を欧州市場で販売される製品にも適用する。規制産業、金融、医療、防衛、重要インフラなどの分野で事業を展開する組織にとって、SBOM（部品表）の導入は調達における重要な障壁となりつつある。

受動的な信頼ではなく、能動的な検証

SBOM（ソフトウェア部品表）は、ソフトウェアが安全であると想定するセキュリティモデルから、ソフトウェアが安全であることを検証するセキュリティモデルへと移行させる。レジストリにクリーンと記載されているからといって、ベースイメージがクリーンであると鵜呑みにするのではなく、チームはSBOMを検査して、どのパッケージが存在するか、どのバージョンが実行されているか、既知の脆弱性が適用されるかどうかを確認できます。

実際には、これはSBOMデータに基づいてポリシーを作成することを意味します。つまり、承認されていないサプライヤーからのパッケージが含まれているイメージは出荷せず、サポート終了コンポーネントは定義された猶予期間を超えて保持せず、一致するSBOM証明書がないイメージは展開しないということです。これらのチェックはCI（継続的インテグレーション）で自動的に実行できるため、SBOM（部品表）は受動的な文書から能動的なゲートへと変わります。

SBOMは、出所証明や暗号署名と組み合わせることで、供給元から展開先までの検証可能な管理連鎖における一つの層となる。あなたはもはや登録機関の言葉を鵜呑みにしない。あなたはそれを暗号的に検証しているのです。

SBOMのフォーマットと規格

SBOMがチーム、ツール、組織を超えて役立つためには、共通の言語が必要である。現状では2つのオープンスタンダードが主流を占めており、それぞれ異なる主要な用途を想定して設計されている。

SPDX（ソフトウェアパッケージデータ交換）

Linux Foundation (ISO/IEC 5962 : 2021 ) によって開発された SPDX は、ライセンスコンプライアンスとオープンソース監査において最も広く採用されているフォーマットです。これは、BuildKitに組み込まれているSBOMジェネレーターでも使用されているフォーマットであり、ビルド中にコンテナイメージに証明書としてSPDXドキュメントを添付します。

サイクロンDX

OWASP財団によって開発されたCycloneDXは、セキュリティワークフローとDevSecOpsパイプライン向けに最適化されています。脆弱性メタデータや依存関係グラフ用のフィールドが含まれており、OWASP Dependency-Trackなどのツールとの連携も良好です。

SBOMフォーマットの概要

コンテナイメージを作成する場合は、まずSPDXから始めましょう。これはBuildKitがネイティブに生成するフォーマットなので、追加のツールを一切使わずにビルド出力としてSBOMを取得できます。お使いの下流のスキャンツールによっては、CycloneDXを好む場合もありますが、それは問題ありません。この2つのフォーマットは相互運用可能であり、両者間でデータを変換するためのコンバーターも存在する。ビルド時にSPDXを生成させ、必要に応じて利用ツールが変換処理を行うようにする。

SBOMがコンテナワークフローにどのように組み込まれるか

従来のソフトウェア開発では、SBOM（ソフトウェア部品表）は多くの場合、事後的に作成され、リリース時のコンプライアンス成果物として後付けされる。コンテナワークフローは、より良いアプローチを提供します。それは、イメージ構築プロセスのネイティブ出力として、ビルド時にSBOMを生成することです。

ビルド時生成

BuildKitを使用してコンテナイメージを構築すると、ビルダーは最終的なイメージのファイルシステムをスキャンし、Dockerfileで宣言された内容だけでなく、実際に出荷された内容を反映したSBOMを生成します。すべてのビルド段階が完了した後の解決済み状態をキャプチャするため、OSレベルのパッケージ、アプリケーションレベルの依存関係、および外部ソースからコピーされたすべてのファイルが含まれます。

ビルド前にマニフェストファイルから生成されるソースレベルのSBOMでは、推移的な依存関係やシステムパッケージが欠落していることがよくあります。画像レイヤーのSBOMは現実を反映している。

証明と由来

SBOMは、画像に含まれる部品を示します。来歴証明書は、それがどのように構築されたかを示します。つまり、どのビルダーが、どのソースコミットで、どのビルドプラットフォームで構築されたかということです。これらを合わせると、監査担当者や政策立案機関がプログラム的に評価できる、検証可能な証拠の連鎖が形成される。これはSLSA（ソフトウェア成果物のサプライチェーンレベル）で説明されているモデルであり、ビルドレベル3では、改ざん不可能な来歴を持つ強化されたビルドプラットフォームが要求されます。SLSAは仕様書であり、 in-totoはSLSAが使用する認証フォーマットである。

SBOM自体は、SPDX述語フォーマットを使用して、完全な証明としてイメージに添付されます。出所情報も同様の方法で添付されるため、どちらも検証可能な機械可読メタデータとして画像とともに伝達されます。

レジストリストレージ

画像とその裏付けとなる情報が構築されたら、消費者がアクセスできる場所に掲載する必要がある。イメージをOCI準拠のレジストリにプッシュすることで、SBOMはそれが記述するアーティファクトと同じ場所に保持されます。これは重要な点です。なぜなら、別のシステム、共有ドライブ、コンプライアンスポータル、またはCIアーティファクトバケットに存在するSBOMは、最終的に生成元のイメージとの同期がずれてしまうからです。同一場所に設置することで、そのギャップが解消されます。イメージを取り出すと、そのSBOM（ソフトウェア部品表）と来歴情報も同時に取り出せます。

連続スキャン

SBOMをイメージに添付してレジストリに保存することで、継続的な脆弱性監視のための入力データとして活用できます。新しいCVEは、イメージ自体を再解析することなく、SBOMに記載されているコンポーネントと照合されます。新たな脆弱性が明らかになった際に、すべての画像を再スキャンする代わりに、スキャナーはSBOM（ソフトウェア部品表）のインベントリを相互参照し、影響を受ける画像を即座に特定します。

政策執行

スキャンによってリスクを特定します。執行機関はそれに基づいて行動する。ポリシーエンジンはSBOMデータを利用して、チームが定義したルールに基づいてデプロイメントを制御できます。例えば、承認されていないサプライヤーからのパッケージが含まれている場合はイメージを出荷しない、サポート終了コンポーネントが定義された猶予期間を超えて残存しない、一致するSBOM証明書がないイメージをデプロイしない、といったルールです。

これらのチェックはCI（継続的インテグレーション）で自動的に実行され、SBOM（部品表）を単なる受動的な文書から能動的なゲートへと変えます。問題のある依存関係を見つけるために、手動レビューに頼る必要はなくなりました。パイプラインは、画像が本番環境に到達する前にそれを検知します。

SBOMの成熟度：貴社はどの段階にありますか？

SBOMの導入は二者択一の問題ではない。ほとんどの組織は、場当たり的な組織から本格的な規模の組織まで、幅広い範囲のどこかに位置する。以下の成熟度モデルは、チームが現状を把握し、次に優先すべき事項を評価するのに役立ちます。

Omdiaの2026ソフトウェアサプライチェーンセキュリティ調査によると、SBOMを作成している組織の半数以上が、ケースバイケースでのみ作成していることが明らかになった。 

SBOMに関するよくある誤解

SBOMは単なるコンプライアンスチェック項目に過ぎない

調達要件を満たすためだけにSBOMを作成するチームは、運用上の価値を見落としている。SBOMは、脆弱性管理、インシデント対応、依存関係追跡のためのリアルタイムデータソースとして最も有用です。監査のために一度だけ作成され、その後保管されたSBOMは、網羅性があるという誤った認識を与える。

SCAと同じです

ソフトウェア構成分析（SCA）ツールは、コードやイメージをスキャンして既知の脆弱性を検出します。SBOMとは、そのスキャンを可能にする在庫のことです。SCAとSBOMは一般的に連携して機能します。SBOMは在庫リストであり、SCAツールはその在庫リストを使用し、多くの場合独自の在庫リストを作成して、既知の脆弱性をチェックします。この区別が重要なのは、スキャン精度は、その背後にある在庫の質に左右される傾向があるからだ。

SBOMは一度限りの成果物です

SBOMは特定のイメージダイジェストに関連付けられています。イメージを再構築するたびに、依存関係の変更を反映させるためにSBOMを再生成する必要があります。古いSBOMは、実行されていると思われるものと実際に展開されているものとの間にギャップを生み出します。自動ビルド時生成により、このずれは解消されます。

SBOMはランタイムセキュリティの代替手段となる

SBOM（部品表）には、出荷された製品が記載されています。それらは実行時に何が起こっているかを教えてくれません。SBOMは、まだ公開されていないゼロデイ脆弱性を検出したり、実行中のコンテナ内の異常なプロセス動作を検出したり、アプリケーションロジックが正しいことを検証したりすることはできません。SBOM（部品表）は、多層防御モデルにおける一つの層であり、在庫と構成を管理する。実行時監視、ネットワークポリシー、およびアクセス制御が残りの部分を処理します。

SBOMがないと何が問題になるのか

広く使われているライブラリにゼロデイ脆弱性が発見されたとしましょう。SBOMがない場合、セキュリティチームは手動でのトリアージを開始します。つまり、Dockerfileをチェックしたり、レジストリを照会したり、開発者にどのバージョンを使用しているかを尋ねたりします。時間が過ぎた。影響を受けるパッケージが3階層にわたる推移的依存関係にあるため、一部のイメージが欠落しています。爆発範囲が地図に示された時点で、その脆弱性はすでに2日間公表されていた。

SBOM（ソフトウェア部品表）がすべての画像に添付されているため、同じトリアージ作業が数分で完了します。SBOMデータベースに対して影響を受けるパッケージとバージョンを照会し、それを含むすべてのイメージのリストを取得し、展開状況に基づいて修復の優先順位を決定します。

SBOMの入門

チームが犯しがちな最も一般的な間違いは、SBOMの導入をワークフローを阻害する大規模な変革プロジェクトとして捉えてしまうことです。そうである必要はない。

• まずは一枚の画像から始めましょう。生産イメージを選択し、次回のビルドでSBOM生成を有効にします。BuildKitでは、それは単一のフラグで済みます。

出力結果を確認してください。このたった1つの手順で、イメージ内に含まれているとは知らなかった推移的な依存関係やOSパッケージが明らかになることがよくあります。

• CIにおける生成を自動化する。このフラグをCIパイプラインに拡張することで、すべてのイメージビルドでSBOMが自動的に生成されるようになります。
• 部品表（SBOM）は画像と一緒に保管してください。SBOMをOCIレジストリの証明書として添付することで、SBOMが記述対象のアーティファクトと同じ場所に保持されます。
• 監視システムに接続します。SBOM（部品表）を脆弱性監視ツールに入力し、コンポーネントを新しいCVE（共通脆弱性識別子）と継続的に照合できるようにします。これにより、在庫と行動の間のループが閉じられます。
• 方針を設定する。許容範囲を定義する：最大CVE経過期間、必要なSBOMの最小完全性、ブロックされたライセンス。これらのポリシーをパイプラインで強制適用し、準拠していないイメージがデプロイ前に検出されるようにします。

可視性を確保して構築し、自信を持って出荷する

SBOM（ソフトウェア部品表）は、ソフトウェアサプライチェーンのセキュリティの基盤となるものです。それらは、不透明なソフトウェア成果物を、セキュリティチーム、コンプライアンス担当者、開発者など、誰もが利用できる透明で監査可能なインベントリに変換する。しかし、部品表（SBOM）だけでは十分ではありません。SBOMが製造時に生成され、出所証明と組み合わされ、新たな脅威に対して継続的に監視される場合に、真の価値が生まれます。

Dockerを使えば、このワークフローがネイティブに実現します。Dockerの強化イメージには、完全なSBOM、SLSAビルドレベル3の来歴情報、OpenVEXの脆弱性データ、およびすべてのイメージに対する暗号署名が付属しています。一方、 Docker Scoutは、イメージに添付されたSBOMデータに基づいて継続的な脆弱性監視を提供し、イメージポートフォリオ全体にわたって実用的な洞察を明らかにします。これらを組み合わせることで、チームは原材料の調達から生産までの検証可能な管理履歴を確保でき、手作業による組み立ては一切不要となる。

よくある質問

出典

Omdia、 「ソフトウェアサプライチェーンのセキュリティ確保：AI導入による開発規模拡大を支援する戦略的アプローチ」 、5月2026 。