ソフトウェア部品表（SBOM）

ソフトウェア部品表（SBOM）とは、ソフトウェアの中に含まれるすべてのコンポーネント（ライブラリ、そのバージョン、ライセンス、サプライヤー情報など）を機械可読形式で正式に一覧化したものです。

食品表示が原材料を一覧にするのと同じように、SBOMがあればこの製品にはXの脆弱なバージョンが含まれているかという問いに数秒で答えられます。SBOMがなければ、手作業による調査に数日かかることもあります。

重大な脆弱性が発生したとき、運用上まず問われるのは影響範囲です。影響を受けるコンポーネントを出荷している製品はどれかを確認しなければなりません。

Log4Shellのインシデントでは、SBOMを持つ組織はインベントリを検索し、数時間で優先順位を付けて対応できました。SBOMを持たない組織は、ビルドディレクトリをgrepで検索するのに数週間を費やしました。規制当局や大手の購入者は、調達条件としてSBOMを求めるようになっています。

• 脆弱性の影響を迅速に分析できます
• ライセンス遵守と義務を追跡できます
• 顧客や監査人にサプライチェーンの透明性を提供できます

主流のオープン標準は2つあります。通常、ツールを使って相互に変換できます。

• SPDX — Linux Foundationの標準で、ライセンスに強く、規制当局に広く受け入れられています
• CycloneDX — OWASPの標準で、セキュリティに重点を置き、脆弱性や依存関係の関係データをサポートします

独自の形式を作るのは避けてください。利用者やスキャナーはこれらの形式を想定しています。

各コンポーネントのエントリには、脆弱性フィードと照合できる十分な識別情報を含める必要があります。主なフィールドは次のとおりです。

• 名前とバージョン — 範囲ではなく正確な値
• PURL（package URL） — pkg:npm/lodash@4.17.21のような汎用識別子
• ハッシュ — 完全性を検証するための値
• ライセンス — SPDXライセンス識別子
• サプライヤー — それを生成した者

ソースから、またはビルド済みアーティファクトからSBOMを自動的に生成します。Syftは、両方の標準形式を出力できる、エコシステム横断型の一般的な生成ツールです。

異なる段階で生成されたSBOMは、それぞれ異なる実態を捉えます。

• ソースSBOM — マニフェストが宣言する内容です。バンドルされたコードやベンダリングされたコードを見落とす可能性があります
• ビルドSBOM — ビルドが実際に取り込んだ内容です。リリースについて最も正確です
• ランタイム／デプロイ済みSBOM — OSパッケージを含め、実行中のイメージに実際に存在する内容です

サプライチェーンを保証するには、実際のアーティファクトからビルド時に生成し、最終コンテナもスキャンしてOSレベルのパッケージを確認します。

SBOMは、コンポーネントを既知のCVEに対応付ける照合ツールに入力すると強力な効果を発揮します。生成と分析を分離できるため、新しいCVEが公開された日に古いSBOMをスキャンできます。

SBOMには、製品内では実際には悪用できない脆弱なコンポーネントが示されることがあります（脆弱な関数が一度も呼び出されない場合など）。VEX（Vulnerability Exploitability eXchange）文書には、その評価を記録します。

VEXによってノイズを減らせます。記載されたCVEを見てすべての顧客が慌てる代わりに、正当な理由を添えてnot_affected（影響なし）を、または是正策とともにaffected（影響あり）を表明できます。これにより、単なるインベントリが実行可能なトリアージ情報になります。

SBOMは、真正性があり、記述している正確なアーティファクトと結び付いている場合にのみ信頼できます。単独のファイルとして扱うのではなく、署名してアテステーションとして添付します。

手動で作成したSBOMはすぐに実態とずれてしまいます。パイプラインに生成処理を組み込み、すべてのリリースでビルドアーティファクトとして生成・保存します。可能であれば、同じジョブで署名とスキャンも行います。

• リポジトリだけでなく、ビルド済みアーティファクトから生成します
• バージョンをキーにして検索できるレジストリにSBOMを保存します
• 保存したSBOMを、最新のCVEフィードに対して定期的に再スキャンします
• 脆弱性スキャンの結果に基づいてリリースを制御します

SBOMを形式的なチェック項目として扱うと、気付かないうちに役に立たないものになります。

• 古い — 一度生成したきりで、再生成されていません
• 不完全 — OSパッケージ、静的リンクされたコード、またはベンダリングされたコードが含まれていません
• 未検証 — デプロイ済みアーティファクトと結び付けるハッシュがありません
• 未活用 — 生成されるだけで、スキャンも検索もされていません

目標は、一度だけ作成したJSONファイルではなく、正確で、再生成され、署名され、継続的にスキャンされるSBOMです。

学んだことをインシデントのシナリオに適用しましょう。

これで、ソフトウェアに何が含まれているかを一覧化し、その情報に基づいて対応できるようになりました。

• SBOMは、SPDXまたはCycloneDX形式で記述された、すべてのコンポーネントの機械可読リストです
• コンポーネントはPURL、バージョン、ハッシュ、ライセンスで識別します
• ビルド時に生成し、照合ツール（grype、osv-scanner）に入力してCVEを確認します
• VEXを使って実際の悪用可能性を表明し、誤警報を減らします
• CIで署名と自動化を行い、保存したSBOMを新しいフィードに対して再スキャンします

次は、署名によってアーティファクトの出所を証明します。