Tone: Senior Network Engineer / Architect
Focus: Technical deep-dive, protocol-level data structures, compliance workflows
Language: Japanese
Constraints: Follow metadata tagging, use Mermaid for sequences, use text blocks for data structures
Key Theme: EN 40000-1-3 (CRA Horizontal Standard for Vulnerability Handling/SBOM) [/PROMPT_SPECIFICATION]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
EN 40000-1-3 ドラフト：CRA準拠の脆弱性ハンドリングとSBOM義務化の技術仕様
【背景と設計目標】
欧州サイバーレジリエンス法（CRA）の施行に伴い、デジタル要素を備える製品の製造者は、製品ライフサイクル全体を通じた脆弱性管理とSBOM（Software Bill of Materials）の提供が法的義務となる。EN 40000-1-3は、これら「水平的（Horizontal）」なセキュリティ要件を具体化する規格群の一部であり、特に脆弱性の収集、追跡、修正、および通知のプロセスと、それを支えるSBOMのデータ交換形式を定義する。
本規格は、従来のISO/IEC 29147（脆弱性開示）やISO/IEC 30111（脆弱性処理）をベースとしつつ、CRAが求める「悪用された脆弱性の24時間以内の当局通知」という過酷なタイムラインへの対応、およびサプライチェーンの透明性を担保するための機械読み取り可能なSBOM作成を新規に必須化する。
【通信シーケンスと動作】
EN 40000-1-3で想定される、脆弱性発見からVEX（Vulnerability Exploitability eXchange）配布、および当局への通知シーケンスを以下に示す。
sequenceDiagram
participant "Finder as 脆弱性発見者 (Researcher)"
participant "MFR as 製造者 (Product Manufacturer)"
participant "ENISA as ENISA / CSIRT (当局)"
participant "User as エンドユーザー / 管理システム"
Finder ->> MFR: 脆弱性報告 (RFC 9116 / security.txt)
MFR ->> MFR: 内部トリアージ & 修正プログラム開発
Note over MFR: 24時間以内の判定
MFR ->> ENISA: 悪用された脆弱性の早期警告 (CRA要件)
MFR ->> MFR: SBOM / VEX情報の更新
MFR ->> ENISA: 詳細通知 (72時間以内)
MFR ->> User: 修正パッチ & VEX (CycloneDX/SPDX) 配布
User ->> User: SBOM照合による影響範囲の自動特定
【データ構造 / パケットフォーマット】
SBOMおよびVEXのデータ交換において、EN 40000-1-3が準拠を促す論理的なメタデータ構造（JSON/XMLエンコーディング前段階の抽象モデル）を以下に整理する。
+---------------------------------------------------------------+ | Field Name | Logical Offset | Description | +---------------------------------------------------------------+ | HEADER_MAGIC | 0x00:32 | BOM Format Identifier| | SPEC_VERSION | 0x04:16 | Standard Version | | COMPONENT_COUNT | 0x06:16 | Number of Components| +---------------------------------------------------------------+ | [Component Structure Loop] | | +- COMP_ID | 0x00:UUID | PURL (Package URL) | | +- COMP_NAME | String | Name of Library | | +- COMP_VERSION | String | Semantic Versioning | | +- HASH_ALGO | 0xXX:8 | SHA-256/384/512 | | +- HASH_VALUE | Binary | Integrity Check | | +- LICENSE_ID | 0xXX:16 | SPDX License ID | +---------------------------------------------------------------+ | [VEX (Vulnerability Exploitability eXchange) Extension] | | +- VULN_ID | String | CVE-ID / GHSA-ID | | +- STATUS | Enum:8 | affected / not_aff. | | +- JUSTIFICATION | Enum:8 | code_not_reachable | | +- REMEDIATION | String | Patch Link / Workar.| +---------------------------------------------------------------+
【技術的な特徴と比較】
EN 40000-1-3が定義する「動的SBOM管理」と、従来の「静的な管理」との比較。
| 特徴 | 従来の脆弱性管理 | EN 40000-1-3 (CRA) |
|---|---|---|
| 更新頻度 | リリース時のみ（静的） | 脆弱性発見毎にVEXを更新（動的） |
| 透明性 | 任意の開示 | 機械読み取り可能なSBOMが必須 |
| 通知期限 | ベストエフォート | 悪用確認後24時間以内（早期警告） |
| サプライチェーン | 1次ベンダーのみ把握 | N次ベンダーまでPURLで追跡可能 |
| 主要技術キーワード | Excel/PDF管理, CVE | CycloneDX, VEX, PURL, CDX |
【セキュリティ考慮事項】
SBOMの整合性と署名: SBOM自体が改ざんされた場合、脆弱なコンポーネントが隠蔽されるリスクがある。EN 40000-1-3では、SBOMファイルへのデジタル署名（Ed25519等）による真正性の確保を強く推奨している。
VEXによる誤検知の削減: 「コンポーネントは存在するが、脆弱な関数を呼び出していない」場合のステータス（
code_not_reachable）を明示することで、脆弱性スキャナーによる過剰なアラートを抑制し、パッチ適用の優先順位付けを最適化する。情報開示のリスク（偵察活動への悪用）: 詳細なSBOMは攻撃者にとっても攻撃経路のマップとなる。このため、配布先を認証された顧客に限定する、あるいはVEX情報を適切にフィルタリングする制御が必要となる。
【まとめと実装への影響】
ネットワークエンジニアおよび開発者が留意すべき3つのポイント：
SBOM自動生成のCI/CD統合: 開発パイプライン（Build時）にCycloneDX等のSBOM生成ツールを組み込み、ソースコードとバイナリの整合性を自動検証する仕組みが必須となる。
VEX情報の継続的な同期: 製品出荷後も、新しいCVEが発表されるたびにVEXファイルを更新し、エンドユーザーの脆弱性管理システムとAPI（CSAF等）経由で連携できる環境を構築する必要がある。
インシデントレスポンスの高速化: 24時間以内の当局通知を遵守するため、ネットワーク上のIDS/IPSログとSBOMを紐付け、侵害が発生した際に影響を受けるデバイスを即座に特定する能力が求められる。
