[PROTOCOL_INFO] NAME: EN 18031-3 (Vulnerability handling) / prEN 40000-1-3 (CRA Horizontal Standard) STATUS: Draft (CENELEC JTC 13 WG8) LAYER: Management/Governance (Supply Chain Security) KEYWORDS: CRA, SBOM, VEX, Vulnerability Management, CycloneDX, SPDX, EU Policy [/PROTOCOL_INFO]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
EU Cyber Resilience Act (CRA) 対応：脆弱性ハンドリング水平規格 EN 18031-3 (prEN 40000-1-3) と SBOM 義務化の技術詳解
【背景と設計目標】
欧州サイバーレジリエンス法（CRA）の施行に伴い、デジタル要素を持つ製品（PDE）に対して「設計段階からのセキュリティ」と「ライフサイクル全体の脆弱性管理」が法的義務となります。本規格（EN 18031-3 / 旧仮称 40000-1-3）は、これらの法的要求を具体化するための「水平規格（分野横断的規格）」として策定されました。
主な目標は、サプライチェーンにおけるコンポーネントの透明性を確保する「SBOM（Software Bill of Materials）」の作成義務化と、発見された脆弱性を修正・通知する「脆弱性ハンドリングプロセス」の標準化です。従来の任意ガイドライン（ISO/IEC 29147等）をベースとしつつ、CRA遵守のための強制力を持った技術要件へと再定義されています。
【通信シーケンスと動作】
CRA環境における脆弱性報告と修正プログラム配布、およびSBOM/VEX（Vulnerability Exploitability eXchange）の更新プロセスを以下に示します。
sequenceDiagram
participant "Finder as 脆弱性発見者 (Researcher)"
participant "MFR as 製造者 (Manufacturer)"
participant "SBOM_Repo as SBOM/VEX リポジトリ"
participant "EU_Agency as ENISA (欧州情報セキュリティ庁)"
participant "User as エンドユーザー / 管理者"
Finder ->> MFR: 脆弱性報告 (Coordinated Disclosure)
MFR ->> MFR: 内部検証・修正パッチ開発
MFR ->> EU_Agency: 悪用された脆弱性の通知 (24時間以内/CRA要件)
MFR ->> SBOM_Repo: SBOM/VEXデータの更新 (脆弱性ステータスの書き換え)
SBOM_Repo -->> User: 自動スキャン/通知 (CycloneDX/SPDX)
MFR ->> User: 修正パッチ/ファームウェアの配布
このシーケンスでは、製造者が脆弱性を検知してから、単にパッチを出すだけでなく、SBOMに関連付けられた「VEX情報」を更新することで、ユーザー側での自動的なリスク判断（影響の有無）を可能にすることが核となっています。
【データ構造 / パケットフォーマット】
CRAが要求するSBOMおよび脆弱性情報の交換において、事実上の標準となるCycloneDX形式（JSONベース）の論理構造を定義します。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | bomFormat (String: "CycloneDX") | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | specVersion (e.g., "1.5") | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | serialNumber (UUID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Section: | | - Timestamp | | - Manufacturer Info / Product Model | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Components List (Array): | | - Component Name, Version, PURL (Package URL) | | - SWID / Hash (SHA-256) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vulnerabilities (VEX Extension): | | - CVE-ID / Severity (CVSS) | | - Analysis State (Affected, Not_Affected, Fixed) | | - Remediation Plans | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
※物理的なパケットではなく、API経由で交換されるドキュメント構造の定義です。
【技術的な特徴と比較】
CRA対応規格（EN 18031-3）と、従来の一般的なソフトウェア管理手法の比較です。
| 比較項目 | 従来の手法（任意） | CRA/EN 18031-3（強制） |
|---|---|---|
| SBOM作成 | 大企業が限定的に実施 | 全てのPDE（デジタル製品）で必須 |
| 脆弱性通知先 | 任意（自社サイト等） | ENISAへの通知義務（悪用時） |
| 対応期間 | ベストエフォート | 製品寿命期間（最大5年等）の義務 |
| 情報の透明性 | ブラックボックスが多い | 構成成分(PURL)の明示が必須 |
| 脆弱性ステータス | セキュリティアドバイザリ | VEXによる機械可読な形式 |
技術キーワード解説：
VEX (Vulnerability Exploitability eXchange): SBOMとセットで利用され、「特定の脆弱性がその製品において実際に悪用可能か」を機械可読形式で示すデータ。
PURL (Package URL): ソフトウェアパッケージをプラットフォーム非依存で一意に識別するためのURI形式。
Machine-Readability: 人間が読むドキュメントではなく、自動化された脆弱性スキャナが処理できる形式であることを重視。
【セキュリティ考慮事項】
SBOM自体の改ざん耐性: SBOMデータが偽装されると、脆弱性のあるコンポーネントが隠蔽されるリスクがある。デジタル署名（sigstore等）による完全性の担保が不可欠。
情報漏洩のジレンマ: 詳細なSBOMは攻撃者にとっても「攻撃のロードマップ」になり得る。そのため、SBOMの公開範囲を「顧客のみ」にするか「パブリック」にするかのポリシー設計が必要。
VEXの即時性: パッチ未公開段階での脆弱性情報の取り扱いは、責任ある開示（Coordinated Disclosure）に基づき、ENISAへの通知タイミングと一般公開の同期に注意を要する。
【まとめと実装への影響】
ネットワークエンジニアおよび製品開発者が留意すべき3つのポイント：
開発パイプラインへのCI/CD統合: SBOM生成をビルドプロセスに組み込み、リリースごとに最新のCycloneDX/SPDXファイルが自動生成される仕組みを構築すること。
資産管理(EAM/CMDB)との連携: ネットワーク上のデバイスからSBOMを動的に取得、または中央リポジトリで管理し、CVE情報と突合させる運用フローの設計。
法規制への適合証明: 技術ファイルの一部としてSBOMが位置づけられるため、監査に耐えうるバージョン管理と、サプライヤー（上流OS/ライブラリ）からのSBOM収集プロセスの確立。
