【Meta-Data】
{
"status": "draft",
"topic": "prEN 40000-1-3 (CRA Vulnerability Handling)",
"reference": ["CEN/CENELEC JTC 13 WG 8", "Cyber Resilience Act (CRA) Annex I Section 2"],
"engineer_level": "Senior Network/Security Engineer",
"focus": ["SBOM", "VEX", "Vulnerability Lifecycle"]
}
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
prEN 40000-1-3：EUサイバーレジリエンス法（CRA）に基づく脆弱性ハンドリングとSBOM作成の水平規格
【背景と設計目標】
EUサイバーレジリエンス法（CRA）適合に必要な、デジタル製品のライフサイクル全体における脆弱性管理とSBOM提供の具体的要件を定義。既存のISO/IEC 29147/30111を包含し、法的強制力を持つ適合性評価基準として新規設計された。
【通信シーケンスと動作】
prEN 40000-1-3では、脆弱性発見から修正、エンドユーザーへの通知（VEX形式）までの協調的脆弱性開示（CVD）プロセスを規定しています。
sequenceDiagram
participant "Finder as 脆弱性発見者 (Researcher)"
participant "Vendor as 製造者 (Manufacturer)"
participant "Authority as 当局 (ENISA/CSIRT)"
participant "User as エンドユーザー (Asset Owner)"
Finder ->> Vendor: 脆弱性報告 (Security Advisory Report)
Note over Vendor: 受領確認 (24時間以内推奨)
Vendor ->> Vendor: 内部トリアージ・再現確認
Vendor ->> Authority: 悪用された脆弱性の報告 (24時間/72時間ルール)
Vendor ->> Vendor: 修正パッチ/回避策の開発
Vendor ->> User: セキュリティアドバイザリ発行 (VEX/SBOM更新)
User ->> Vendor: パッチ適用状況のフィードバック
【データ構造 / パケットフォーマット】
本規格はバイナリプロトコルではなく、SBOM（Software Bill of Materials）およびVEX（Vulnerability Exploitability eXchange）のデータ交換フォーマットのセマンティクスを規定します。以下は、実装が推奨されるCycloneDX形式に基づくVEX情報の論理構造です。
+-----------------------------------------------------------+ | SBOM / VEX Logical Record Structure | +-----------------------------------------------------------+ | Offset (Field) | Length/Type | Description | +---------------------+-------------+-----------------------+ | BOM_Format | String | "CycloneDX" / "SPDX" | | Spec_Version | String | e.g., "1.5" | | Component_ID | UUID/PURL | Unique Identifier | | Component_Name | String | Product/Library Name | | Version | String | Semantic Versioning | | Vulnerability_ID | String | CVE-ID / GHSA-ID | | Analysis_State | Enum | [not_affected, | | | | affected, fixed, | | | | under_investigation] | | Remediation | String | Patch URL / Workaround| | Timestamp | ISO8601 | Last Updated | +---------------------+-------------+-----------------------+
【技術的な特徴と比較】
prEN 40000-1-3は、従来のベストプラクティスを「法的義務」へと昇華させます。
| 機能 / 特徴 | 従来の管理 (ISO/IEC 29147等) | prEN 40000-1-3 (CRA) |
|---|---|---|
| 法的強制力 | 任意 (ベストプラクティス) | 必須 (EU市場参入条件) |
| SBOM作成 | 推奨される場合がある | 原則必須 (コンポーネント透過性) |
| 脆弱性報告期限 | 規定なし (ベンダー任意) | 24h/72h (ENISAへの報告義務) |
| VEXの活用 | 限定的 (マニュアル対応) | 推奨 (機械判読可能な脆弱性ステータス) |
| 対象範囲 | ソフトウェア一般 | デジタル要素を持つ全製品 (HW含む) |
SBOM (Software Bill of Materials): 製品に含まれる全コンポーネント（OSS含む）の「成分表」。サプライチェーン攻撃対策の核となります。
VEX (Vulnerability Exploitability eXchange): 特定の脆弱性が、自社製品の構成において「実際に悪用可能か」を示すフラグ。誤検知によるパッチ対応コストを削減します。
【セキュリティ考慮事項】
報告プロセスの機密性: 修正パッチが公開される前の脆弱性情報は極めて機密性が高く、報告経路（発見者から製造者）にはPGP/GPGやTLS 1.3を用いた暗号化通信が必須。
整合性の確保: 提供されるSBOMおよびVEXファイルが改ざんされていないことを保証するため、デジタル署名（Ed25519等）の付与が強く推奨される。
ダウンストリームへの影響: 依存ライブラリの脆弱性が判明した際、自社製品への影響有無を迅速に判断し、VEXを更新し続ける継続的監視体制が必要。
【まとめと実装への影響】
開発パイプラインへのSBOM自動生成の組み込み: ビルドプロセス（CI/CD）と連動し、CycloneDX等の標準形式でSBOMを自動出力する体制が不可欠となる。
PSIRT（Product Security Incident Response Team）の確立: 技術的な修正だけでなく、ENISA等への法的報告期限（24時間以内の速報等）を遵守するための組織的なプロセス整備が求められる。
資産管理との統合: ネットワークエンジニアは、導入済み機器のSBOMを管理システムに取り込み、VEX情報を基にしたリスクベースのパッチ管理へと移行する必要がある。
コメント