23年11月にESFからSBOMに関するガイダンス「
Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption」が出ました。
今回はSBOMを受け取るカスタマー側の目線からお勉強します。
何の本？
本書は一言でいうと「SBOMを受け取った後どうすんの？」を掘り下げるものです。
EO 14028の第4条の指示を受けて、SSDFやSecuring the Software Supply Chain Recommended Practices Guide For DEVELOPERS/SUPPLIERS/CUSTOMERS の3部作が公開されたことは過去のブログで記載しました。
本ガイダンスは、その3部作を更に掘り下げるフォローアップガイダンスとして、主にカスタマーにSBOMの活用方法をイメージしてもらうために作られたものです。
タイトルにあるSBOM Consumptionは、直訳すると「SBOM消費」という分かりづらい言葉になりますが、要はSBOMから得た情報を組織で活用しまくることだと理解しています（参考）。
構成は？
全27ページ、うち本紙が23ページと分量は少なめです。
- はじめに
- SBOM消費
- エンタープライズにおけるSBOMライフサイクル
- SBOMリスクスコアリング
- SBOMの運用
- 結論 SBOM消費の今日と明日
要点
本ガイドラインを3行で表すと以下です。
- SBOMは一度受け取り始めると、とにかく量が多く、細かい
- だから、受け取ったSBOMデータの処理や相関分析の自動化が肝心
- SBOMの活用方法として、VEXを組み合わせた脆弱性管理や、ソフトウェアのリスクの定量化（スコアリング）が考えられる
#でもまだまだ概念レベルの紹介
SBOM消費のために事前に決めておくこと
本ガイドラインの2章にあたります。
SBOMはとにかく数が多くなるため、サプライチェーン全体でSBOMの交換、処理、分析、相関を自動化することを推奨しています。
自動化するためには以下の観点を整理する必要があると述べています。
まず、上図の左の列にあるように、大量のSBOMを扱うには、データフォーマットを標準化し、エンティティを解決し、SBOMの解析と取り込みを自動化する必要があります。
次に、SBOMで扱う情報について「これだけは含める」的な基本セットを決めます。
上図の中央列では製品のバージョン番号、依存識別子、SBOM作成者が例として挙げられていますが、後の4章を見るにSBOM以外の属性情報も基本セットとして使う場合がありそうです。
最後に、SBOMデータの共有や交換を自動化します。
SBOMはサプライヤにより、公開情報とされることも機密情報とされることもありえます。
後者の場合は、暗号化やアクセス制御によりカスタマーが受け取ったSBOMを保護する必要があります。
受け取った後は、各組織が従来から持つ脆弱性管理などの運用インフラに組み込んで活用を目指します。
SBOMの受け取り～活用準備
本ガイドラインの3.1にあたります。
以下の図で、SBOMを活用する手前まで、つまりSBOMデータの受け取り→取り込み→他の情報と紐づける流れを解説しています。
（１）SBOM Delivery
SBOMの受け取り方は様々です。
契約文書の一部として／ソフトウェアダウンロード時に／デバイスがネットワークに接続する際の検出プロセス中に／ポータルサイトなどを通じて などの受け取り方が考えられます。
（２）Acceptance ＆ Validation
カスタマーがSBOMを受け取ったら、ハッシュ値や署名（これもSBOMに埋め込める）を用いて完全性および真正性を検証します。
加えて、カスタマー側でSCAを用いてソフトウェアを解析し、受け取ったSBOMが正確であるか、あるいはサプライヤが提供するVEXに納得感があるかを確認することもあります。
（３）Ingestion & Parsing
いまいち何が言いたいのか不明だったので飛ばします。
SBOMをシステム一覧や資産管理、脆弱性管理と組み合わせて活用するためにデータ管理レイヤーが必要かもね的なことを言っています。この後の（４）（５）との順序関係もよく分からなかったです。
（４）Extraction, Transformation & Loading
SBOMは単体のデータだけでは情報としての意味は少なく、「XXシステムの中で使っている〇〇コンポーネントのSBOM」みたいにシステムとの紐づけが必要です。
この紐づけ作業１つにしても、日々入手する大量のSBOMを処理できるだけの仕組みが必要です。
また、受け取ったSBOMのファイルや文書そのものをカスタマーが保管したいと思う場合、いつ・どこに・何の情報を・いつまで保存するのかしっかり管理する必要がありますし、サプライヤとの契約内でSBOM保管時のセキュリティ要件が定められていた場合はそれを守る必要があります。
（５）Mapping & Asset Management
SBOMを活用するために、構成管理DBやソフトウェア資産管理システム、SOC、調達ワークフローなどの組織が持つ様々な仕組みと連携します。
SBOMの活用
（１）脆弱性管理
本ガイドラインの3.2～3.4にあたります。
SBOMの活用例を想像する際に、CVEなどの脆弱性情報と紐づけた上でリスクを分析し、適切な対応方針の決定（受容、軽減、移転、回避）に繋げる、というアイデア自体は多くの人が思い当たると思います。
本ガイドラインでは、その際に「VEX」を併用することで、より効率的にリスクを管理できるとしています。
VEXとは、Vulnerability Exploitability eXchangeの略称です。
ソフトウエアのサプライヤが、製品における特定の脆弱性の状態を主張できるようにすることが目的です。（参考）
SBOMと脆弱性DBを突き合せると、大量の脆弱性を含んでいるように見えます。
しかし、その中には、一見脆弱性があるように見えてもソフトウェアの作りによっては脆弱性の影響を受けない場合（実は脆弱性を有する関数は使ってない等）があります。
こうした「実際に影響を受けるかどうか」をサプライヤが提供する情報がVEXです。
脆弱性について以下のステータスを示すことができます。
- NOT AFFECTED - この脆弱性に関する修正は必要ない。
- AFFECTED - この脆弱性を修正または対処するためのアクションが推奨される。
- FIXED - これらの製品バージョンには脆弱性の修正が含まれている。
- UNDER INVESTIGATION - これらの製品バージョンが脆弱性の影響を受けるかどうかはまだ分からない。
本ガイドラインは終始「SBOMの膨大な量」を念頭にその扱いを説いており、処理の自動化や、VEXやKEVと組み合わせて対処すべきリスクを絞るなど、大量のSBOMをうまく扱う方向性を示しています。
とはいえ、いきなり最初からSBOM活用やVEXとの併用を実現するには難しい組織が多いと思います。
仮にSBOMを活用できていなくとも、「サプライヤがSBOMを提供している」こと自体がサプライヤの信頼度に関わり、カスタマーにとってのリスク判断に役立つ。逆にいえば、SBOMを提供していないサプライヤは信用ならんくらいのことを書いています。
（２）リスクスコアリング
本ガイドラインの4章にあたります。
私たちが新たなソフトウェアを利用する場合、何をもってそのソフトウェアが「大丈夫」と判断するでしょうか。
クリティカルな脆弱性がないから、沢山の人にメンテナンスされているから、サプライヤが財務的に安定しているから、など様々な観点があると思います。
SBOMによりソフトウェアの構成が把握できると、それを起点に他の情報を追加調査して組み合わせることで、上記の「大丈夫」を定量的に評価できます。それがリスクスコアリングです。
本ガイドラインでは、4つの観点でリスクスコアリングを始めることを推奨しています。ただし、まだ観点レベルの記載であり、具体的な計算式が示されているわけではありません。
なお、経産省の「ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する 手引」（要点抽出ブログはコチラ）にもスコアリング機能を持つツールが言及されています。（私は使ったことはありません）
1. 脆弱性の観点
ソフトウェアが内包する脆弱性のCVSSスコアやVEXが示す影響有無の情報をもとにスコアを算出します。
この計算メトリクスの１つにLinux Foundations LFX platformが登場しますが、特に解説がありませんでした。
LFX SecurityというOSSの脆弱性を検出するツールがあるので、それも役立つという意味かもしれません。
この観点のみ、シンプルな足し算の計算方法が示されています。
Example: 1 high + 1 medium = CVSS score (7.7) + CVSS score (4.1) = vulnerability factor (11.8) for 2 vulnerabilities.
2. ライセンスの観点
SBOMに含まれるライセンスリストを用いて、何種類のライセンスを用いているか、その中にカスタマーを制限したり不利な条件に晒すようなライセンスが含まれていないかをもとにスコアリングします。
3. コミュニティ、サプライヤの観点
SBOMにより得られた構成情報を用いて、libraries.ioなどのOSSの情報を提供するサイトから、各ソフトウェアのサプライヤの地理情報、更新頻度、既知の脆弱性への対応姿勢、コミュニティのメンバー数などの情報を得て、スコアリングに活用します。
4. 依存関係の観点
各ソフトウェアがどれだけ多くの外部パッケージやライブラリと依存関係を持っているかについてスコアリングします。
前述のlibraries.ioのSourceRankが例として挙げられています。
（SourceRankの詳細はこちらが参考になりますが、依存関係の数をスコアリングしたものではないような気がする）
これらの観点をスコアリングし、ソフトウェアの購入判断などに活用することでサプライチェーンリスクマネジメントに寄与できると述べています。
感想
まとめはここまでです。
EO(大統領令)は企業における社長命令と同義（あるいはそれ以上）であり、名指しで挙げられたSBOMはなんとしても普及させねばならない状況だと思われます。
これまではSBOMの「作り方」に関する情報が中心でしたが、受け取り手が活用できるようになって初めてSBOM普及に勢いがつくので、様々な目線からSBOMを盛り上げるためのドキュメントを打ち出しているのだろうなぁ…と思いました。
想像があっているかは分かりませんが、そういう目線で向き合うと読みやすいドキュメントだと思います。
とはいえ、まだまだSBOMは普及前の段階なので概念的な内容が多いです。
本ガイドラインも虎の巻的なものではなく、「SBOMと付き合うにはこういう論点や活用方法があるんだなぁ」くらいに受け止めたほうがよいと思いました。
徐々にデファクトスタンダードな手法やツールが定まるにつれて情報が詳細化されると思いますので、引き続き見守りたいと思います。
