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

Tech

{ “status”: “draft”, “topic”: “EN 40000-1-3 (CRA Horizontal Standard for Vulnerability Handling)”, “reference”: [“CRA Mandate M/596”, “CEN/CENELEC JTC 13”, “ISO/IEC 29147 context”], “author”: “Senior Network Engineer”, “technical_focus”: [“SBOM”, “VEX”, “CVD”, “Compliance Lifecycle”] }

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

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

【背景と設計目標】

欧州サイバーレジリエンス法（CRA）の施行に伴い、デジタル要素を持つ製品（PDE）の製造者には、製品ライフサイクル全体を通じた脆弱性管理と、24時間以内の脆弱性通知が義務付けられます。prEN 40000-1-3は、これらの法的要件を技術的な実務レベルに落とし込むための「水平規格（分野横断的な共通規格）」として設計されました。

従来のISO/IEC 29147（脆弱性開示）やISO/IEC 30111（脆弱性処理）を包含・拡張し、特にSBOM（ソフトウェア部品表）の作成・提供とVEX（Vulnerability Exploitability eXchange）による動的な脆弱性ステータスの伝達を強制力のあるプロセスとして定義することを目標としています。

【通信シーケンスと動作】

本規格が定義する「脆弱性ハンドリング・ライフサイクル」における、製造者、調整機関（ENISA）、およびエンドユーザー間の情報流通シーケンスを以下に示します。

sequenceDiagram
    participant "Finder as 脆弱性発見者 (Researcher/Scanner)"
    participant "Vendor as 製造者 (Manufacturer)"
    participant "ENISA as CSIRT/当局 (ENISA)"
    participant "User as エンドユーザー / 管理者"

    Finder ->> Vendor: 脆弱性報告 (Vulnerability Report)
    Note over Vendor: 1. トリアージ & 解析 (Triage)
    Vendor ->> ENISA: 悪用された脆弱性の通知 (24h以内/CRA準拠)
    Note over Vendor: 2. 修正プログラム/パッチ開発
    Vendor ->> Vendor: SBOM / VEX の更新
    Vendor -->> User: セキュリティ勧告 (Advisory) + VEXファイル
    User ->> Vendor: SBOM要求
    Vendor -->> User: SBOM (CycloneDX/SPDX) 提供

  1. 早期通知: CRAに基づき、悪用が確認された脆弱性は24時間以内に当局（ENISA）へ通知する必要があります。

  2. 継続的監視: 製品出荷後もSBOMに基づき依存コンポーネントの脆弱性を監視。

  3. 情報開示: 脆弱性が自社製品において「影響あり」か「影響なし（偽陽性）」かをVEX形式で機械可読な形で提供。

【データ構造 / パケットフォーマット】

本規格で重要視されるSBOMおよびVEXのデータ構造（概念モデル）を、ネットワークエンジニアが理解しやすいフィールド形式で整理します。

Structure: SBOM (Software Bill of Materials) - CycloneDX Reference
+-----------------------------------------------------------------------+
| Header (bomFormat, specVersion, serialNumber, version)                |
+-----------------------------------------------------------------------+
| Metadata (Timestamp, Tooling, Component: {Vendor, Name, Version})      |
+-----------------------------------------------------------------------+
| Components List (Recursive)                                           |
|  OFFSET:BITS | FIELD NAME          | DESCRIPTION                      |
|  0000:0128   | Component-ID        | UUID / PURL (Package URL)        |
|  0128:0064   | Hash-SHA256         | Integrity of the binary/source    |
|  0192:0032   | License-ID          | SPDX License Expression          |
|  0224:0032   | CPE-Identifier      | Common Platform Enumeration      |
+-----------------------------------------------------------------------+
| Dependencies (Relationship Graph)                                     |
+-----------------------------------------------------------------------+

Structure: VEX (Vulnerability Exploitability eXchange) - Vulnerability Status
+-----------------------------------------------------------------------+
| Vuln-ID (CVE-ID / GHSA-ID)                                            |
+-----------------------------------------------------------------------+
| Status (e.g., NOT_AFFECTED, AFFECTED, FIXED, UNDER_INVESTIGATION)     |
+-----------------------------------------------------------------------+
| Impact_Statement (Reason for 'NOT_AFFECTED' - e.g., Code not reachable)|
+-----------------------------------------------------------------------+

【技術的な特徴と比較】

EN 40000-1-3がもたらす変化を、従来の脆弱性管理アプローチと比較します。

項目 従来のアプローチ (ISO/IEC 29147等) CRA / EN 40000-1-3
法的強制力 任意（ベストプラクティス） 強制（CEマーク取得の必須要件）
SBOM管理 内部管理が主、提供は稀 必須化、機械可読なフォーマット要求
通知期限 合理的な期間（定義曖昧） 24時間以内の当局通知、72時間以内の詳細
脆弱性ステータス PDF等のドキュメント VEXによる自動化可能な動的ステータス
対象期間 サポート期間内 製品寿命または最低5年間のいずれか短い方

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

  1. SBOMの完全性（Integrity）: SBOM自体が攻撃者によって改ざんされると、脆弱なコンポーネントが隠蔽される恐れがあります。デジタル署名（sigstoreやOpenPGP）による信頼チェーンの確立が必須です。

  2. 情報漏洩のトレードオフ: 詳細なSBOMは攻撃者にとっても「攻撃のロードマップ」になり得ます。そのため、公開範囲（公開、顧客限定、当局限定）の適切なアクセス制御設計が求められます。

  3. VEXによる偽陽性排除: 脆弱性スキャナが検知しても、コードパスが実行されないなどの理由で影響がない場合、迅速に「Not Affected」のVEXを発行し、不要なパッチ適用の運用負荷を軽減します。

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

ネットワークエンジニアおよびシステム開発者が留意すべき3つのポイント：

  1. SBOM生成のパイプライン化: CI/CDパイプラインにCycloneDXやSPDX形式のSBOM生成ツールを組み込み、ビルドごとに成果物と紐付いたSBOMを自動生成する体制が必須となります。

  2. PURL (Package URL) への習熟: コンポーネントの識別には曖昧な名前ではなく、pkg:npm/left-pad@1.3.0のようなPURL形式を用いた厳密な依存関係管理が求められます。

  3. 脆弱性レスポンスの自動化: 24時間以内の通知義務は手動では困難です。脆弱性データベース（NVD/OSV）と自社SBOMを照合し、自動的にアラートを生成、当局への報告フローを半自動化するSIEM/SOARとの連携設計が必要になります。

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

コメント

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