{ “version”: “1.0”, “status”: “draft”, “protocol”: “prEN 40000-1-3”, “category”: “Standardization”, “target_audience”: “Network Engineers, Product Security Officers”, “context”: “EU Cyber Resilience Act (CRA) Compliance” }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Draft prEN 40000-1-3：Cyber Resilience Act（CRA）における脆弱性ハンドリングとSBOM作成の水平規格
【背景と設計目標】
EUサイバーレジリエンス法（CRA）遵守に必須となる、製品ライフサイクル全体での脆弱性管理プロセスとSBOM提供の標準化。ISO/IEC 29147等をベースとしつつ、法的義務としての報告フローを新規定義する。
【通信シーケンスと動作】
本規格では、脆弱性が発見されてからパッチが配布され、最終的にENISA（欧州連合サイバーセキュリティ機関）へ報告されるまでのプロセスを定義しています。特に「脆弱性開示」と「VEX（Vulnerability Exploitability eXchange）」の通知フローが重要です。
sequenceDiagram
participant Finder as 脆弱性発見者
participant "Vendor as 製造者 (Manufacturer)"
participant "ENISA as ENISA / 国際CSIRT"
participant User as エンドユーザー
Finder ->> Vendor: 脆弱性報告 (Coordinated Disclosure)
Note over Vendor: 24時間以内に初期受領確認
Vendor ->> Vendor: 脆弱性分析・SBOM照合
Vendor ->> ENISA: 悪用された脆弱性の報告 (CRA義務: 24h/72h以内)
Vendor ->> User: セキュリティアップデート通知 (VEX提供)
User ->> Vendor: アップデート適用 / SBOM更新
【データ構造 / パケットフォーマット】
SBOM（Software Bill of Materials）およびVEX情報の提供形式は、CycloneDXまたはSPDXをベースとした機械判読可能な構造が要求されます。以下は論理的なSBOM構成イメージです。
+-----------------------------------------------------------+ | SBOM Header (Format version, Timestamp, Author) | +-----------------------------------------------------------+ | Component List (Array of Objects) | | - Name (String): "OpenSSL" | | - Version (String): "3.0.7" | | - PURL (String): "pkg:generic/openssl@3.0.7" | | - Hash (Algorithm:Value): "SHA-256:e3b0c442..." | | - License (ID/Expression): "Apache-2.0" | +-----------------------------------------------------------+ | Dependencies (Graph Representation) | | - Component_A -> Component_B | +-----------------------------------------------------------+ | Vulnerability Info (VEX Profile) | | - CVE-ID: "CVE-2023-XXXX" | | - Status: "Fixed" / "Under investigation" / "Not affected"| +-----------------------------------------------------------+
【技術的な特徴と比較】
従来のアドホックな脆弱性対応と、prEN 40000-1-3が定めるCRA準拠の対応を比較します。
| 機能・特性 | 従来（Best Practice） | prEN 40000-1-3 (CRA対応) |
|---|---|---|
| SBOM作成 | 任意（顧客要求ベース） | 法的義務 (全デジタル製品) |
| 脆弱性報告先 | 自社窓口、PSIRT | ENISA/各国当局への報告義務 |
| 報告期限 | 合理的な期間内 | 24時間以内（悪用された場合） |
| 機械判読性 | PDF/Text等、形式不問 | CycloneDX/SPDX等の構造化データ |
| ライフサイクル | サポート終了まで（任意） | 原則5年または製品寿命（法的定義） |
【セキュリティ考慮事項】
SBOMの完全性保護: 悪意のある第三者がSBOMを改ざんし、脆弱なコンポーネントを隠蔽することを防ぐため、SBOMファイル自体へのデジタル署名が強く推奨されます。
情報の機密性: 脆弱性が修正される前の詳細な技術情報は、製造者と当局（ENISA）間のみで共有される必要があり、通信路のTLS等による暗号化が必須です。
VEXによる誤検知削減: SBOM単体では「コンポーネントが含まれている」ことしか分かりませんが、VEX（脆弱性活用可能性情報）を併用することで、その脆弱性が実際に製品内で到達可能（Exploitable）かどうかを示し、ユーザー側の不要なパッチ作業を抑制します。
【まとめと実装への影響】
ネットワークエンジニアや製品開発者が留意すべき3つのポイント：
自動生成パイプラインの構築: SBOMを手動で管理することは不可能です。CI/CDパイプラインに、ビルド成果物からCycloneDX等のフォーマットを自動生成するツールを組み込む必要があります。
サプライチェーン管理の厳格化: OSSだけでなく、サードパーティ製ライブラリのベンダーに対しても、CRA準拠のSBOM提供を契約条件に盛り込む必要が生じます。
迅速な報告体制の確立: 脆弱性の悪用を検知してから24時間以内に当局へ初期報告を行うプロセスは、技術部門だけでなく法務・広報を巻き込んだインシデントレスポンス計画の策定を必要とします。
コメント