SBOM
顧客からのSBOM提出依頼への答え方
顧客、見込み顧客、または調達チームからSBOMを求められました。依頼はセキュリティ質問票や契約書、あるいは1行のメールで届くこともあり、たいてい期限付きです。相手が何を知りたいのか、何を送るべきか、そして次の依頼を日常業務にする方法をご紹介します。
更新日
メーカーにコンポーネントや組み込みソフトウェアを供給していますか？契約、VEX、納品するソフトウェアバージョンごとのSBOMを扱うサプライヤー向けSBOMガイドをご覧ください。
顧客が今、SBOMを求める理由
- Cyber Resilience Act。EUで販売するメーカーは自社製品のSBOMを必要とし、取り込むコンポーネントにも注意を払わなければならないため、この問いがサプライチェーンの下流へと伝わっていきます。
- NIS2。必須事業体と重要事業体は、サプライチェーンのセキュリティに取り組まなければなりません。指令はSBOMを名指ししていませんが、SBOMは購入者がサプライヤーの出荷するものを把握する手段の1つです。NIS2、ISO 27001、SOC 2のエビデンスとしてのSBOMをご覧ください。
- 業界別の規則。FDAの第524条BはサイバーデバイスにSBOMを求めており、ほかの業界にも独自の規則があります。
- 顧客自身の脆弱性対応。製品の中身を把握している顧客は、サポートチケットを起票しなくても、新しいCVEが自社に影響するかどうかを判断できます。
送る前に合意しておくべきこと
| 確認事項 | 重要な理由 |
|---|---|
| どの製品とバージョンか | SBOMは1つのリリースを記述します。最新のビルドではなく、顧客が実行しているものを送ります。 |
| どのフォーマットか | ほとんどの依頼ではCycloneDXまたはSPDXが受け付けられます。特定のバージョンが必要かどうかを確認します。 |
| どこまで深くか | トップレベルの依存関係だけでは不十分な場合があります。推移的依存関係も求められると考えておきましょう。 |
| 1回限りか、リリースごとか | 契約でリリースごとに新しいSBOMが求められることがあり、その場合は手作業での対応は現実的ではありません。 |
| どのような条件でか | SBOMは製品がどう構築されているかを示します。機密保持の条件とファイルの受け渡し方法について合意します。 |
良い回答に含まれるもの
- 顧客が実行している正確なリリースについての、合意したフォーマットのSBOM。
- 名前、バージョン、サプライヤー、ライセンス、パッケージ識別子を備えたすべてのコンポーネント。
- 推移的パッケージがどこから取り込まれたかをたどれるよう、コンポーネント間の依存関係。
- 作成日、作成したツール、元になったビルド。
- SBOMがカバーしていない範囲についての率直な注記（SBOMの完全性を参照）。
ファイルの実例についてはSBOMの例を、2つのフォーマットについてはCycloneDXとSPDXの比較をご覧ください。顧客が受け取った時点で確認しそうな内容については、SBOM品質チェックリストをご覧ください。
後で問題になるミス
- 出荷したビルドではなく最新のビルドを送る。ビルドはデフォルトでは再現可能ではないため、同じコミットを再ビルドしても同じSBOMになる保証はありません。顧客が受け取ったものを示せるのは、そのリリースを作成したビルドのSBOMだけです。
- その場限りで手作業で作成する。1回の依頼には応えられますが、次の顧客、次のリリースのたびに繰り返さなければなりません。SBOMの自動化をご覧ください。
- 繰り返せる以上のことを約束する。「リリースごとに送ります」は契約に書くのは簡単ですが、自動化なしで守り続けるのは困難です。
- SBOMを送れば終わりと考える。次に来る問いは「このCVEの影響を受けていますか」であり、それは次の大きな脆弱性とともにやってきます。
次の依頼に備える方法
SBOMがすでに存在していれば、依頼への対応は簡単になります。リリースをビルドするパイプラインですべてのリリースのSBOMを作成し、リリースと一緒に保管し、新たな脆弱性について監視します。そうすれば依頼への対応はダウンロードと短い添え書きだけで済み、続く問いにも同じ記録から答えられます。
CRACIでの対応
CRACIは、自社のランナーで実行されるGitHub ActionsのすべてのビルドからSBOMを記録するため、誰かに求められたときには各リリースのSBOMがすでに存在しています。
- CycloneDXまたはSPDXでのエクスポート。推移的依存関係とコンポーネントで見つかった脆弱性も含まれます。
- ビルドそのものから得たエビデンス。SBOMのすべてのコンポーネントは実際にビルドに含まれていたものであり、ロックファイルベースのツールが見逃す隠れた依存関係も記録されます。
- すべてのジョブに完全性の状態。送る前に、何を送ろうとしているのかがわかります。
- ビルド履歴。保持期間内であれば、過去のビルドとそのSBOM、そしてどのビルドに脆弱な依存関係が含まれていたかを確認できます。
- 続く問いへの回答。CRACIは監視対象のSBOMを再評価し続け、VEXに対応し、インベントリビューでどの製品がどのバージョンを実行しているかを示します。
顧客からのSBOM提出依頼：よくあるご質問
顧客にSBOMを提供する義務はありますか？
市場と契約によります。Cyber Resilience ActはSBOMを技術文書の一部としており、技術文書は要請に応じて市場監視当局に提出するもので、公開は求められていません。顧客がSBOMを受け取る権利は通常は契約から生じるため、合意内容を確認してください。
どのSBOMフォーマットで送るべきですか？
CycloneDXまたはSPDXのうち、顧客が求める方です。特に希望がなければ、どちらでも構いません。顧客のツールに特定のバージョンが必要かどうかを確認してください。
推移的依存関係を含める必要はありますか？
Cyber Resilience Actが求めるのは少なくともトップレベルの依存関係ですが、多くの購入者は依存関係ツリー全体を期待しており、脆弱性は推移的パッケージに潜んでいることがよくあります。完全なSBOMを送る方が安全です。
SBOMはNDAのもとで顧客に渡すべきですか？
それはお客様と顧客が決めることです。SBOMは製品が何でできているかを示すため、多くのベンダーは公開するのではなく、既存の契約やNDAのもとで共有しています。
更新したSBOMはどのくらいの頻度で送るべきですか？
合意した頻度です。依存関係はリリースごとに変わるため、リリースごとに新しいSBOMを送るのが誠実な基本方針であり、それが現実的なのはSBOMがビルドから生成される場合だけです。
顧客から古いリリースについて尋ねられたら？
そのリリースを作成したビルドのSBOMが必要です。CRACIは保持期間内のビルド履歴を保管します。デフォルトは180日間で、Enterpriseではカスタムの保持期間を設定できるため、それより長く保管する必要があるものはエクスポートしてください。
SBOMを作ったことがありません。何から始めればよいですか？
顧客が実行しているリリースと、実際のビルドをもとに動作するツールから始めましょう。GitHub Actionsをお使いなら、ビルドをCRACIランナーに移すと、最初の実行から記録されたSBOMが得られます。