タグ: ASM

SBOM（Software Bill of Materials）は、ソフトウェアを構成するOSSやライブラリ、依存関係を可視化する「ソフトウェア部品表」です。本記事では、SBOMの基本から注目される背景、OSS脆弱性管理やソフトウェアサプライチェーン対策との関係、企業が導入すべき理由まで分かりやすく解説します。

はじめに

ソフトウェアの安全性を考えるうえで、近年急速に重要性が高まっているのがSBOM（Software Bill of Materials）です。日本語では「ソフトウェア部品表」とも呼ばれ、ソフトウェアを構成するライブラリ、モジュール、依存関係、供給元などを整理して把握するための考え方として広がっています。背景にあるのは、企業システムの多くが自社開発のコードだけで成り立っているわけではなく、OSS、外部コンポーネント、パッケージ、クラウドネイティブな部品を組み合わせて構築されている現実です。そのため、どのソフトウェアに何が含まれているのか分からない状態では、脆弱性対応もソフトウェアサプライチェーン対策も後手に回りやすくなります。NIST（米国立標準技術研究所）ではSBOMについて、「ソフトウェアを構築するために使われた各種コンポーネントとサプライチェーン上の関係を記録した正式な記録」と説明しています*5https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1。

SBOMは単なる開発者向けの技術資料ではありません。新しい脆弱性が公開されたときに、自社のどのシステムが影響を受けるのかを素早く把握するための基盤であり、調達先のソフトウェアを評価するための材料でもあり、継続的な脆弱性管理を支える台帳にもなります。NTIA（米国商務省電気通信情報局：National Telecommunications and Information Administration）は、「SBOMの最低要件が脆弱性管理、ソフトウェア在庫管理、ライセンス管理といった基本的なユースケースを可能にする」と整理しています*2https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom。つまりSBOMは、単に「何が入っているか」を眺めるための一覧ではなく、ソフトウェアの透明性を高め、セキュリティ運用を速く正確にするための実務ツールです。

SBOMとは

SBOMとは、ソフトウェアを構成する部品の一覧とその部品同士の関係を示す情報のことです。食品に原材料表示があるようにソフトウェアにも、何でできているかを示す考え方が必要だという発想で語られることが多く、NISTもその比喩を用いて説明しています。SBOMに含まれる情報としては、コンポーネント名、供給元、バージョン、識別子、依存関係などが代表的です。

ここで重要なのは、SBOMがソースコード一覧そのものではない、という点です。SBOMは完成したソフトウェアや提供される製品・サービスの中に、どのような構成要素が含まれているかを把握するためのものです。特にオープンソースソフトウェア（OSS）を多用する現代の開発では、直接利用しているライブラリだけでなく、その先の依存関係まで含めて把握することが欠かせません。自社が書いていないコードであっても、最終的に自社サービスの一部として動作している以上、その脆弱性やライセンス、供給元リスクに無関心ではいられません。SBOMは、その見えにくい構成を可視化する手段です。

なぜ今SBOMが注目されているのか

SBOMが注目されている最大の理由は、ソフトウェアサプライチェーンの複雑化です。現在の企業システムは、内製コードだけで完結することが少なく、OSSライブラリ、サードパーティ製コンポーネント、外部サービス、コンテナイメージなどの積み重ねで成り立っています。その結果、脆弱性が発見されたときに自社に関係あるのかがすぐに分からないケースが増えています。SBOMがあれば、影響を受けるコンポーネントの有無を確認しやすくなり、初動のスピードを上げやすくなります。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）もSBOMを、「ソフトウェア透明性とサプライチェーンセキュリティを支える重要な要素」として扱っています*3https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom。

また、脆弱性対応の現実もSBOMが注目される理由の一つです。脆弱性情報は日々公開されますが、公開情報だけを見ても、自社のどのシステムにその部品が含まれているか分からなければ、対応判断が遅れます。NTIAはSBOMのユースケースとして脆弱性管理を明示しており、CISAもSBOMの実務活用をサプライチェーン防御の一部として位置付けています*4https://www.ntia.gov/blog/2021/ntia-releases-minimum-elements-software-bill-materials。つまりSBOMは、脆弱性情報を受け取ったあとに本当に役立つ資産側の台帳として価値を持ちます。

SBOMで分かること

SBOMを整備すると、まずソフトウェアに含まれるコンポーネントの全体像が見えるようになります。どのOSSライブラリが使われているか、どのバージョンか、どの供給元に由来するか、どう依存しているかが分かれば、新しい脆弱性が公表されたときの影響調査が大幅にしやすくなります。また、ライセンス確認や調達先評価、保守対象の整理にも役立ちます。NTIAは、SBOMが脆弱性、在庫、ライセンスの管理に資することを明確に示しています。

さらにSBOMは開発部門だけでなく、運用部門、調達部門、セキュリティ部門にとっても意味があります。開発部門にとっては依存関係の可視化、運用部門にとっては影響調査の迅速化、調達部門にとってはベンダー製品の透明性確認、セキュリティ部門にとっては脆弱性管理の効率化につながります。NISTがSBOMを「サプライチェーン上の関係を含む正式な記録」として位置付けているのは、こうした部門横断の活用が前提にあるからです。

SBOMとOSS脆弱性管理の関係

SBOMが特に力を発揮するのは、OSS脆弱性管理の場面です。近年のソフトウェアは、多数のOSSコンポーネントに依存していますが、問題はその依存関係が深くなりやすいことです。開発者が直接追加したライブラリだけでなく、その先にぶら下がる間接依存まで含めると、構成は想像以上に複雑になります。そのためSBOMがない状態では、ある脆弱性が自社に影響するのか、どのアプリケーションに含まれているのか、を迅速に判断しにくくなります。SBOMはその複雑さを整理し、脆弱性対応の起点を作る役割を果たします。

この点で、SBOMはSCA（Software Composition Analysis）と相性が良い考え方です。SCAはソフトウェアの依存関係を解析し、既知脆弱性やライセンス情報を確認するための仕組みですが、その結果を継続的に管理しやすくするうえでSBOMが有効です。つまりSCAが見つけるための仕組みだとすれば、SBOMは構成を記録し、影響を追いやすくするための仕組みと捉えると分かりやすいです。SBOMそのものが脆弱性を自動で直すわけではありませんが、どこに何が入っているかを把握できるだけでも、対応の速度と精度は大きく変わります。

SBOMの代表的な形式と標準

SBOMを実務で扱うには、機械可読な形式が重要です。NTIAの minimum elements でも、自動化を支える仕組みが重要な要件のひとつとして示されています。手書きの一覧表では更新に追いつかず、脆弱性情報との突合も難しいためです。実務で広く知られている代表的な形式としては、OWASP CycloneDX (ECMA-424)やSPDXが挙げられます。少なくともCycloneDXは、サイバーリスク低減のためのフルスタックのBill of Materials (BOM)標準として位置付けられており、現在はECMA-424として標準化されています。

形式選定で重要なのはどちらが絶対に優れているかではなく、自社の利用目的に合っているかです。開発パイプラインに組み込みやすいか、既存ツールと連携しやすいか、脆弱性管理やライセンス管理に使いやすいか、といった観点で選ぶのが現実的です。標準形式を使うことで、ツール間連携や取引先との情報共有もしやすくなります。

企業がSBOMを導入すべき理由

企業がSBOMを導入すべき理由は明快です。第一に、脆弱性対応が速くなるからです。新しいCVEが出たときに、対象部品が自社のどこに入っているかを確認しやすくなれば、影響調査の時間を短縮できます。第二に、ソフトウェアサプライチェーンの透明性が高まるからです。外部から調達したソフトウェアについても、何が含まれているかが分かれば、評価や説明責任を果たしやすくなります。第三に、継続的なソフトウェア資産管理に役立つからです。NTIAもこうしたユースケースをSBOMの基本的価値として整理しています。

加えて、SBOMはこれからの脆弱性管理の前提になりつつあります。クラウドネイティブ化や DevSecOpsが進むほど、ソフトウェア構成は動的になり、人手だけで追うのは困難になります。NISTもソフトウェアサプライチェーン対策の中でSBOMを含む各種能力の実装を推奨しており、CISAもSBOM消費の実践をサプライチェーン強化の一部として扱っています。SBOMは流行語ではなく、複雑化したソフトウェア環境を管理するための土台になりつつあると考えたほうがよいでしょう。

SBOM導入時の課題

もっともSBOMは作れば終わりではありません。実際の課題はどう作るかよりも、どう更新し、どう使うかにあります。ソフトウェアは日々更新されるため、一度作成したSBOMを放置するとすぐに実態とずれます。またSBOMがあっても、脆弱性情報や資産台帳、SCA、CI/CDと連携していなければ、実務で十分に生きません。CISAの近年のガイダンスもSBOMの生成だけでなく消費、つまり実際の運用への組み込みを重視しています。

そのため導入では、まず重要システムや外部公開サービスなど、影響の大きい範囲から始めるのが現実的です。CI/CDでSBOMを自動生成する仕組みを作り、SCAや脆弱性管理フローと結び付けて、脆弱性情報公開時にすぐ影響確認できるようにする。この流れができて初めて、SBOMは単なる提出資料ではなく、日常運用で役立つ仕組みになります。

まとめ

SBOMとは、ソフトウェアを構成する部品とその関係を記録する「ソフトウェア部品表」です。OSS利用の拡大やソフトウェアサプライチェーンの複雑化により、どのシステムに何が含まれているのかを把握する重要性はこれまで以上に高まっています。SBOMを整備することで、脆弱性対応の初動を速め、影響調査を効率化し、ソフトウェアの透明性を高めやすくなります。NTIA、NIST、CISAがいずれもSBOMを重要視しているのは、その実務的な価値が明確だからです。特にSBOMは、SBOMとは何かを理解するだけでは不十分で、脆弱性管理、SCA、CI/CD、調達管理とどう結び付けるかが重要です。企業が導入を考える際は、形式やツール選定だけでなく、更新運用と活用場面まで見据えて設計する必要があります。これからのセキュリティ運用では、SBOMは一部の先進企業だけのものではなく、ソフトウェアを安全に使い続けるための基本装備に近づいています。

SBOMは脆弱性対応やソフトウェアサプライチェーン対策を効率化するための重要な仕組みです。ただしSBOMを整備するだけでは十分ではなく、継続的な脆弱性管理が重要になります。企業が行うべき脆弱性管理の基本や実践フローについては、以下の記事で詳しく解説しています。
「脆弱性管理とは？企業が行うべき脆弱性管理の基本と実践手順【2026年版】」

【関連ウェビナーのご案内】
本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理しました。次回、5月20日（水）14時からの開催のウェビナーでは、AssetViewとFutureVulsのメーカーが登壇し、各領域の役割をどのように整理し、どのように連携させれば実効性ある脆弱性管理が実現できるのか、解説します。脆弱性管理の考え方について深くを理解されたい方は、ぜひご参加ください。

その他のウェビナー開催情報はこちら

BBSecでは

BBSecでは以下のようなご支援が可能です。 お客様のご状況に合わせて最適なご提案をいたします。

自ステムの状態を知る

SQAT^®脆弱性診断サービス

サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報（OSINT）を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

編集責任：木下

Security NEWS TOPに戻る
バックナンバー TOPに戻る

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。