SBOM(Software Bill of Materials)という単語が広まり始めて2年※1がたち、多くの企業でどのような情報を含めるべきなのか、いつどのように作成するか、また上手く活用していくためにはどうしたら良いのかといった議論が進みつつあります。
本記事ではSBOMとは何か、何故必要なのかといった基本を簡単に振り返った後、SBOMを取り巻く最新の状況※1をレポート、今後どのように取り組んでいくべきかなどの指針について解説します。
はじめに
SBOMとは
SBOMとはソフトウェアの部品表(Software Bill Of Materials)の略称であり、ソフトウェアを構成する要素とそれらの関係性を一覧化したリストを指します。このリストを活用することによって、本来の目的であった脆弱性管理、ライセンス管理のメリットだけではなく、ソフトウェア開発における生産性向上のメリットもあることが、経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引 – 2.2章」※1,2で言及されています。
経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引※2
https://www.meti.go.jp/press/2024/08/20240829001/20240829001-1r.pdf
SBOMの重要性
昨今のソフトウェア、またソフトウェアサービスは多くの他のソフトウェア、特にオープンソースソフトウェアを組み合わせて作成されるものが殆どです。Synopsys社が毎年発行されている「オープンソース・セキュリティ＆リスク分析レポート（OSSRA Open Source Security and Risk Analysis）」※3では、ほぼ全ての産業界においてソフトウェアやサービスの80%以上にオープンソースソフトウェアが使われていることがわかります。
シノプシス社 オープンソース・セキュリティ & リスク分析レポート
https://www.synopsys.com/ja-jp/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html
一方で、古くから開発されておりその素性がわからなくなっているコンポーネントや、非常に多くの小さなコンポーネントを依存関係に持つソフトウェアが増えており、その依存関係、包含関係を把握することが非常に難しくなっています。
また更に、数々のソフトウェアはBSPやSDKなど多くの組織や企業で受け渡され、開発するソフトウェアやサービスの一部として取り込まれます。
このように昨今ではソフトウェアそのものが複雑になるとともに、ソフトウェアサプライチェーンも複雑化しており、最終的なソフトウェアやサービスに一体どのような部品が含まれているのかを把握することは非常に難しくなっています。その為、もし部品の一部に脆弱性があった場合その影響範囲を特定することが難しく、対応に時間がかかる点が非常に課題となってきています。
このような背景から、ソフトウェアやサービスの透明性を高めるためにSBOMを作成し、実際のソフトウェアやサービスと共にサプライチェーン上で流通させていきましょう、というのがトレンドとなってきています。
VEX(Vulnerability Exploitability eXchange) とは
製品やその製品が含むソフトウェアコンポーネントが脆弱性を持っていて、何かセキュリティインシデントが起きた場合にはそれぞれ固有の名前や番号を付与し管理していきます。それがCVE(Common Vulnerabilities and Exposures)やCVE IDです。更に、これら製品やソフトウェアに含まれる全ての脆弱性を記載し、その影響を詳細に分析したレポートとして、VDR (Vulnerability Disclosure Report)という文書が発行されます。
しかし、ときに製品は脆弱性を持つソフトウェアコンポーネントを含んでいた場合であってもその影響を受けない場合があります。そういった混乱を避けるために開発されたのがVEXです。VEXは製品やサービスに脆弱性が含まれているかどうか、またその脆弱性が悪用される可能性があるかどうかがわかる指標となっています。
SBOMとVEXの関係
VEXとSBOMに直接的な関係はありませんが、相互に補完できる情報となっており、代表的なSBOMフォーマットであるSPDX及びCycloneDXではVEXをSBOMに包含したり、関連付けて活用できるような構造となっています。
SBOMと各国法制、規制
ソフトウェアサプライチェーン上の透明性を高めようとする取り組みは古くから続いていましたが、この動きが加速したのは2021年以降です。2020年、SolarWinds社のセキュリティ事件を受けて2021年5月に米国大統領令、”Executive Order on Improving the Nationʼs Cybersecurity”が発行されました。
この大統領令を受けて米国NTIA(National Telecommunications and Information Administration)が、ソフトウェアコンポーネントの透明性に関する活動を開始、SBOMが満たすべき最低限の必須事項をThe minimum Elements for a Software Bill of Materialsとして公開しました。
NTIAはこの文書の中で以下3つの要件を必須と定めています。
- SBOMに含むべき6つのデータフィールド
a. サプライヤー名
b. コンポーネント名
c. コンポーネントバージョン
d. 一意な識別子
e. 依存関係
f. SBOMデータの作成者
g. SBOMデータを作成した日時 - 機械判読可能なフォーマットで記述され、自動化に対応可能であること
- SBOMで記述する依存関係の深さ、アップデートの頻度、どのように共有するかといったプロセス
NTIAが策定したこの “The minimum Elements for a Software Bill of Materials”を基本として、米国内外で様々な法制や規制が策定、施行されつつあります。
米国政府機関調達要件
米国行政管理予算局(Office of Management and Budget)からは連邦政府機関が調達するソフトウェアに関してセキュリティー要件を定めるガイダンスが発表されており、その中で各政府機関はSBOMの提出を求めることが出来るとされているなど、既に実用段階に入っています。
Enhancing the Security of the Software Supply Chain to Deliver a Secure Government Experience※4
https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf
欧州サイバーレジリエンス法案 (EU Cyber Resilience Act)
欧州委員会は2022年にサイバーレジリエンス法案を公表し、欧州で販売されるハードウェア、ソフトウェアなどあらゆるデジタル製品に対し、脆弱性の対応などサイバーセキュリティを確保するための対応やソフトウェアの透明性を高めるための施策を求めています。
CRAではその法案中で24時間以内のENISAへの脆弱性、インシデント報告を求めたり、必要に応じてSBOMを当局に提供すること、それらを順守している製品やサービスの認定まで行うことなどが提案されています。
昨年11月に※1欧州議会、EU理事会、欧州委員会での三者対話(トリローグ)での合意がなされ暫定合意はなされていますが、議論はまだ続いています。SBOMの形式やフォーマットは欧州委員会が指定できると記載されているのみで特に詳細まで言及されていませんが、NTIAのガイドラインを基本としています。
CRAは2025年12月頃よりの施行が想定※5されており、企業では対応に関して最も多くの議論が発生している状況です。
ドイツ 情報セキュリティ局発行 SBOMガイドライン TR-03183
ドイツの情報セキュリティ局がSBOMについての考え方、運用の仕方などをまとめたガイドラインを発行しています。
Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products
– Part 2: Software Bill of Materials (SBOM) Version 1.1
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2.html
このガイドラインは、NTIAのガイドライン中にある依存関係の考え方がガイドライン中に具体的に示されていることが特徴です。
現時点※1ではCRAなどに含まれる公式ドキュメントではないとのことですが、欧州委員会に対して正式なドキュメントとして扱ってもらえるような働きかけを行っていることが、2024年 CISA主導で行われたイベント、 SBOM-a-Rama で紹介されています。https://www.cisa.gov/news-events/events/sbom-rama-winter-2024
医療機器業界におけるセキュリティ規制
医療機器については、IMDRF(International Medical Device Regulators Forum)による “Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity”、FDA (U.S. Food & Drug Administration) による “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” が発行されています。
IMDRF(International Medical Device Regulators Forum)
https://www.imdrf.org/documents/principles-and-practices-software-bill-materials-medical-device-cybersecurity
FDA (U.S. Food & Drug Administration)
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
特にFDAが発行する “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” では、NTIAの最小要件に加えて、「ソフトウェアコンポーネントの製造者によるサポートレベル」、「サポート終了日時」もSBOMに含めるよう求めています。(4章 (b))
経済産業省 ソフトウェア管理に向けたSBOMの導入に関する手引
日本でも経済産業省からSBOMの導入手引が発行されています。
経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を策定しました。※1,2
https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html
今はv2.0の改版作業が始まっていますが※1,2、日本においてもサイバーセキュリティ対応、またソフトウェアサプライチェーンの透明性を担保するためのSBOMへの取り組みが始まってきています。
法制化、規制といった形にはなっていませんが、近い将来日本においてもSBOMの流通が重要になってくることは間違いないでしょう。
今後の展望
ソフトウェアを製品やサービスで提供する場合、SBOMの作成や提供を求められる場面は今後拡がっていく事は間違いありません。
SBOMはソフトウェアのライフサイクルに応じて、作成されるSBOMのタイプを変えて作成、管理していく必要があります。
https://www.cisa.gov/sites/default/files/2023-09/Tooling%20%26%20Implementation_508c.pdf
オープンソースソフトウェアを取得するときにはSBOMが提供されているか、SBOMを生成するのに必要な情報が提供されているかに気を付け、第3者からソフトウェアを受け取るときなどはSBOMを可能な限り受領してください。勿論、自分たちがソフトウェアを作成する際にはそのビルドプロセスの中で構成を解析し適切なSBOMの生成をすることが出来るようなツールを統合していく必要が出てきます。
脆弱性及びサイバーセキュリティへの対応と、今後の各国法制や規制への対応として、自社のソフトウェア開発、サービス開発におけるソフトウェアの構成管理をどのようにCI/CDに組み込んでいくか、それを考える時期がまさに今来ています。
FossIDは、ソフトウェア全体を構成するオープンソースソフトウェアを素早く検出、そのバージョンやコードスニペットなどの情報も含めた解析を行います。解析で得た詳細なソフトウェアコンポーネント情報をSBOM (CycloneDX, SPDX, SPDX-Lite)として出力することが可能です。
更にこれら詳細なソフトウェアコンポーネント情報からCVEに基づいた脆弱性情報を提供する機能が存在しており、脆弱性情報の検知や管理も可能となっています。脆弱性の原因となるコードスニペットを検出するVulnSnippet Finderという有償機能も提供していますので、VEXへの対応が一段とスムーズなものとなるはずです。
Tips集のご案内
企業の中でOSSと上手につきあうためのポイントや、OSSを活用したソフトウェア開発に役立つヒントなどをさまざまな視点からまとめたTips集を提供しています。
過去の記事掲載もありますので、まだダウンロードされていない方は、こちらからご確認ください。
※1 本記事は2024年3月時点のものです。
※2 本記事執筆後の2024年8月に「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0」に改定が行われています。https://www.meti.go.jp/press/2024/08/20240829001/20240829001-1r.pdf
※3 2023年のレポートを参照したデータです。
※4 2025年4月30日現在、「Enhancing the Security of the Software Supply Chain to Deliver a Secure Government Experience」はこちららのリンクからご参照いただけます。https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf
※5 欧州サイバーレジリエンス法案は、
2024年12月10日：施行
2026年9月11日：当局及びユーザへの脆弱性・インシデントの報告および通知義務の適用開始
2027年12月11日：報告義務以外の義務の適用開始
が予定されています。
