SBOMとOSV-Scannerで依存関係リスクを棚卸しする実習

「使っているつもりがないライブラリ」まで見えるようにする

サプライチェーン攻撃の怖さは、攻撃者が自分たちの境界を直接破らなくても、依存しているソフトウェア、ビルド基盤、パッケージ公開アカウントを経由して入ってくる点にあります。CyberLens のニュースでも、npm や PyPI をまたぐ悪意あるパッケージ、AI関連ライブラリのCI/CD侵害、人気パッケージの短時間汚染を扱ってきました。

このレッスンでは、SBOM（Software Bill of Materials）と OSV-Scanner を使い、依存関係の棚卸しから脆弱性の優先度付けまでを実習します。目的は「スキャンして終わり」ではありません。どの依存関係が、どの資産に、どの程度の対応優先度で影響するのかを説明できるようにすることです。

今回の到達点

この実習で身につけるのは、次の流れです。

• SBOMを「提出用の書類」ではなく、影響範囲を調べる索引として使う
• OSV-Scannerで依存関係と既知脆弱性を照合する
• CISA KEV、到達可能性、公開面、代替策を使って対応優先度を決める
• SLSAの考え方を使い、ビルド由来のリスクを棚卸しに含める

脆弱性管理は、CVSS の点数順に並べるだけでは現場で破綻します。攻撃者が実際に使っているか、インターネットに露出しているか、修正できない理由があるかまで含めて判断します。

SBOMでまず見るべきもの

SBOM は、ソフトウェアの部品表です。CycloneDX の公式説明では、コンポーネント、依存関係、関係性を機械可読な形式で表現し、脆弱性やライセンス、調達判断に使えることが強調されています。

最初に見るべき項目は多くありません。

観点	見るもの	なぜ必要か
コンポーネント名	npm、PyPI、Maven などのパッケージ名	脆弱性データベースと照合するキーになる
バージョン	実際に組み込まれている版	影響有無と修正版確認に必要
依存関係	直接依存か推移的依存か	自分たちが更新できる範囲が変わる
パッケージURL	pkg:npm/... のようなPURL	ツール間で同じ部品を識別しやすい
生成日時	いつの状態か	古いSBOMでは判断を誤る

SBOM は「作った瞬間に古くなる」資料です。CIで生成し、リリース物とひもづけて保存する運用にしなければ、インシデント発生時に役に立ちません。

npmプロジェクトでSBOMを作る

npm には npm sbom コマンドがあり、CycloneDX または SPDX 形式の SBOM を生成できます。pnpm や他のエコシステムを使っている場合は、対応する公式ツールや組織標準のSBOM生成ツールに読み替えてください。

bom.json に bomFormat、specVersion、components が含まれていれば、最低限の部品表として扱えます。実務では、リリース番号、Gitコミット、コンテナイメージのダイジェストと一緒に保存すると、後から「どの成果物が影響を受けるか」を追いやすくなります。

OSV-Scannerで既知脆弱性を照合する

OSV-Scanner は、依存関係情報をOSVデータベースの脆弱性情報と照合するためのツールです。公式ドキュメントでは、ソースツリー、lockfile、SBOM、コンテナイメージを対象にできると説明されています。

SBOMを対象にする場合は、OSV-Scanner v2 の scan source が仕様に沿ったファイル名の SBOM を自動検出します。検出されない場合は、ファイル名や形式がツールの期待に合っているかを確認してください。

脆弱性を優先度へ変換する

ここからが実務です。検出結果をそのまま「全部すぐ修正」とすると、開発チームは疲弊します。逆に、CVSS が低いから放置すると、実際に悪用されている脆弱性を見逃すことがあります。

優先度付けでは、次の4つを並べて見ます。

判断軸	高優先に寄せる条件
悪用実績	CISA KEV Catalog に掲載されている
到達可能性	アプリの実行経路上にあり、外部入力から触れる
露出面	インターネット公開、認証前、管理面、CI/CDなど高権限領域
修正容易性	パッチあり、破壊的変更なし、テストで退行を確認できる

たとえば、CVSS 9.8 でも開発用ツールの未使用機能なら、即日停止より計画修正が妥当な場合があります。逆に CVSS が中程度でも KEV に入り、インターネット公開面で使われているなら、優先度は上げるべきです。

トリアージ表を作る

スキャン結果をチームで扱うには、次のような表に変換します。

項目	記入例
パッケージ	example-lib
現在バージョン	1.2.3
修正版	1.2.7
依存種別	直接依存 / 推移的依存
影響資産	決済API、管理画面、社内ツールなど
外部露出	あり / なし
KEV掲載	あり / なし
対応方針	更新、設定回避、利用停止、リスク受容
期限	例: 72時間以内、次回リリース、月次
例外理由	テスト未整備、互換性破壊、ベンダー待ちなど

例外管理も重要です。「直さない」のではなく、期限付きで「なぜ今は直せないか」「どの補完策を置いたか」を記録します。ここが曖昧だと、半年後に同じ脆弱性が残ります。

SLSAの観点を足す

依存関係の脆弱性だけを見ていると、ビルドプロセスの改ざんを見落とします。SLSA はソフトウェア成果物のサプライチェーン保証を段階的に整理するフレームワークで、Build L1 では provenance（どのプロセスでビルドされたか）が存在すること、Build L2 では署名された provenance とホストされたビルド基盤、Build L3 ではより強化されたビルド基盤が焦点になります。

小さなチームでも、いきなり高いレベルを目指す必要はありません。まずは次を確認します。

• 本番成果物がどのGitコミットから作られたか追えるか
• CI/CDの実行者、ワークフロー、入力が記録されているか
• リリース物のハッシュやコンテナダイジェストを保存しているか
• 手元PCから本番ビルドを作る運用が残っていないか
• 依存関係の更新がレビューなしで自動反映されていないか

SBOMが「何でできているか」を示すなら、provenance は「どう作られたか」を示します。両方が揃って初めて、サプライチェーンインシデントの影響調査が短くなります。

ニュースを自分たちの棚卸しに変換する

CyberLens のニュースで扱った axios のサプライチェーン汚染 や Contagious Interviewのクロスエコシステム攻撃 は、単なる読み物で終わらせるともったいない題材です。

ニュースを見たら、次のように自分たちの棚卸しへ変換します。

• 該当パッケージ名、名前の似たパッケージ、関連エコシステムをSBOMで検索する
• lockfile と実行環境の両方を確認し、開発環境だけの依存か本番依存かを分ける
• CI/CDのキャッシュ、コンテナベースイメージ、テンプレートリポジトリにも残っていないかを見る
• 影響なしと判断した理由を、チケットやインシデント記録に残す

「うちは使っていないと思う」ではなく、「SBOMとlockfileで確認した結果、対象バージョンは存在しない」と言える状態を作ることが、この実習の最終ゴールです。

参考にしたい一次情報

• OSV-Scanner 公式ドキュメント
• OSV-Scanner Usage
• CycloneDX SBOM
• SLSA Security Levels
• CISA Known Exploited Vulnerabilities Catalog

まとめ

サプライチェーン防御は、派手な検知よりも地味な棚卸しが効きます。SBOMを残し、OSV-Scannerで既知脆弱性を照合し、KEVや露出状況で優先度を決め、例外を期限付きで管理する。この流れができている組織は、新しい脆弱性やパッケージ汚染が出ても、慌てずに影響範囲を切り分けられます。

次は、攻撃の全体像を理解する サプライチェーン攻撃 と、優先度付けの基礎になる 脆弱性管理 を読み返すと、今回の実習が運用設計につながります。