SBOM（ソフトウェア部品表）とは？ソフトウェアサプライチェーンの新たな守り方と脆弱性管理の実務

2026.06.24

はじめに

現代のソフトウェアは多数の部品（コンポーネント）を組み合わせて構築されており、その構成を正確に把握できなければ、脆弱性への対処が後手に回ります。ソフトウェアサプライチェーンを狙った攻撃が深刻化するなかで、各部品の情報を一覧にまとめたSBOM（Software Bill of Materials）の活用が実務上の課題となっています。

SBOMは、ソフトウェアに含まれる構成要素を可視化し、脆弱性管理の起点となる仕組みです。本記事ではSBOMの定義や主要フォーマット、脆弱性管理の具体的な手順、さらに国内の評価制度との関係まで、実務に必要な知識を順を追って解説します。

SBOMの定義と基本構造

ソフトウェア部品表という考え方

SBOMとは、ソフトウェアを構成する部品の一覧を正式に記録した文書です。米国大統領令14028は、SBOMを「ソフトウェアの構築に使われたさまざまなコンポーネントの詳細とサプライチェーン上の関係を含む正式な記録」と定義しています（参照*1）。

たとえるなら、食品パッケージの成分表示のようなものになります。食品に何が含まれているかを消費者が確認できるように、ソフトウェアにどのような部品が使われているかを利用者や開発者が確認できる状態を目指しています。SBOMは組織間で共有されることを前提に設計されており、ソフトウェアサプライチェーンの参加者間で構成要素の透明性を高める役割を担います（参照*2）。

脆弱性をソフトウェア開発の段階から管理して混入を防ぐ手段として、SBOMの活用はグローバルに広がり始めています（参照*3）。つまりSBOMは完成後の点検だけでなく、開発プロセスそのものに組み込むことで効果を発揮する仕組みです。

SBOMに含まれる最小要素

SBOMには、機械が自動で読み取れる形式のメタデータが含まれます。具体的には、ソフトウェアパッケージとその中身を一意に識別する情報のほか、著作権やライセンスに関するデータも記載される場合があります（参照*2）。

米国NTIAが定めた最小要素は大きく3つの領域に分かれます。1つ目は「データフィールド」で、各コンポーネントについて追跡すべき基本情報を文書化するものです。2つ目は「自動化の支援」で、自動生成と機械可読性によってソフトウェアの生態系全体へ拡張できるようにします。3つ目は「運用プロセス」で、SBOMの要求・生成・利用に関する手順を定めるものです（参照*1）。

これら3領域を満たすことで、SBOMは単なる部品リストではなく、脆弱性管理やライセンス管理を自動化するための基盤として機能します。手作業に頼らず、ツールが自動で情報を読み取れる点が、従来の管理台帳との決定的な違いです。

SBOMが求められる背景

サプライチェーン攻撃の深刻化

ソフトウェアサプライチェーンを狙った攻撃は、信頼された配布経路を悪用するため検知が極めて難しいという特徴を持ちます。ソフトウェアの正規アップデートに不正なコードを混入させる手口では、利用者側が通常の更新と区別できません。過去には、攻撃者が世界的なネットワーク管理ツールの更新プログラムに不正コードを混入させ、1万8,000件弱の顧客に配信される大規模な事案が発生しました（参照*4）。

サプライチェーン全体でのセキュリティ対策は課題になっています。独立行政法人情報処理推進機構（IPA）は、委託元企業にとって委託先のセキュリティ対策が可視化しづらく、チェックリスト等の要求事項の適正性を担保することも難しい点を課題として挙げています（参照*5）。

SBOMはソフトウェアの構成要素を一覧化するため、特定の部品に欠陥が見つかった際、自社のどのシステムにリスクがあるかを素早く特定できます。サプライチェーン攻撃への備えとして、まず「中身を知る」ことが防御の出発点になります。

米国大統領令とNIST指針の影響

2021年に発令された米国大統領令14028は、連邦政府のサイバーセキュリティ強化を目的とし、SBOMの提出を調達要件に組み込みました。同令に基づき、連邦機関は調達行為に関連する場合、ソフトウェア製品やサービスの提供者に対して、NTIAの最小要素に準拠した機械可読のSBOMへのアクセスを求めるべきとしています（参照*1）。

NISTはこれと並行して、安全なソフトウェア開発のための枠組み（SSDF）をSP 800-218として公表しました。SSDFは、ソフトウェア開発ライフサイクルの各段階に統合できる高水準な開発手法をまとめたもので、リリースされるソフトウェアの脆弱性削減、未検知の脆弱性が悪用された場合の影響緩和、そして根本原因への対処による再発防止を目指しています（参照*6）。

米国での動きは、日本を含む各国の政策に波及しています。連邦政府への納入が求められる日本企業にとっても無関係ではなく、SBOMの整備は国際的な取引条件の一部になりつつあります。

主要フォーマットの比較と選び方

SPDXとCycloneDXの特徴

SBOMを記述する標準フォーマットとして、NTIAが認める形式にはSPDX、CycloneDX、SWIDの3つがあります。第三者から受け取ったSBOMが業界標準のフォーマットに準拠していることで、バージョンの自動取り込みと監視が可能になります（参照*1）。

SPDXはLinux Foundationが主導する国際標準で、ISO/IEC 5962として承認されています。SPDX、OpenChain、OpenSSFと連携した調査では、多くの組織がSBOMを自社のサイバーセキュリティ戦略の中核に据えていることが報告されています（参照*2）。一方、CycloneDXはOWASP Foundationが支援し、CycloneDX Core Working Groupが仕様の方向性や保守を担うSBOM標準です。サイバーリスク低減に向けたサプライチェーン機能に加え、ライセンス情報の扱いにも対応しています（参照*7）。

SPDXはライセンス情報の網羅性に強みがあり、CycloneDXはサプライチェーンリスクや脆弱性情報を扱う運用との相性を重視する場合に選択肢になります。自社が何を優先するかによって、選ぶべきフォーマットは変わります。

選定時の判断基準

フォーマットを選ぶ際にまず確認すべきは、取引先や調達先が指定する形式があるかどうかです。米国連邦機関との取引ではNTIAの最小要素に準拠したフォーマットが求められるため、SPDX・CycloneDX・SWIDのいずれかに対応する必要があります（参照*1）。

取引条件としての指定がない場合は、自社の目的に合わせた判断が求められます。脆弱性管理を主目的とするならCycloneDXの軽量な構造が適しており、オープンソースのライセンス遵守を重視するならSPDXの網羅的な記述が有利です。いずれの場合も、ツールによる自動生成と機械可読性に対応していることが前提条件となります。

複数のフォーマットを相互変換するツールも存在するため、将来的な取引先の要件変化に備えて、変換可能な運用体制を想定しておくことが実務上のポイントです。

SBOMを用いた脆弱性管理の手順

SBOM生成から脆弱性照合まで

脆弱性管理の第一歩は、自社のソフトウェアに含まれる構成要素を正確に把握することです。SBOMを活用する動きはグローバルに広がっており、ソフトウェア開発の段階から脆弱性の混入を防ぐことを目的としています（参照*3）。

具体的な流れとしては、まずビルド時やリリース時にSBOM生成ツールを実行し、ソフトウェアに含まれるすべてのコンポーネントとそのバージョンを一覧化します。次に、生成されたSBOMをCVE（共通脆弱性識別子）などの脆弱性データベースと照合し、既知の脆弱性が含まれていないかを確認します。NISTのSSDFは、リリースされるソフトウェアの脆弱性を削減し、未検知の脆弱性が悪用された際の影響を緩和する手法をまとめています（参照*6）。

この照合を開発パイプライン（ソフトウェアの構築から配布までの自動化された一連の工程）に組み込むことで、脆弱性を含んだ部品がリリースされる前に検出できます。手動による確認ではなく、自動的かつ継続的に照合が行われる体制の構築が、脆弱性管理を実効性あるものにします。

トリアージと修正パッチ適用

脆弱性が検出された後に必要なのは、対応の優先順位を決めるトリアージ（選別）です。すべての脆弱性を同時に修正することは現実的ではないため、リスクの大きさや悪用の可能性に応じて対処の順番を定めます。

脆弱性対策は「気づいた時にアップデートする」という対応では不十分であり、管理プロセスとして組織に定着させる必要があります。ある評価基準では、高リスクな脆弱性が公表された場合に修正パッチを14日以内に適用することが指標の一つとして示されています（参照*8）。

SBOMがあれば、脆弱性が公表された部品を使用しているシステムを即座に特定でき、トリアージの判断材料が揃います。パッチ適用までの期限を社内ルールとして明文化し、SBOMの更新と連動させることで、脆弱性管理は場当たり的な作業から組織的な仕組みへと変わります。

国内政策と評価制度の動向

経産省SBOM導入手引ver2.0の要点

経済産業省はSBOM導入に関する手引ver2.0を公表し、ソフトウェアサプライチェーンの透明性確保と脆弱性管理プロセスの整備を推進しています（参照*9）。この手引は、SBOMを導入する際の手順や留意点を具体的に整理したもので、国内企業が取り組みを始める際の指針として位置づけられます。

手引ではソフトウェアサプライチェーンの各段階でSBOMをどう生成・管理・共有するかが示されており、脆弱性の早期発見と対処を組織的に行うための道筋を提供しています。国内においては、経済産業省の動きがSBOM普及の推進力となっています。

SCS評価制度とSBOMの関係

2026年度に本格的な社会実装が開始される「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」は、統一された客観的基準による評価と「見える化」を促進する仕組みです。従来、企業は自社の判断でセキュリティ対策を実施し、取引先には個別のチェックシートで回答するという非効率な慣行が続いていました。SCS評価制度はこの状況を変え、マーク取得を通じて委託先のセキュリティ対策水準を可視化することを目的としています（参照*8）。

IPAはこの制度について、委託先へのサイバー攻撃を起因とした事業の提供途絶や機密情報の漏えいといったリスクに対し、適切なセキュリティ対策の実施を促すものと説明しています（参照*5）。一方、情報セキュリティ担当者700名を対象とした調査では、約7割が制度を十分に把握できていないものの、8割超が強い関心を示しているという結果も出ています（参照*10）。

SBOMはこの評価制度において、ソフトウェアの構成要素を客観的に示す根拠資料としての役割を果たします。制度への対応を見据え、SBOMの生成と管理を日常業務に組み込んでおくことが、今後の準備として求められます。

導入時の失敗例と注意点

SBOMの導入にあたって陥りやすい失敗の一つは、手作業に頼った運用です。手作業で資料を作成する運用では、評価時の負担が大きくなるだけでなく、継続的な対応も困難になります。ログや管理情報を日常的に取得・保管し、必要に応じて提示できる状態を整えることが現実的な対策です（参照*11）。

もう一つの落とし穴は、SBOMを「一度作って終わり」にしてしまうことです。ソフトウェアは更新のたびに構成要素が変わるため、SBOMもビルドやリリースのたびに再生成する必要があります。SBOMの導入が推奨される理由は、特定のプログラムに欠陥が発見された際に、自社のどのシステムにリスクがあるかを即座に特定できる点にあります（参照*4）。この利点を生かすには、常に最新の状態を維持する仕組みが不可欠です。

導入を成功させるには、SBOMの生成を開発パイプラインに自動で組み込み、脆弱性データベースとの照合も自動化する体制を構築することが有効です。手動の運用を残したままでは、SBOMがあっても実質的な脆弱性管理にはつながりません。

おわりに

SBOMはソフトウェアの構成要素を可視化し、脆弱性管理を組織的に進めるための基盤です。米国の大統領令やNISTの指針、そして日本の経済産業省が公表した手引やSCS評価制度の動きが示すように、SBOMの整備はすでに国際的な取引条件や国内の評価基準に組み込まれつつあります。

ソフトウェアサプライチェーンの安全性を維持するには、SBOMの生成・管理を日常の開発プロセスに定着させ、脆弱性への対処を仕組みとして回し続けることが欠かせません。自社の現状と本記事の内容を照らし合わせ、対応の優先順位を検討してみてください。

お知らせ

SBOMやソフトウェアサプライチェーン、脆弱性管理への理解は、インフラエンジニアが対応領域を広げるうえで重要な視点です。近年はサプライチェーンリスクへの関心が高まっており、関連知識を持つエンジニアの需要も拡大しています。

クラウド、ネットワーク、セキュリティ運用などの業務範囲を整理しながら、自身の経験がどのような案件で活かせるのかを確認してみましょう。あわせて、今後習得したいスキルやキャリアの方向性についても検討してみることをおすすめします。

cyseekではフリーランスのITエンジニア向けの案件をご紹介しています。
案件に関する新着情報は、以下のリンクからご覧いただけます。

参照

cyseekはサイバーセキュリティ人材向けの案件紹介サービスサイトです。

サイバーセキュリティ業界に精通したエージェントが求人紹介、年収交渉、キャリアアップの実現など、採用課題の整理から稼働後のフォローまでトータルにサポートするほか、保有するノウハウを活かしフリーランスやサイバーセキュリティ人材に向けたコラムを発信しています。