製造者のCRA脆弱性対応フローを整備する：受付、証拠、報告期限の管理

目的

2026年10月25日時点の情報である。インシデント発生時に証拠、製品の責任主体、報告期限を取り出せるよう、製造者の脆弱性対応フローを整備する。フローを更新する際は、第14条、附属書I、最新のENISA SRP利用手順を再確認すること。これは準備手順の提案であり、ある組織が適合性評価に合格したと主張するものではない。

第14条の報告義務は2026年9月11日から適用されている。第71条は、附属書Iの脆弱性対応義務を含む、より広範な要件の適用開始を2027年12月11日と定めている。後から適用される義務への準備は現在の報告にも役立つが、それぞれの日付は区別しなければならない。欧州委員会の報告ガイダンス。

前提条件

製造者の対象製品、担当するエンジニアリングチーム、報告責任者、その代理担当者を特定する。アクセスを制限したインシデント記録、リリースと構成要素の情報へのアクセス、影響を受けるユーザーへの連絡経路を用意する。これらは組織体制に関する提案である。言語が都合よいという理由だけで選ぶのではなく、第14条(7)に照らして適切な調整担当CSIRTを確認する。

手順

1. 受付を明確な担当者につなげる。 附属書I第II部に記載された、協調的な脆弱性開示ポリシーと報告窓口を用意する。任意で設置するRFC 9116のsecurity.txtを使って、研究者をそれらへ案内できる。HTTPSの/.well-known/security.txtで公開し、必須フィールドのContactとExpiresを含め、Policyでポリシーへリンクする。ファイルとリンク先を最新の状態に保つ。RFC 9116、第2節、第3節、第5節。

2. 直ちに案件記録を作成する。 実務的な記録設計として、受信時刻、受け取った証拠、報告対象の事象を認識した時刻、判断の責任者、その後の改訂を分けて記録する。元の証拠を保全し、評価を変更した理由を説明する。内部承認によって、認識時刻を黙ってリセットしてはならない。

3. 問題をリリースに対応付ける。 製品とリリースの識別子に加え、ソフトウェア部品表（SBOM）を維持する。附属書I第II部(1)の要件が適用される場合、少なくとも直接の依存関係を網羅した、一般に使われる機械可読形式が必要となる。本手順では、これらの記録を出荷済みリリースに関連付け、影響を受ける製品一覧を再構成できるようにすることを提案する。SBOMは構成の一覧であり、悪用の証拠ではない。

4. 法定の報告要件を個別に評価する。 第3条(42)では、実際の悪用と判断するには、悪意ある行為者がシステム所有者の許可なく脆弱性を悪用したという信頼できる証拠が必要である。重大なインシデントは、第14条(5)の両方の基準に照らして評価する。証拠と未解決の問いを記録する。深刻度スコアだけでは、実際の悪用は確認できない。手順1、3、4は規則に基づく。

5. 期限の記録を維持する。 速やかに対応するという要件を保ちつつ、認識した時点から24時間と72時間の段階を予定する。脆弱性の最終報告は是正措置または緩和措置が利用可能になった時点から、インシデントの最終報告はインシデント通知の提出時点から管理する。受領確認、提出した各版、当局からの照会をまとめて保存する。

6. プラットフォームへのアクセスと連絡体制を用意する。 ENISAは、多要素認証を使用する個人のEU Loginアカウントを必須としている。10月のFAQは、通知が必要になった時点でSRP登録を開始することを推奨しているため、EU Loginへのアクセスは事前に用意する。当局への報告と並行して、影響を受けるユーザーへの連絡も維持する。ENISA SRP FAQ、質問9。

7. 内部でリハーサルする。 架空の製品事例を使い、本番の報告プラットフォームの外で報告案を作成する。代理担当者に証拠を探し出して期限を再構成してもらい、受領先を選んだ理由を説明してもらう。不足していた情報を記録して修正し、うまくいかなかった引き継ぎをもう一度実施する。

期待される結果

レビュー担当者は、散在するメッセージから時系列を再構成せずに、1つの案件を受付から製品との対応付け、報告要件の評価、提出、ユーザーへの連絡まで追跡できる。

限界と検証の根拠

リハーサルや実地運用の成果を報告するものではない。本提案は、規則、欧州委員会のガイダンス、2026年10月15日更新のENISAのFAQ、RFC 9116を組み合わせている。連絡先ファイルの公開も、リハーサルの成功も、適合性の証明にはならない。製品の適用範囲や見解が分かれる報告要件の評価には、引き続き専門知識を持つ者のレビューが必要である。