SBOM はコンプライアンスのチェックリスト以上のものだ
規制当局や顧客がいまや SBOM（ソフトウェア部品表）を求めるため、多くのチームはそれを「成果物」として扱う——生成し、提出し、監査を満たす。それは SBOM の本来の用途を無駄にしている。良い SBOM はゴールではなく、統制の出発点だ。
一つの棚卸し、三つのレベル
すべての SBOM が同じではない。
- 何があるか：コンポーネントとバージョンを列挙する。最低ライン——そして多くのツールが止まる場所。
- どれだけ危険か：各コンポーネントを CVE / CNVD / CNNVD / EUVD に対応付け、ライセンスを付記する。
- 何をすべきか：到達可能性と悪用可能性を組み合わせ、何を最初に直すべきかを示す——500 件のバックログを手渡すのではなく。
パッケージ単位ではなく、スニペット単位で
宣言的な依存解決は二つを見逃す：プロジェクトにコピー＆ペーストされたオープンソース片と、改名・切り出し・改ざんされたコンポーネントだ。スニペットレベルの指紋照合はコード自体を指紋化し、膨大なコーパスと照合する。だから「変装した」オープンソースコードを捕らえ、ひそかに変更されたライセンスを可視化する。
SBOM の価値は「すべてを列挙する」ことではなく「正確に対応付ける」ことにある。リストがどれだけ完全でも、リスクに対応付けられなければ、ただの紙だ。
棚卸しに行動を駆動させる
SBOM を CI/CD に接続すれば、静的な書類から生きた防御へと変わる：新たに導入された高リスクコンポーネントは即座にブロックされ、ライセンス競合は警告を発し、脆弱性インテリジェンスはリアルタイムで還流する。コンプライアンスは副産物であり、本当の見返りは統制可能性だ。
それが CleanSource SCA の設計思想だ——棚卸しを生成するだけでなく、実行可能な統制に変える。