トップ>テクノロジー>ソフトウェアの成分表示？SBOM管理の課題とSSVC・AIを用いたベストプラクティス

SBOM（Software Bill of Materials）とは、ソフトウェアに含まれるコンポーネントの一覧表であり、近年の法統制によりその管理が求められています。本記事では、SBOM管理の必要性と現状の認知度についてお話しします。また、SSVCによる脆弱性評価とAIを活用した、効率的なSBOM管理のベストプラクティスについて解説いたします。

はじめに

この記事は、NTT docomo Business Advent Calendar 2025 11日目の記事です。

こんにちは！イノベーションセンターMetemcyberプロジェクトの千坂知也と申します。

Metemcyberプロジェクトは10/9（木）～10/10（金）に開催されたdocomoBusinessForum'25[1]にて、開発中のSBOM（Software Bill of Materials）管理ソリューション「Threatconnectome」^*1を展示させていただきました。多くのお客さまにご来場いただき、SBOM管理が必要のある現場での課題感などを議論させていただきました。

そこで感じたのは法統制などによりSBOM管理が求められていることは、ある程度周知されている一方で、その管理方法やなぜ必要とされているのかの認知が広がっていないということでした。

以上のことから本記事では、SBOM管理の必要性と現場での課題感、個人的に思う現状のベストプラクティスについて書いていこうかと思います。以降では、次の3つについて述べていきたいと思います。

SBOM（Software Bill of Materials）とは
SBOM管理の法統制が進む背景
現状考えうるベストプラクティス

SBOM（Software Bill of Materials）とは

SBOMとはSoftware Bill of Materialsの略であり、日本語では「ソフトウェアの部品表」という意味になります。製造業の方にはソフトウェアのBOMと言えば分かりやすいかもしれません。今日、多くのシステムに組み込まれているソフトウェアはさらに小さな複数のソフトウェアを組み合わせて構成されています。これらはコンポーネントと呼ばれ、パッケージ、ライブラリなどが該当します。SBOMはこれらソフトウェアのコンポーネントの一覧表のことを指します。各コンポーネントの名称、バージョン情報、ライセンス情報に加え、コンポーネント間の依存関係なども含まれます。

我々Metemcyberプロジェクトでは、よくこのSBOMを「食品の成分表示」と同じというふうに説明いたします。皆さんがスーパー・コンビニなどで買う食品の裏には必ずどのような原材料・成分が含まれているかを表す成分表示が書かれています。この成分表示をみて、自身にとってアレルギーのものが含まれていればその食品は買わない、などの判断ができるわけです。

ソフトウェアも中に含まれている成分（コンポーネント）表示から、危険なもの（脆弱性が含まれているパッケージなど）が含まれているのではないかを検知できるというわけです。

SBOMの認知度

MetemcyberプロジェクトがdocomoBusinessForum’25にてThreatconnectomeを展示させていただき、多くのお客さまと議論を交わしたなかで、次のようなお声を多く耳にしました。

「（SBOMという）言葉自体は聞きかじったことある」
「最近SBOMというワードをよく聞きます」
「法統制でSBOM対応が迫られているのは知っている」
「SBOMで管理しろっていわれても具体的にどうすればよいかわからない」
「結局なんで必要なのかが分からない」

言葉自体の認知度はやや上がりつつあるものの、具体的にSBOMが何なのか、SBOM管理と言われても何をしたら良いのか分からない、といった程度の認知度であることをひしひしと感じました。ベリサーブ社が国内製造業の設計開発部門および品質管理部門の担当者を対象に実施したSBOMの導入状況アンケート[2]では、「導入予定はない」は79％であり、「導入検討中」は14％、「導入済み」は7％と依然として導入へは課題があります。

SBOM法統制とガイドライン

SBOM管理は米国での2021年の大統領令[3]を皮切りに世界的に法規制が進んでいます。EUでは2024年のサイバーレジリエンス法（Cyber Resilience Act：CRA）^*2[4]にてSBOM対応が必須要件となり、日本でも医療機器のサイバーセキュリティ手引書[5]でSBOMに関する言及が多くあります。

ガイドライン面においても、経済産業省が2023年7月にSBOM導入のメリットと活用プラクティス[6]を公開し、内閣サイバーセキュリティセンター[7]も2024年7月の改訂で調達基準へのSBOM導入の可能性に言及しています。デジタル庁も2024年1月に政府情報システムでのセキュリティバイデザインの手段としてSBOM[8]を推奨しました。

さて、そもそもなぜこのような法統制が進んできているのでしょうか？

SBOM管理の法統制が進む背景

SBOM管理が必要になった背景には、以下の２点があると考えています。

OSS（オープンソースソフトウェア）の急速な普及
発見される脆弱性の爆発的な増加（OSSへのサプライチェーン攻撃の増加）

OSS（オープンソースソフトウェア）の急速な普及

近年の商用ソフトウェアは、コードベースの平均で70％以上、システムによっては90％近くがOSS由来のコンポーネントで構成されている[9]といわれています。OSSはソースコードが公開され、改変・再配布が可能であるため、既存の機能を活用することで開発コストの削減や生産性向上に大きく寄与します。

しかし、OSSもソフトウェアである以上、脆弱性の存在する可能性があります。実際、2021年12月にはApache Log4jというOSSにおいて、Log4Shellと呼ばれる非常に深刻な脆弱性[10]が発見され、Amazon AWSやiCloud、Steamなど世界規模のサービスにまで影響が及びました。こうした重大な脆弱性に迅速に対応するためには、まず自社システムがどのOSSを利用しているかを正確に把握することが不可欠です。把握していなければ、適切な修正や封じ込めは困難になります。

また、現代のソフトウェアの多くは、表面からは見えないOSSやライブラリで構成されており、開発者でも「何が含まれているか」を完全に把握するのは難しい状況です。そのため、SBOMを活用することで、こうした隠れた依存関係を可視化し脆弱性対応を効率的に行うことが可能になると考えられています。

発見される脆弱性の爆発的な増加

情報システムの技術的な発展に伴い、ソフトウェアは社会システムの基盤そのものを構成するようになりました。一方で、技術の進歩と単純なソフトウェアの数の増加により、そこに含まれる脆弱性も急速に増加しています。CVE[11]の登録件数を見ても、ここ10年で著しい増加が続いており、2025年においては、すでに昨年を上回る件数が登録されています。前述した通り、このことの背景にはOSSの普及によって膨大な量のソフトウェアが複雑な依存関係を持つようになったことが関連しています。そのため、脆弱性に迅速かつ確実に対応するために、SBOMが不可欠になってきているということです。

これらの要因からSBOM管理は法整備されつつあるというわけです。

しかしながら、SBOMによってソフトウェアの中身の見える化を図ったとしても、結局どのように脆弱性対応に当たればよいかが現時点で明確化されていないという実情があります。膨大すぎる成分表示を渡されても、その中身が危険かどうかを判断するためのプラクティスが確立されていないのです。

現状考えうるベストプラクティス

１つは対応する脆弱性のトリアージを行うということが挙げられます。ソフトウェアにもよりますが、SBOMに含まれるコンポーネントの数は、一般的には数千～数万にも及びます。それらの脆弱性全てに対応しようとすると、とても現実的な時間では不可能です。一方でソフトウェアに含まれている脆弱性は対応を無視しても全く問題のないものが大多数です。組織や人命にとって重大な被害を及ぼしかねない脆弱性のみをピックアップして迅速に対応していくことが重要になってきます。

もう１つは、常に最新の脆弱性と同期させ、その脆弱性による組織内への被害の影響がどの程度の範囲に及ぶのかを把握しておく必要があるということです。前述した通り、新たな脆弱性は日々見つかっており、それが組織固有のシステムに影響を及ぼす可能性があります。どの組織のシステムにも甚大な被害を及ぼしかねない危険性が含まれているかもしれないのです。

これら２つのプラクティスを実践するためにSSVCという脆弱性の評価の指標を利用することと、AIによる自動化が有効であると我々Metemcyberプロジェクトは結論付けています。従来、脆弱性評価に多く用いられてきたCVSS（Common Vulnerability Scoring System）[12]という指標は脆弱性そのものの性質のみを見て評価をしているため、同じCVSSスコアでも、組織によって「対応の優先度」が変わり、対応方針までは決められません。SSVC（Stakeholder-Specific Vulnerability Categorization）[13]は「誰（どのステークホルダー）」が意思決定をするかを前提に設計された脆弱性評価の指標です。この評価指標は人命への影響度、悪用された場合の組織への影響度、利用システムのインターネットへの公開状況などをパラメータとして最終的な脆弱性の危険度を評価します。これらのパラメータを用いることで出力された脆弱性危険度はその組織のこのシステムを対象にこの程度の範囲で影響が出るという、具体的な評価を下します。さらにAIによって事前に該当ソフトウェアが組み込まれているシステムの組織的な位置づけ（利用目的など）から上記パラメータを推定できれば、人力でのSBOM管理の手間はより低減されると考えております。このような手段を用いて、脆弱性のトリアージを行うというのがベストプラクティスなのではないでしょうか。

上記の理由により、私たちMetemcyberプロジェクトではSSVCによる脆弱性評価を用いた脆弱性のトリアージがSBOM管理と相性の良いものであるというふうに考えており、さらにAIによる自動化を図ることでこれから求められつつあるSBOM管理のベストプラクティスを提示しようとしています。

まとめ

本記事では現場におけるSBOMの認知度と課題感、および現状考えうるベストプラクティスについて書かせていただきました。SBOMということ自体は聞きかじったことのあるものの、その具体的な内容や管理・運用の仕方がまだ分からないという方が多いというのが実情です。前述したとおり、我々Metemcyberプロジェクトでは、SSVCと呼ばれる脆弱性評価の指標をもとに脆弱性のトリアージをしつつSBOMを管理できるソリューション「Threatconnectome」を開発しております。ご興味がある方はぜひThreatconnectomeのGitHubページなどもご覧ください。

以上でAdventcalendar11日目の記事は終了です！明日もお楽しみに！