EU Cyber Resilience Act (CRA) 対応：脆弱性ハンドリング水平規格 EN 18031-3 (prEN 40000-1-3) と SBOM 義務化の技術詳解

Tech

[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: 人間が読むドキュメントではなく、自動化された脆弱性スキャナが処理できる形式であることを重視。

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

  1. SBOM自体の改ざん耐性: SBOMデータが偽装されると、脆弱性のあるコンポーネントが隠蔽されるリスクがある。デジタル署名（sigstore等）による完全性の担保が不可欠。

  2. 情報漏洩のジレンマ: 詳細なSBOMは攻撃者にとっても「攻撃のロードマップ」になり得る。そのため、SBOMの公開範囲を「顧客のみ」にするか「パブリック」にするかのポリシー設計が必要。

  3. VEXの即時性: パッチ未公開段階での脆弱性情報の取り扱いは、責任ある開示（Coordinated Disclosure）に基づき、ENISAへの通知タイミングと一般公開の同期に注意を要する。

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

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

  1. 開発パイプラインへのCI/CD統合: SBOM生成をビルドプロセスに組み込み、リリースごとに最新のCycloneDX/SPDXファイルが自動生成される仕組みを構築すること。

  2. 資産管理(EAM/CMDB)との連携: ネットワーク上のデバイスからSBOMを動的に取得、または中央リポジトリで管理し、CVE情報と突合させる運用フローの設計。

  3. 法規制への適合証明: 技術ファイルの一部としてSBOMが位置づけられるため、監査に耐えうるバージョン管理と、サプライヤー（上流OS/ライブラリ）からのSBOM収集プロセスの確立。

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

コメント

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