脆弱性分析およびSBOM
CRAは、お客様のソフトウェア部品表を生きた義務に変えます。すなわち、製品に何が含まれているかを把握し、それらの構成要素を新たな脆弱性について監視し、第14条の期限内にそれらを修正し報告することです。本ページは、そのループと、それを実行する無償ツールを順を追って説明します。
脆弱性を監視する
すべての構成要素を、ライブの脆弱性データ（NVD、EUVD）に対して継続的に相互参照します。バッチ処理された通知ダイジェストは24時間の期限を満たしません。
なぜダイジェストでは不十分か ↓CRA脆弱性アナライザー
お客様のSBOMおよび有効脆弱性リストをアップロードします。アナライザーは、すべての構成要素を国家脆弱性データベース（NVD）およびEU脆弱性データベース（EUVD）と相互参照し、使用終了（End-of-Life）の構成要素にフラグを付与し、お客様の技術ファイルに添付できるコンプライアンスレポートを生成します。
ハウツーガイド
適合したSBOMを生成する
ソフトウェア部品表は、附属書I、第II部、第(1)項に基づく厳格な法的要件です。本ガイドでは、必須の適用範囲および形式、その生成方法、そしてそれが監視ループにどのように供給されるかを取り上げます。
1 · 法的根拠
附属書I、第II部（「脆弱性対応要件」）、第(1)項は、製造者に以下を求めています。 「ソフトウェア部品表（SBOM）を一般的に利用され機械可読な形式で作成し、少なくとも製品の最上位の依存関係を網羅することを含め、脆弱性および構成要素を特定し文書化すること。」
解釈上の柔軟性を認める一部のCRAの規定とは異なり、少なくとも最上位の依存関係を網羅する機械可読なSBOMを作成する義務は、代替的なアプローチを認めません。
2 · 必須の適用範囲および形式
構成要素の網羅範囲。 SBOMはすべての最上位の依存関係を文書化しなければなりません。これは推奨される目標ではなく法定の下限です。可能な限り推移的（間接的）な依存関係をマッピングしてください。浅いSBOMは法律の文言を満たしますが、効果的な脆弱性管理にはしばしば不十分です。
形式。 CRAは「一般的に利用され、機械可読な形式」を義務付けています。許容される形式には以下が含まれます。
- SPDX （ISO/IEC 5962:2021）：広く採用されており、ライセンスに重点を置き、コンプライアンス文書化に適しています。
- CycloneDX：セキュリティを重視しており、脆弱性管理のワークフローに適しています。
- 認知されたツールからのその他の構造化形式（JSON、XML）は、基本要件の下で一般的に許容されます。
SBOMをPDFとして保存しないでください。PDFは、市場監視当局によって機械可読でないと異議を申し立てられる可能性があります。お客様のツールチェーンからのネイティブなJSON、XMLまたはタグ値出力を保存してください。
必須のメタデータ項目
| 項目 | 説明 |
|---|---|
| 構成要素名 | ライブラリ、パッケージまたはモジュールの一意の識別子 |
| バージョン | 正確なバージョン文字列。バージョン範囲では不十分です |
| サプライヤー／出所 | 発行者、ベンダーまたはオープンソースプロジェクトの名称 |
| 依存関係 | 直接的か推移的か。可能な場合は依存関係グラフ |
| 暗号学的ハッシュ | 構成要素ごとにSHA-256以上の完全性チェック |
| ライセンス識別子 | SPDXライセンス表現（例：Apache-2.0、MIT） |
3 · SBOMの生成
最新のプラットフォームの多くは、追加費用なしでビルド時に自動的にSBOMを生成できます。
- GitHub / Actions： 依存関係グラフ → SBOMをエクスポート（設定 → コードセキュリティ）。SPDX JSONを出力します。
- GitLab： CycloneDXレポートは、依存関係スキャンのCI/CDジョブによってネイティブに生成されます。
- Syft （Anchore）：コンテナイメージ、ファイルシステムおよびパッケージマニフェスト向けにSPDXおよびCycloneDXを生成するオープンソースのCLIです。
- cdxgen： npm、Maven、pip、Go、RustなどにわたるCycloneDX SBOM。
脆弱性審査。 いずれかのSBOMを最終化する前に、すべての構成要素を既知脆弱性データベースに照らして審査します。GitHubのスキャナーとSyftはいずれも、以下と統合します。 Grype のためのものです。既知の、既にパッチ適用済みの脆弱性を持つ構成要素を含めることは、附属書Iの直接的な違反であり、解釈上の柔軟性はありません。
構成要素のパッチ適用済みバージョンが存在する場合、それを使用しなければなりません。CRAの下では、解決済みの脆弱性について「リスク受容」のカテゴリーは存在しません。製品を上市する前に、すべての検出事項に対応してください。
4 · ライフサイクルの維持と保存
SBOMは生きた成果物であり、パッチ適用済みの構成要素、新しい依存関係、削除された使用終了の構成要素、サプライチェーンの変更を反映するため、製品のサポート対象ライフサイクル全体にわたって継続的に更新されます。SBOMを含むすべての版の技術文書は、最初の上市から少なくとも10年間保存されなければなりません……
第4節～第9節：ライフサイクル、罰則、BSI TR-03183-2および準備状況チェックリスト
ガイドの残りの部分では、10年間の保存義務、機密性およびサプライチェーンの開示、第14条の脆弱性報告との統合、監視頻度、ドイツのより厳格なBSI規則、制裁金（最大1,500万€または売上高の2.5％）、そしてすぐに使える準備状況チェックリストを取り上げます。