なぜプロダクトマネージャーが脆弱性の開示と対応を管理するのか？CRA が求める結果は？
CRA の脆弱性義務は製品に結び付き、サポート期間全体にわたって続きます。附属書 I 第 2 部は脆弱性対応の要求を 8 項目挙げています。EU の JRC と ENISA による 2024 年の対応分析では次のとおりです。
| 規格 | 附属書 I 第 2 部との対応 |
|---|---|
| ISO/IEC 29147 | 8 項目中 4 項目（第 2、4、5、6 号） |
| ISO/IEC 30111 | 8 項目中 5 項目（第 2、4、5、6、8 号） |
SBOM（第 1 号）、定期的なテストとレビュー（第 3 号）、アップデートの安全な配布（第 7 号）はこの二つの規格に対応しておらず、他の規格や手順で補う必要があります。この報告書は分析文書で整合規格ではなく、適合推定は生じません。
外部に何を公表するか？顧客や研究者はどうやって報告窓口を見つけるか？
29147 の典型的な成果物は、製品の外向きの脆弱性窓口そのものです。
- security.txt と報告用メールアドレスまたはフォーム
- 受付と回答の SLA
- CVD 方針（セーフハーバー条項を含む）
- 公表テンプレートと公開手順、必要に応じた CVE 番号の申請手順
CRA も脆弱性報告の連絡先の提供（附属書 I 第 2 部第 6 号）と単一の連絡窓口の指定（第 13 条第 17 項）を求めています。これらの情報は製品文書とウェブサイトに載るため、プロダクトマネージャーは窓口に責任者がいて、回答期限を守れることを確認します。
修正とセキュリティアップデートを製品のリリースと出荷のリズムにどう組み込むか？
30111 は報告受領後の対応を五つのゲートに分け、各ゲートに責任者と期限が必要です。
| ゲート | 決めること |
|---|---|
| 受付と検証 | 報告が成立するか、再現できるか、どの製品とバージョンに影響するか |
| 深刻度評価 | どの基準で深刻度と対応期限を決めるか |
| 修正 | 修正、回避策、テストの担当は誰か |
| リリース | セキュリティアップデートを利用者にどう届け、公表をいつ行うか |
| 振り返り | 根本原因分析とプロセス改善 |
CRA は遅滞ない修正を求め、技術的に可能な場合はセキュリティアップデートを機能アップデートと分けて提供することを求めています。よくある欠落は、両者を一緒にしてしまうことと、製品・部品の一覧がなく影響範囲を判断できないことです。
サポート期間中の旧モデルや生産終了モデルも脆弱性対応が必要か？
必要です。CRA は製造者に、製品を市場に出した時からサポート期間全体にわたり、附属書 I 第 2 部に従って脆弱性に有効に対応することを求めています（第 13 条第 8 項）。
- サポート期間は 5 年以上、想定使用期間が 5 年未満なら想定使用期間
- 終了日（少なくとも年と月）は購入時に明確に表示（第 13 条第 19 項）
- 期間中に出した各セキュリティアップデートは、10 年以上またはサポート期間終了までのいずれか長い方の間、利用可能に（第 13 条第 9 項）
- セキュリティアップデートはカスタマイズ製品で別段の合意がある場合を除き無償
「旧バージョンと生産終了モデルの担当者がいない」は修正ゲートでよくある欠落です。生産終了計画でサポート期間中の責任者を指定します。
CRA の報告期限は発売後の保守を乱すか？
第 14 条の報告義務は 2026 年 9 月 11 日から適用され、2027 年 12 月 11 日より前に市場に出た製品も対象です。
- 積極的に悪用されている脆弱性：認識から 24 時間以内に早期警告、72 時間以内に通知、是正・緩和措置が利用可能になってから 14 日以内に最終報告
- 製品のセキュリティに影響する重大インシデント：24 時間以内に早期警告、72 時間以内に通知、インシデント通知から 1 か月以内に最終報告
報告は ENISA の単一報告プラットフォームから提出します。既存のセキュリティインシデント手順は良い土台ですが、インシデント対応は発生した攻撃を、脆弱性対応は報告された弱点を扱い、きっかけ、期限、成果物が異なるため、脆弱性専用のプロセスと記録が必要です。
小さな会社でも PSIRT が必要か？どこまでやれば証拠を示せるか？
大きな体制は不要ですが、明確な受付経路、責任者、回答プロセスは必要です。成果物は認証機関と顧客が監査できることを基準にします。
- 脆弱性対応の方針とプロセス文書
- 深刻度評価の基準（例：CVSS のローカライズ基準）
- 対応記録と SLA の報告の仕組み
- SBOM との連携手順
- 29147 の開示側とのインターフェース文書
現行版は ISO/IEC 29147:2018 と ISO/IEC 30111:2019 です。改訂は ISO/IEC JTC 1/SC 27 で登録されていますが、新版はまだ発行されていません。
積穗科研はプロダクトマネージャーの ISO/IEC 29147・30111 対応をどう支援するか？
積穗科研は 29147 と 30111 を対で導入し、引き継ぎ部分に監査上の欠落を残しません。
- security.txt、報告用メールアドレスまたはフォーム、受付と回答の期限、CVD 方針と公表手順
- 「誰が受け付け、誰が検証し、誰が評価し、誰が直し、誰がリリースし、どれだけ速く」を監査可能なプロセスと SLA に
- 複数製品ラインの企業には、脆弱性の影響範囲を横断的に評価する仕組み
- ISO 27001 取得済みの企業では、CVD プロセスを既存の ISMS に組み込み、文書と監査を共有
積穗科研自身の提供パイプラインは SBOM を毎日生成、署名、監視しています。副社長・取締役クラスのコンサルタントが外注せず一貫して支援します。詳しく：ISO/IEC 29147、ISO/IEC 30111、29147 コンサルタントの選び方、30111 コンサルタントの選び方。無料のメカニズム診断を申し込む
ほかの役割から見たこのサービス
同じ役割のほかのサービス
- プロダクトマネージャーと EU CRA：自社製品は対象か、発売前に何をそろえるか？
- プロダクトマネージャーと EU AI 法：製品の AI は発売前に何を終えるべきか？
- プロダクトマネージャーと IEC 62443-4-2：産業制御製品の認証で発売は遅れるか？
- プロダクトマネージャーと ISO/SAE 21434：車載製品は自動車メーカーの開発監査をどう通るか？
- プロダクトマネージャーと ISO 42001：AI 製品のガバナンス要求に顧客へどう応えるか？
- プロダクトマネージャーと TISAX プロトタイプ保護：ラベルがないと自動車メーカーの案件は止まるか？
- プロダクトマネージャーと ISO 27701・GDPR：各市場で販売する前にどの個人情報対応が必要か？