SBOM（Software Bill of Materials／ソフトウェア部品表）とは、ソフトウェアがどのような部品で作られ、それぞれがどう依存し合っているかを一覧にしたものです。
現在のソフトウェアの多くは、OSSや外部ライブラリを数多く組み合わせて開発されています。そのため中身が見えにくい「ブラックボックス」になりがちで、脆弱性が公表されても自社が影響を受けるのか判断できないという問題が生じています。SBOMを整備すれば、こうしたソフトウェアの中身を見える化し、脆弱性やライセンス違反のリスクを効率よく管理可能です。
本記事では、SBOMについて以下の内容を解説します。
- SBOMの概要とできること
- SBOMが注目される背景
- SBOMのメリットと導入時の課題
- SBOMを導入・運用する流れとツール選びのポイント
本記事を読むことで、SBOMがなぜ求められているのか、自社に必要かどうかを判断する材料が得られます。SBOMだけではカバーしきれないWebアプリの脆弱性対策についても紹介するので、ソフトウェアのセキュリティ強化を検討している企業の方はぜひご一読ください。
SBOMとは？
SBOM（ソフトウェア部品表）とは、ソフトウェアがどのような部品（コンポーネント）で作られ、それぞれがどのバージョンで、どのように依存し合っているかを一覧にしたものです。
現在のソフトウェアの多くは、オープンソースソフトウェア（OSS）や外部のライブラリを数多く組み合わせて開発されています。そのため、完成したソフトウェアを外から見ただけでは、内部にどの部品が使われているのかを把握しづらく、中身の見えにくいブラックボックスの状態になりがちです。それが、脆弱性への対応やリスク管理を難しくする一因となっています。
このような見えない中身を見える化する仕組みとして有効なのがSBOMです。私たちの身近なものにたとえるなら、食品のパッケージに記載されている「原材料表示」が近いでしょう。アレルギーの原因となる成分が含まれていないか表示を見て確認するように、ソフトウェアの世界でもSBOMがあれば、脆弱性情報のデータベースと照らし合わせて危険な部品が含まれていないかを洗い出せるようになります。
SBOMでできること
SBOMを整備しておくと、ある部品に新たな脆弱性が見つかったとき、自社の製品やシステムに該当する部品が含まれているかを速やかに確認できるようになります。どの部品がどこで使われているかが一覧化されているため、影響範囲の調査を短縮できます。脆弱性を含む部品を早い段階で特定し、迅速に対処できる点は、SBOMの大きな強みです。
あわせて、それぞれの部品が持つライセンス情報も一覧で管理できます。ソフトウェアはOSSを組み合わせて作られることが多く、把握しきれないまま利用すると、意図しないライセンス違反につながるおそれがあります。SBOMで各部品のライセンスを見える化しておけば、こうした違反を未然に防ぎ、コンプライアンス面のリスクを抑えることが可能です。
SBOMに記載する主な項目としては、部品名やそのバージョン、部品同士の依存関係、SBOMの作成者や作成日時などが挙げられます。これらの情報がそろうことで、「どの部品が」「どのバージョンで」「どう組み合わされているか」を具体的に管理でき、脆弱性対策とライセンス管理の両方を効率よく進められるようになります。
SBOMが必要になるのはどんな企業か
ソフトウェアやWebサービスを開発・提供する企業はもちろん、外部から製品やシステムを調達して利用する企業にもSBOMは他人事ではありません。つまり、「開発する側」と「使う側」の双方にとって重要な仕組みです。自社でシステムを作る場合は構成要素を正確に把握するために必要となり、他社から導入する場合は安全性を確認するための材料として求められます。
とくに自動車や医療機器といった分野など、取引先から厳しいセキュリティ対応を求められやすい業界では、SBOMへの対応が前提になりつつあります。自社が直接ソフトウェアを販売していなくても、事業の中で何らかのシステムを運用しているなら、決して無関係ではありません。提供側か利用側かを問わず、自社のビジネス環境を安全に保つために有効なものだと考えておきましょう。
SBOMが注目される3つの背景
近年、SBOMが世界中で急速に注目を集めるようになりました。その理由として、サイバー攻撃の手法の変化や、国や公的機関による環境整備といった、以下の3つの背景が挙げられます。
- ソフトウェアサプライチェーン攻撃が増えている
- 米国大統領令がSBOM普及の起点になった
- 日本でも経済産業省が導入の手引きを公開した
ソフトウェアサプライチェーン攻撃が増えている
かつては企業ネットワークの入口を狙うサイバー攻撃が主流でしたが、企業の防御が固まるにつれてその手法は変化しています。近年はセキュリティ対策が厳重な正面入り口を避け、ソフトウェアの部品として組み込まれているOSS（オープンソースソフトウェア）などの弱点を突くソフトウェアサプライチェーン攻撃も増えています。
自社でセキュリティ対策を講じていても、取引先や日常的に利用している外部ソフトが侵害されることで、自社が攻撃の影響を受ける可能性があります。気づかないうちにシステム内へ侵入され、重要情報の漏えいといった深刻な被害につながる可能性もあります。
もし自社でどのOSSが使われているかを正確に把握できていなければ、問題が起きても迅速に対処することは困難です。だからこそ、システムの中身を可視化できる手段としてSBOMが注目されています。
▼関連記事
米国大統領令がSBOM普及の起点になった
SBOMが世界的に注目されるようになった大きなきっかけが、2021年5月にアメリカで発令された大統領令（EO 14028）です。これは国家のサイバーセキュリティ向上を目的としたもので、そのなかでソフトウェア・サプライチェーンのセキュリティ強化が重要な柱として位置づけられました。大統領令を受け、連邦政府が調達するソフトウェアのサプライチェーンセキュリティを強化する取り組みが進み、そのなかでSBOMの提供・活用が重視されるようになりました。
こうした動きの背景には、国家レベルの脅威と受け止められた大規模なサプライチェーン攻撃の存在があります。なかでも象徴的だったのが、2020年に発覚したSolarWinds事件です。多くの政府機関や大企業が利用するソフトウェアの更新プログラムに悪意あるコードが仕込まれ、正規のアップデートを通じて広範囲に被害が拡大しました。信頼して導入したソフトウェアが侵入経路になり得ると明らかになったことで、どの部品が使われているのかを把握しておくことの重要性が一気に高まったのです。
日本でも経済産業省が導入の手引きを公開した
SBOMを推進する世界的な流れを受けて、日本でも取り組みが進んでいます。経済産業省は2023年7月に「ソフトウェア管理に向けたSBOMの導入に関する手引」を公開しました。この手引きは、深刻さを増すソフトウェアの脅威に対応し、企業が効率的にSBOMを導入できるようにすることを目的として策定されました。
手引きの特徴は、SBOMを導入することで得られるメリットと、導入時に押さえておくべきポイントが、フェーズごとに整理されている点です。手順が体系立てて示されているため、これからSBOMに取り組む企業でも、何から始めればよいかを把握しやすくなっています。
SBOMの代表的なフォーマット
SBOMにはいくつかのフォーマットが存在し、目的や業界に応じて使い分けられています。主に以下の3つが代表的です。
- SPDX
- CycloneDX
- SWIDタグ
SPDX
SPDXは、オープンソースの普及を推進するLinux Foundationという団体が中心となって作ったSBOMの標準規格です。世界中で広く活用されており、国際規格としても正式に承認されています。そのため、グローバルなビジネスを展開する際にも、安心して利用できるフォーマットだと言えるでしょう。
SPDXが持つ最大の特徴は、各ソフトウェア部品のライセンス情報や著作権について、非常に細かく記述できる点です。構成要素だけでなく権利関係も記録できるため、法務での確認やIT資産管理を重視する場面で大きな強みを発揮します。とくに、意図しないライセンス違反を防ぎたい企業や、厳格な権利管理が求められる業界での導入に向いています。
CycloneDX
CycloneDXは、OWASPが推進している軽量なフォーマットです。国際規格としても承認されており、とくにセキュリティの強化を重視して作られています。システムを構成する部品の一覧に加え、脆弱性情報や、対象製品における悪用可能性を示すVEXなどの情報を表現できます。
そのため、ソフトウェア開発現場におけるリスク管理の仕組みと非常に相性が良く、安全性の確認をスムーズに進められるでしょう。対応ツールや脆弱性情報と連携することで、脆弱性の把握から影響調査、優先順位づけまでを進めやすいため、セキュリティ対策を重視する開発チームに向いています。
SWIDタグ
SWIDタグは、組織が管理する端末にインストールされたソフトウェアを、追跡・把握することを目的として作られたフォーマットです。「どの端末に、どのソフトウェアが入っているか」を管理する視点に特徴があり、国際規格としても承認されています。
ソフトウェアに付与されたタグを管理ツールなどで収集することで、端末への導入状況を効率的に把握できます。また、適用されたアップデートやパッチの識別、ソフトウェア資産やライセンスの管理などに活用できます。
SBOMを導入する3つのメリット
SBOMを導入すると、ソフトウェアの中身が見える化され、これまで手作業に頼っていた管理を効率化できます。効果はセキュリティ面にとどまらず、開発現場全体にも及びます。代表的なメリットは以下の3つです。
- 脆弱性を早く・効率的に管理できる
- ライセンス違反のリスクを減らせる
- ソフトウェア開発の効率が上がる
脆弱性を早く・効率的に管理できる
SBOMを導入する大きなメリットは、脆弱性への対応を素早く進め、調査の抜け漏れを減らしやすい点です。ソフトウェアを構成する部品をあらかじめ一覧化しておけば、新たな脆弱性が公表されたとき、その部品を自社の製品やシステムで使っているかどうかをすぐに確認できます。
さらに、影響範囲をすぐに絞り込めるため、対応にかかる時間とコストの削減にもつながります。無駄な調査に人手を割かずに済み、本当に対処が必要な箇所へ集中して取り組めるでしょう。経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引」にも、医療機器分野を対象とした実証では、SBOMを活用した脆弱性管理は手作業に比べて管理工数が70%程度低減したと記載されています。
ライセンス違反のリスクを減らせる
現在のソフトウェア開発では多くのOSSが使われていますが、OSSにはそれぞれ異なるライセンスが設定されており、利用時に守るべき条件も一律ではありません。条件を把握しないまま組み込んでしまうと、知らないうちに利用条件へ違反し、法的なトラブルや取引停止といったリスクにつながるおそれがあります。
そこで役立つのがSBOMです。各部品のライセンス情報を一覧化しておけば、どのコンポーネントがどのライセンスで提供されているのかを正確に把握できます。自社の社内ルールや製品の要件に反していないかを確認可能です。ツールを使えばライセンスの管理を効率化できるため、手作業によるチェック漏れやヒューマンエラーも減らせるでしょう。
ソフトウェア開発の効率が上がる
脆弱性とライセンスの管理が効率化されると、その結果として開発全体の生産性も上がります。部品のバージョンやライセンス情報が可視化されていれば、問題のある箇所を早い段階で見つけられるためです。開発初期でつまずきに気づければ、大きな遅延やムダな手戻りを防げるでしょう。
また、過去に作成したSBOMを参照できる点も便利です。これまで使ってきた部品の情報が蓄積されていれば、サポート終了を迎えた部品を洗い出して計画的に更新したり、担当者交代やシステム引き継ぎをスムーズに行えたりします。
SBOM導入でつまずきやすい課題
メリットの多いSBOMですが、実際に導入を進めようとすると、いくつかの壁にぶつかることがあります。あらかじめ課題を知っておけば、対策を立てたうえで取り組めるでしょう。よくある課題は次の3つです。
- 導入・運用に手間がかかる
- ツールごとに出力フォーマットが違う
- 取引先との共有・ルール作りが難しい
導入・運用に手間がかかる
SBOMは、導入や運用の段階で手間がかかりやすい点には注意が必要です。SBOMツールは海外製のものが多く、操作画面やサポート窓口が日本語に対応していないケースも少なくありません。
もし運用中に不明点や不具合が発生した場合、言語の壁があるとスムーズな解決が難しくなります。その結果、担当者の負担が大きくなり、導入のハードルが上がってしまうでしょう。
こうした事態を避けるためには、ツールを導入する前の段階で、日本語対応の有無やサポート体制をしっかりと確認しておくことが大切です。運用を継続させるために、自社のスタッフが無理なく使いこなせるツールを選びましょう。
ツールごとに出力フォーマットが違う
SBOMを扱ううえで悩みの種になりやすいのが、使用するツールによって出力されるフォーマットや記載内容にばらつきが生じる点です。複数のツールで作られたSBOMを突き合わせて確認しようとすると、形式の違いを一つひとつ照らし合わせる必要が出てきます。
フォーマットがそろっていないと、脆弱性のチェックにも余計な時間がかかります。取引先との共有の場面でも、相手の形式と合わなければ、変換や調整に手間を取られるでしょう。こうした事態を避けるために、フォーマットが自社のニーズや取引先の要件に合っているかを、導入前に確認しておくことをおすすめします。
取引先との共有・ルール作りが難しい
SBOMは、社内で作成して終わりというものではなく、取引先や納入先とやり取りして初めて効果を発揮する場面が数多くあります。ところが実務では、この連携部分にルール作りの難しさがあります。SBOMを誰が作成し、そのコストをどちらが負担するのか、また記載する情報の責任範囲をどこまでとするのかといった取り決めは、明確に定まっていないケースが多く見られます。基準があいまいなまま作業を進めてしまうと、「聞いていた内容と違う」「どちらが対応すべきか分からない」といった認識のずれが生じかねません。
こうしたトラブルを防ぐために、契約を結ぶ段階で、受注者と発注者の間でSBOMに関する取り決めをはっきりさせておきましょう。作成の主体や共有の方法、更新の頻度、責任の範囲などをあらかじめ書面で確認しておけば、後々の認識違いを避けられます。
SBOMを導入・運用する流れ
実際に自社でSBOMを活用していくためには、順を追って計画的に進めることが大切です。導入の準備から日々の管理に至るまで、基本的な運用は以下の4つのステップに分けられます。
- 適用範囲を明確化する
- ツールを選ぶ・導入する
- コンポーネントを解析してSBOMを作る
- SBOMを管理・運用する
①適用範囲を明確化する
SBOM導入で最初に取り組むべきなのが「適用範囲の明確化」です。SBOMは脆弱性管理を重視するのか、ライセンス管理を重視するのかといった対象や目的によって、コストも効果も大きく変わります。いきなりツールを導入するのではなく、「何のために導入するのか」という自社の課題と目的をはっきりさせましょう。
目的を定めたら、対象ソフトウェアの開発言語やビルドツール、動作環境などの情報を整理します。あわせて「どこを自社で開発し、どこを取引先やOSSに頼っているのか」を可視化しておくと、リスク管理の範囲を明確にしやすくなります。
作成主体（Who）、対象部品の範囲（What・Where）、活用目的（Why）といった観点で適用範囲を整理しておくと、次のツール選定や作成のフェーズをスムーズに進められます。
②ツールを選ぶ・導入する
適用範囲が明確になったら、次は自社の目的や環境に合ったSBOMツールを選び、導入・設定を進めます。ツールを選ぶうえで押さえておきたいのが、有償か無償かによって使える機能やサポートが変わる点です。有償ツールはコストがかかるものの、操作画面が整っていて直感的に扱いやすく、導入や運用で困ったときにベンダーへ相談できるという利点があります。一方で無償ツールは、ツール自体のコストはかからないものの、日本語の情報が少なく導入・運用に大きな工数を要する場合があります。
こうした特徴を踏まえ、機能や性能、コスト、サポート体制、日本語対応といった観点から複数のツールを比較し、自社に適したものを選ぶことが大切です。導入前に無償トライアルを利用して実際の使用感を確かめておくと、選定の失敗を防ぎやすくなります。
③コンポーネントを解析してSBOMを作る
ツールの準備が整ったら、いよいよSBOMの作成に入ります。まず、導入したツールでソースコードや依存関係定義ファイル、ビルド成果物などを解析し、対象ソフトウェアに含まれるコンポーネント（部品）を洗い出します。これにより、部品の名称やバージョン、部品同士の依存関係などを確認できます。
ただし、SBOMツールは万能ではなく、部品の検出漏れや誤検出が起こる場合があります。そのため、出力結果に抜け漏れや誤りがないかを確認したうえで、規制や取引先の要求も踏まえながら、含める項目やフォーマットを決めて出力することが大切です。完成したSBOMは、必要に応じて納入先や利用者に共有すると、サプライチェーン全体の透明性が高まります。
④SBOMを管理・運用する
作成したSBOMをもとに、ライセンス条件と自社の利用方法に不整合がないかを継続的にチェックし、リスクを評価しながら対応していきます。脆弱性の情報は日々更新され、ソフトウェアもバージョンアップで中身が変わるため、その都度SBOMを更新し、最新の状態を保つことが大切です。
また、作成したSBOMのデータは、ソフトウェアのアップデートなどに伴う変更履歴も含めて一定期間保管しておきましょう。万が一、取引先や利用者からセキュリティに関する問い合わせがあった際、いつでも情報を参照できる状態にしておくことが望ましいといえます。
SBOMツールを選ぶときのポイント
数あるSBOMツールの中から自社に最適なものを選ぶには、いくつかの基準を満たしているか確認することが大切です。導入後に「使いこなせない」「取引先と連携できない」といった事態を避けるためにも、以下のポイントを比較検討の参考にしてみてください。
| ポイント | チェックする内容 |
|---|---|
| 対応フォーマット | SPDX・CycloneDX・SWIDタグなど、取引先や自社の運用に必要な形式を作成・読み込みできるか |
| 脆弱性への対応 | 脆弱性データベースと自動で照合できるか。新たな脆弱性が見つかった際にアラートで通知されるか |
| 優先順位付けの機能 | 検出した脆弱性の深刻度やリスクを評価し、対応の優先度を判断する材料を示せるか |
| 対応する開発言語・環境 | 自社が使っている開発言語やビルドツール、動作環境に対応しているか |
| 日本語対応・サポート体制 | 画面やマニュアルが日本語に対応しているか。導入時やトラブル発生時に相談できる窓口があるか |
| コスト | ライセンス費用だけでなく、環境構築や学習、運用にかかる工数まで含めて導入効果に見合うか |
前述した「導入・運用に手間がかかる」「ツールごとに出力フォーマットが違う」といった課題を解決できるかどうかは、ツール選びにおける重要なポイントです。とくに海外製品が多い分野だからこそ、日本語でのサポート体制が整っているか、自社に必要なフォーマットに統一して出力できるかといった視点を持ちましょう。
SBOMだけでは足りない？Webアプリの脆弱性対策もあわせて実施
SBOMはソフトウェアに「どんな部品が使われているか」を可視化し、潜在的なリスクを管理するための非常に優れた仕組みです。しかし、それぞれの部品単体が安全であっても、それらを複雑に組み合わせて構築したWebアプリケーション全体が実際に安全に動作しているかまでは、SBOMだけでは確認できません。
そのため、Webアプリケーションを開発・運用している場合は、SBOMによる「部品の管理」に加えて、稼働しているWebアプリそのものをテストする「脆弱性診断」をあわせて実施することが重要です。構成要素をSBOMで把握し、Webアプリに潜む脆弱性を脆弱性診断で確かめれば、それぞれ単独では見落としがちな部分を補い合えます。どちらか一方を選ぶのではなく、両方を組み合わせることが、対策強化の近道です。
▼関連記事
Webアプリの脆弱性診断ならクラウド型ツール「AeyeScan」
Webアプリケーション自体の安全性を確かめるには、クラウド型Web診断ツールである「AeyeScan」の活用がおすすめです。AIを活用した自動巡回により、高度な専門知識を持っていなくても手軽に脆弱性診断を実施できます。対象URLを登録するだけで運用を始められるうえ、脆弱性の内容やリスク、必要な対策までレポートで確認できるため、修正方法を調べる手間もかかりません。
内製による診断を取り入れることで、外注にかかる手間やコストを大幅に抑えることが可能です。これまでに300社以上の企業へ導入された実績があり、多くの開発現場でセキュリティ対策の強化に貢献しています。
現在、実際の操作性や機能を体験できる無料トライアルも提供中です。自社のWebアプリケーションをより安全に運用していきたいとお考えの方は、ぜひ一度お問い合わせください。
まとめ｜SBOMでソフトウェアの中身を見える化し、脆弱性対策を強化しよう
SBOMは、ソフトウェアがどのような部品で作られているかを一覧にし、中身を見える化するための重要な仕組みです。構成要素や依存関係を正確に把握することで、新たな脆弱性が発見された際の迅速な対応や、意図しないライセンス違反を防ぐといったリスク管理に大きく役立ちます。
しかし、実際の導入にあたっては、運用にかかる手間や取引先とのルール作りなど、いくつかの課題にも直面するでしょう。これらのハードルを乗り越え、継続的な管理体制を築くためには、自社の目的や環境に合った使いやすいSBOMツールを選ぶことが欠かせません。
さらに、SBOMによる部品の管理だけでなく、Webアプリケーション自体の脆弱性診断を組み合わせることで、より強固なセキュリティ対策が可能です。AeyeScanを活用すれば、AI活用によって専門知識がなくても手軽にWebアプリの安全性を確認できます。SBOMとあわせてセキュリティ体制を強化したいと考えている企業の方は、ぜひ資料をダウンロードしてみてください。
著者：榊原敦子（シニアカスタマーマーケティングマネージャー）
