SBOM（Software Bill of Materials）
1. 概要
A. 定義
ソフトウェアを構成するすべてのコンポーネント・ライブラリ・依存関係と、そのバージョン・ライセンス・供給者情報を機械判読可能な形で目録化した明細書。製造業の資材明細書（BOM）から概念を借りたもので、ソフトウェアサプライチェーンセキュリティ（SSC、Software Supply Chain）の中核的成果物である。
SBOMの根本的な趣旨は「見えなければ管理できない（You can't secure what you can't see）」という命題にある。現代のアプリケーションはコードの70〜90%が開発者が直接書いたものではなく、外部のオープンソース・サードパーティコンポーネントで埋められるが、その中に何がどれだけ入っているかの目録すら備えていない組織が大半である。SBOMはこの「ソフトウェアの成分表（食品の栄養成分表になぞらえられる）」を明示化し、これまで管理の死角にあった脆弱性・ライセンスリスクを管理可能な対象へ引き上げる。
SBOMは単なる文書ではなく自動化可能なデータ構造である点が核心である。人が読む目録にとどまるなら、数百のコンポーネントを毎日更新される脆弱性データベースと突き合わせる作業は不可能である。したがってSBOMは、ツールが解釈・突合・検証できる標準フォーマットで作成されて初めて実効性を持つ。
B. 登場背景および必要性
オープンソース依存が急増し、一つのアプリが直接間接的に数百〜数千のコンポーネントに依存するようになり、その奥深くに潜む一つの欠陥がサプライチェーン全体へ波及する大型事故が相次いだ。ビルドシステム自体を汚染し、正常に署名された更新に悪性コードを載せて配布したSolarWinds（2020） 事件と、広く使われるJavaロギングライブラリのリモートコード実行脆弱性であるLog4Shell（Log4j、2021、CVE-2021-44228） が代表的である。
とりわけLog4Shellの際、数多くの組織が「自社システムがLog4jを使っているか、使っているならどのバージョンをどこで使っているかすら把握できず」初動対応が数日ずつ遅れた。もしSBOMが備わっていれば、一度の照会で影響範囲を即座に識別し、優先順位どおりにパッチできたはずである。この事件はSBOMの価値を全産業に刻み込んだ決定的契機であった。こうした背景から米国は行政命令EO 14028（2021） を通じて連邦政府へ納入されるソフトウェアにSBOM提出を義務化し、その後各国の規制と産業標準へ急速に拡散した。
2. SBOM構成要素・標準フォーマットと生成階層
A. 構成要素と標準フォーマット
SBOMが実効性を持つには、人ではなくツールが自動で解釈できねばならないので、機械判読が可能な標準フォーマットで作成することが重要である。フォーマットが標準化されてこそ、異なる組織・ツール間でSBOMをやり取りし、脆弱性データベースと自動突合し、サプライチェーンをさかのぼる検証が可能になる。
| 区分 | 内容 |
|---|---|
| 構成要素 | コンポーネント名・バージョン、供給者、依存関係、ライセンス、ハッシュ(完全性検証) |
| 標準フォーマット | SPDX(Linux財団、ISO標準)、CycloneDX(OWASP、セキュリティ特化)、SWID |
米国商務省傘下のNTIAは、SBOMが備えるべき最小要素（minimum elements） として、供給者名・コンポーネント名・バージョン・固有識別子・依存関係・SBOM作成者・タイムスタンプを規定した。この最小要素は、異なるSBOMを相互に突合・統合するための共通基盤となる。各コンポーネントの固有識別子としてはPURL（Package URL） やCPE（Common Platform Enumeration） が使われるが、表記が標準化されてこそ「このコンポーネントがそのCVEの対象と同じものか」を誤検出なく判断できるためである。
フォーマット別の性格も異なる。SPDXはライセンス・規定順守の管理に強みがあり国際標準（ISO/IEC 5962:2021）として採択され、CycloneDXはOWASPが主導して脆弱性・サプライチェーンセキュリティ活用に焦点を置き、VEX・サービス・依存グラフの表現が豊富である。ハッシュ（チェックサム）を含める理由は、明細されたコンポーネントが実際の配布物とビット単位で同一か（改ざん・汚染の有無）を検証するためである。ハッシュがなければ「目録は合っているが実物がすり替えられた」サプライチェーン攻撃を選り分けられない。
B. 生成時点による階層
SBOMはいつ作るかによって正確性と完全性が変わる。これを理解すれば、なぜビルド時点の自動生成が推奨されるかが明確になる。
| SBOM類型 | 生成時点 | 特徴 |
|---|---|---|
| Source SBOM | ソース・依存宣言時点 | 宣言された依存基準、実際の包含物と異なりうる |
| Build SBOM | ビルド/コンパイル時点 | 実際の成果物基準、正確・最新(推奨) |
| Deployed/Runtime SBOM | 配布・運用時点 | 実行環境・構成まで反映 |
ソース段階で宣言した依存と、実際のビルド成果物に含まれるコンポーネントはしばしば食い違う（推移的依存の解決、条件付き包含、バンドリングなどの理由で）。だから信頼できるSBOMは、ビルドパイプラインが実際に作り出した成果物から抽出したBuild SBOMでなければならないというのが定説である。
3. 管理対象：オープンソースリスク
SBOMで可視化しようとするリスクは大きく四つであり、そのうち推移的（transitive）依存が最も厄介である。自分が直接取り込んだライブラリがまた別のライブラリを呼び、それがさらに三つ目を呼ぶ多段構造なので、実際に問題となるコンポーネントは目に見えない深い所に潜むためである。実際、アプリが明示的に宣言した直接依存は数十個でも、そこから引き連れられる推移的依存は数百〜数千個に達する場合が多い。
| 脆弱性 | 内容 |
|---|---|
| 既知の脆弱性(CVE) | Log4jなど公開された欠陥が推移的依存に潜む |
| 依存リスク | 多段の推移的依存で何を使うか把握困難 |
| ライセンス違反 | GPLなどコピーレフトライセンス未順守時に法的リスク |
| 保守中断・悪性 | EOL(サポート終了)パッケージ、悪性注入(Typosquatting) |
ライセンス違反がセキュリティに劣らず重要な理由は、GPLのような強いコピーレフトライセンスを認識せずに含めると、自社ソースコードの公開義務が発生したり配布が制限されたりするなど法的・事業的リスクに直結するためである。実際、オープンソースライセンス違反で製品出荷が中断されたり訴訟に発展したりした事例は少なくない。
最後の類型である保守中断・悪性注入も近年急増する脅威である。人気パッケージ名と一文字だけ異なる偽パッケージを登録して打ち間違いを狙うタイポスクワッティング（Typosquatting）、正常なパッケージの保守権限を奪取して悪性バージョンを配布する依存ハイジャック、長らく放置されたEOLパッケージの未パッチ脆弱性などは、いずれもSBOMがなければ存在自体を認識しにくい。
この四つのリスクは互いに絡み合い増幅する。例えばEOLで保守が途絶えた推移的依存に新たなCVEが公開されると、パッチが出ないので代替コンポーネントに置き換えるか迂回せねばならないが、推移的依存なのでどの直接依存を手直しすべきかすらSBOMなしでは追跡しにくい。このようにリスクは個別にではなく依存グラフ全体の文脈で判断せねばならず、SBOMはまさにそのグラフを提供する地図の役割を果たす。
4. SBOM基盤の管理方策
SBOMは一度作って終わる静的文書ではなく、生成→共有→マッピング→対応→再生成が循環する持続的プロセスでなければならない。新たなCVEは毎日数十〜数百件公開されるので、昨日まで安全だったコンポーネントが今日脆弱になりうるためである。
flowchart LR
G["SBOM生成(SPDX・CycloneDX)"] --> S["共有・公開"]
S --> M["脆弱性マッピング(CVE・NVD突合)"]
M --> R["対応・パッチ・監視"]
R -. 持続管理 .-> G
上記の循環の各段階は、CI/CDパイプラインと運用段階にまたがって次のように具体化される。下図は開発-ビルド-運用の軸でSBOMがどのように自動統合されるかを示す。
flowchart TB
DEV["開発(依存宣言)"] --> BUILD["ビルド(SBOM自動生成)"]
BUILD --> SCA["SCAスキャン(構成・脆弱性・ライセンス)"]
SCA --> VEX["VEXで悪用可能性を判定"]
VEX --> GATE{"リリースゲート通過?"}
GATE -->|No| DEV
GATE -->|Yes| OPS["配布・運用監視"]
OPS -. 新規CVE監視 .-> SCA
| 段階 | 方策 |
|---|---|
| 生成 | CI/CDビルド時点にSBOMを自動生成(正確性・最新性を確保) |
| 分析(SCA) | SCAツールで構成要素・脆弱性・ライセンスをスキャン |
| マッピング | CVE/NVDデータベースと突合して脆弱コンポーネントを識別 |
| 対応・監視 | パッチ・アップグレード、新規CVE公開を持続的に監視 |
核心はSBOM生成を人の手ではなくビルドパイプラインに自動統合することである。手作業で作成した明細はたちまち実際のコードと食い違い信頼できなくなるので、ビルドが回るたびに実際の成果物からSBOMを機械的に抽出せねばならない。代表的ツールとしてはSBOM生成器のSyft、脆弱性スキャナのGrype・Trivy、そして商用SCAプラットフォーム（例：Snyk、Sonatypeなど）があり、これらをCIに接続して生成-スキャン-遮断を自動化する。
もう一つ重要な実務ポイントはSBOM自体の信頼性確保である。SBOMが偽・改ざんされると、かえって誤った安心感を与えかねないので、生成したSBOMにデジタル署名を付け（例：Sigstore/Cosign）完全性を検証する手続きも併せて備えてこそ、サプライチェーンの信頼の連鎖が完成する。
5. 深化：VEX結合と国内外の規制動向
脆弱性の目録だけでは実際の危険を過大評価しやすいというのが、SBOM運用の最大の落とし穴である。あるコンポーネントにCVEが存在しても、当該の脆弱なコード経路が自社製品で実際に呼び出し・実行されなければ、悪用の危険がないか極めて低いことがある。この隔たりを埋めるのがVEX（Vulnerability Exploitability eXchange） である。VEXは各脆弱性について「影響なし（not_affected）・調査中・影響あり・措置完了」といった悪用可能性の状態を供給者が明示的に宣言する文書で、対応の優先順位を定め不要なパッチ騒動を減らすのに決定的である。SBOMが「何が入っているか」なら、VEXは「そのうち何が実際に危険か」を教えてくれ、両者は対をなしてこそ実効性が完成する。
規制動向も速く強化されている。米国はEO 14028に続き医療機器（FDA）・連邦調達全般へSBOM要求を拡大しており、欧州連合はCRA（Cyber Resilience Act） を通じて市場に投入されるデジタル製品にSBOM具備と脆弱性処理義務を課す方向へ進んでいる。Hàn Quốc でも科学技術情報通信部・KISAを中心にSW供給網セキュリティガイドが整備され、公共・金融部門を皮切りにSBOM適用が議論・拡散する流れである。ただし詳細な義務化の範囲と時期は政策により変わりうるので、組織は規制を後追いするより先んじてSBOM管理体系を整える方が有利である。
技術士の観点の予想出題方向は、（1）SBOMの定義・最小要素・標準フォーマット（SPDX vs CycloneDX）の比較、（2）推移的依存・ライセンスリスクの管理の必要性、（3）SBOM生成-SCA-CVEマッピング-VEX-監視の持続的プロセス、（4）DevSecOps統合と署名基盤の完全性確保の方策として整理できる。
6. 考慮事項および示唆点
第一に、自動化と最新性の確保である。SBOMはビルドパイプラインに統合し毎ビルドごとに自動生成せねばならず、手作業の明細はたちまち古びて信頼を失う。生成だけでなく新規CVE公開に合わせた持続的な再マッピングが併せて回ってこそ、SBOMが生きた資産となる。
第二に、VEX結合を通じた優先順位化である。脆弱性の数自体ではなく悪用可能性を基準に対応順序を定めてこそ、限られた人員を実際の危険に集中できる。VEXなしにCVEだけを羅列すると「パッチ疲労」でかえって危険な脆弱性への対応が遅れる逆説が生じる。
第三に、SBOMの完全性・信頼の連鎖の確保である。SBOM自体を署名・検証し、コンポーネントのハッシュで配布物の改ざんを検知し、供給者から受け取ったSBOMの真偽を確認する手続きがあってこそ、サプライチェーンの信頼が成立する。信頼できないSBOMは、ないよりも劣る誤った安心感を与える。
第四に、ライセンス・規定順守の常時管理である。セキュリティ脆弱性だけでなくコピーレフト・相反ライセンスの有無を持続的に点検して法的・事業的リスクを先んじて統制せねばならず、そのためにはSPDX基盤のライセンスメタデータを正確に管理する必要がある。
第五に、組織次元のDevSecOps内在化と規制対応である。SBOM・SCA・VEXをパイプラインに常時統合し、EU CRA・国内SW供給網セキュリティ政策などの規制変化を先んじて反映して、組織全般のサプライチェーンセキュリティ成熟度を高めねばならない。SBOMはそれ自体が目的ではなく、サプライチェーン全般の可視性・信頼・対応力を支える基盤インフラだという観点が必要である。
参考資料
- CISA, "Software Bill of Materials (SBOM)": https://www.cisa.gov/sbom
- NTIA, "The Minimum Elements For a Software Bill of Materials (SBOM)", 2021
- OWASP CycloneDX: https://cyclonedx.org/ · SPDX: https://spdx.dev/
一言まとめ: SBOMはソフトウェア構成要素をSPDX・CycloneDX標準で目録化して オープンソースの脆弱性・ライセンスリスクを可視化 し、ビルド時の自動生成→SCAスキャン→CVEマッピング→VEX優先順位化→署名・監視 の持続的プロセスでサプライチェーンセキュリティを管理する基盤インフラである。