SBOMはもっとシンプルにできると思う

やりたいことは要するに脆弱性管理でしょ

ソフトウェアXに脆弱性Vがあったぞやばいぞ！ってなったときに、俺たちはXを使っているのかってのを把握したい

そのためには製品Pはこれとこれを使っています的なリストがあればいい（構成情報）

リストがあれば、Xの名前で検索して見つかったかどうか、で判断できる

もっとも製品名には表記揺れがある（脆弱性データベース側の名前と構成情報側の名前）があるので単純な文字列比較はできないけど

現状これがあるからPSIRTが手作業で頑張っている

今はその構成情報を表現する手段としてSBOMに注目が集まっている

でも製品P（のコードやバイナリ）から構成情報を正確に吸い出すなんてできない

だからせめて正確な情報が書けるようにしておこう、というわけでSBOMのフォーマットはやたら複雑になっている

SPDXもそう。SPDX3.0も出たよね（もっと複雑になっている）

……なんだけど、違うでしょsta.icon

俺だったらこうするねsta.icon

1 構成情報はNarsion程度を記した、シンプルなものにする …… SBOM

2 表記揺れを吸収して一致判定できる仕組みをつくる …… PNM(Product Name Matcing)

グローバルな製品情報データベース(PND(Product Name Database))みたいなものが一つあるといい

最低でも社内で持って、育てていけばいい

3 SBOM内の各Narsionをどう使っているか、使っていないかなどの補足を記したファイル …… BOME(BOM Explanation)

要はSBOMファイルとBOMEファイルを用意する

sbomファイルはnarsion程度のシンプルなものなので、比較的楽につくれるはず

最悪手作業記入であってもnasion(nameとversion)を列挙するだけなので何とかなる

少なくともspdx liteみたいに付随情報あれこれ書かせるクソゲーじゃない

で、「実際にどう使ってるか」という部分はbomeファイルという別ファイルで説明する

この部分はどう頑張っても環境やコードからは抽出できない

人間が記述するしかない

でもこれは「どう使ってるかの説明」であって、構成情報そのものではない

だからこそsbomの概念からは切り離すべきだと思うんだよ

ミクスチャセパレーティングね。切り離すのは基本ですsta.icon

あとは脆弱性判定だけど、これはPNMを使えばいい

その際、bomeも見る（たとえばコンポーネントAは実際は使ってないですとあるならAは見なくていい）