SBOMのベストプラクティス

これらをチーム全体に展開する方法は、エンジニアリングチーム横断のSBOM生成をご覧ください。

SBOMの生成

1. すべてのリリースについてCIで生成する

手作業で作ったSBOMは、誰かが読む前に古くなります。リリースをビルドするパイプラインのステップにするか、ステップなしでSBOMを生成するランナーを使い、SBOMなしで出荷されるリリースがないようにします。GitHub Actionsについては、GitHub ActionsでSBOMを生成する方法をご覧ください。

2. 出荷したビルドを記述する

ビルドはデフォルトでは再現可能ではありません。同じコミットを2回ビルドしても、同じ依存関係になる保証はありません。バージョンはビルド時に解決され、ステップも変わりうるからです。ノートPCで作ったSBOMや後からのスキャンが記述するのは似たビルドであり、出荷したビルドそのものではありません。リリースを生成したCIビルドからのSBOMだけが、その中身を証明します。ビルド時SBOMをご覧ください。

3. ロックファイル以上をカバーする

ロックファイルは出荷内容の記録ではありません。インストールスクリプトはコードをダウンロードし、Rustのビルドスクリプトはファイルを取得し、コンテナビルドは独自のOSパッケージを持つベースイメージを取り込みます。SBOMがカバーすべき範囲を決め、それをテストしましょう。ベースイメージのパッケージとビルドツールをSBOM内で検索してみてください。

4. 推移的依存関係と関係性を含める

脆弱性は通常、直接の依存関係より下にあります。フラットな一覧ではコンポーネントが存在することは分かっても、何をアップグレードすべきかは分かりません。SBOMに依存関係グラフを保持し、検出結果にそれを取り込んでいるパッケージが付くようにします。

5. 見えなかったものを明示する

2026年版Minimum Elementsは、SBOMの作成者に不明な情報を明示的に示すよう求めています。不完全であることを明示した不完全なSBOMは、完成しているように見える不完全なSBOMよりも価値があります。ツール、そのバージョン、生成時の状況も記録し、読み手がファイルのカバー範囲を判断できるようにします。SBOMの完全性も参照してください。

SBOMの保持

6. リリースごとに1つのSBOMを保持し、成果物に結び付ける

古いバージョンを使っている顧客から影響の有無を尋ねられたとき、必要なのは最新のSBOMではなく、そのバージョンのSBOMです。各SBOMは、それが記述するビルドと成果物とともに保存し、保持期間はリリースをサポートする期間に基づいて決めます。SBOM内のハッシュは、それを正確な成果物に結び付けるのに役立ちます。

7. フォーマットと識別子を決め、統一する

CycloneDXまたはSPDX、フォーマットのバージョン、識別子としてのパッケージURLを標準化します。SBOMの比較で苦労する原因の大半は、ツールが同じものを異なる名前で呼ぶことにあります。パイプラインで各ファイルを検証し、サプライヤーにも同じフォーマットを求めましょう。何をチェックし、どのツールで行うかはSBOM品質チェックリストにまとめています。

SBOMの活用

8. ビルド中のものだけでなく、出荷したものを監視する

SBOMが最も価値を発揮するのは、昨年リリースしたソフトウェアについてアドバイザリが公開された翌日です。そのとき、プルリクエストでのスキャンは役に立ちません。サポート対象のリリースについて保存したSBOMを新しい脆弱性データで再評価し、新しいアドバイザリが出たら、影響を受けるリリースの一覧がすぐ得られるようにします。

9. 検出結果を担当者に振り分け、判断を記録する

1,000件の脆弱性が一致したSBOMは、計画ではなく単なる一覧です。優先順位付けの手法で検出結果をランク付けし、それぞれを修正を担当するチームに送り、残りについて対応しなかった理由を、たとえばVEXステートメントに記録します。

10. 顧客と監査人に同じSBOMを使う

顧客、監査人、規制当局は似たような質問をしてきます。内容が食い違っていく別の文書を作るのではなく、自社のチームが使うSBOMで答えましょう。SBOMを共有する場合は、誰が閲覧でき、どのように更新を受け取るかを決め、サプライヤーにも同じことを求めましょう。

よくある間違い

間違い	問題になる理由	推奨される対応
リポジトリごとに1つのSBOM	特定のリリースについて何も分からない	リリースごとに1つ、成果物に結び付ける
監査のときだけ生成する	誰も出荷していないビルドを記述してしまう	すべてのリリースでCIで生成する
SBOMを完成品として扱う	新しいアドバイザリはリリース後に届く	監視を続ける
コンポーネント数だけを比較する	エントリーが誤っていれば、数が多くても意味がない	含まれていると分かっている特定のパッケージを確認する

CRACIでの対応

CRACIは、ビルドに依存するプラクティスをカバーします。CRACIはGitHub Actionsランナーであり、各ジョブが取得するすべてのパッケージを、どのロックファイルにも記載されない隠れた依存関係も含めて、完全性の状態付きのCycloneDXまたはSPDXのSBOMに記録します。プランの保持期間内で過去のすべてのビルドとそのSBOMを保持し、新たな脆弱性が現れるたびに監視対象のSBOMを再評価し、脆弱な依存関係を含んでいたビルドを示します。セキュリティチームは検出結果をトリアージし、修正を担当するチームに送ります。管理ツールの比較についてはSBOM管理を、またはおすすめのSBOMツールをご覧ください。

SBOMのベストプラクティスに関するよくあるご質問

SBOMはいつ生成すべきですか？

リリースを生成するCIビルドの中で、毎回生成します。その時点で作られたSBOMは出荷したものを記述しますが、後から作られたSBOMが記述するのは再ビルドやスキャンの結果です。

SBOMはどれくらいの期間保持すべきですか？

少なくともリリースをサポートする期間に加えて、規制当局や契約が求める期間です。古いバージョンのユーザーが新しい脆弱性の影響を受けるかどうかを判断するには、そのバージョンのSBOMが必要です。

SBOMは自動化すべきですか？

はい。手作業のSBOMは次のリリースまでに古くなります。パイプラインでSBOMを生成し、そこで検証し、ビルドとともに保存しましょう。

SBOMを顧客と共有すべきですか？

顧客や規制当局から求められたときに、納得できる条件で共有しましょう。SBOMは自社が何を使っているかを明らかにするため、多くの企業は公開するのではなく、求めに応じて共有しています。

SBOMとSBOM管理の違いは何ですか？

SBOMは1つのファイルです。SBOM管理は、SBOMをリリースごとに保存し、新たな脆弱性について監視し、必要とする人が利用できるようにする継続的な取り組みです。