prEN 40000-1-3：EUサイバーレジリエンス法（CRA）に基づく脆弱性ハンドリングとSBOM作成の水平規格

Tech
【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): 特定の脆弱性が、自社製品の構成において「実際に悪用可能か」を示すフラグ。誤検知によるパッチ対応コストを削減します。

【セキュリティ考慮事項】

  1. 報告プロセスの機密性: 修正パッチが公開される前の脆弱性情報は極めて機密性が高く、報告経路（発見者から製造者）にはPGP/GPGやTLS 1.3を用いた暗号化通信が必須。

  2. 整合性の確保: 提供されるSBOMおよびVEXファイルが改ざんされていないことを保証するため、デジタル署名（Ed25519等）の付与が強く推奨される。

  3. ダウンストリームへの影響: 依存ライブラリの脆弱性が判明した際、自社製品への影響有無を迅速に判断し、VEXを更新し続ける継続的監視体制が必要。

【まとめと実装への影響】

  1. 開発パイプラインへのSBOM自動生成の組み込み: ビルドプロセス（CI/CD）と連動し、CycloneDX等の標準形式でSBOMを自動出力する体制が不可欠となる。

  2. PSIRT（Product Security Incident Response Team）の確立: 技術的な修正だけでなく、ENISA等への法的報告期限（24時間以内の速報等）を遵守するための組織的なプロセス整備が求められる。

  3. 資産管理との統合: ネットワークエンジニアは、導入済み機器のSBOMを管理システムに取り込み、VEX情報を基にしたリスクベースのパッチ管理へと移行する必要がある。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました