CTO の ISO/IEC 29147・30111 導入：脆弱性対応プロセスをどう作るか

CTO が作る脆弱性プロセスで、29147 と 30111 はそれぞれどの部分を扱うか？

二つの規格は互いに参照し合い、プロセスも連動しているため、別々に導入すると引き継ぎ部分に監査上の穴が残ります。対で整えることを勧めます。現行の有効版は ISO/IEC 29147:2018 と ISO/IEC 30111:2019 で、改訂は ISO/IEC JTC 1/SC 27 で作業項目として登録されていますが、新版はまだ発行されていません。

EU CRA は研究開発の脆弱性対応にどんな必須要件と期限を課すか？

CRA 附属書 I 第 2 部は製造者に次のことを求めています。

• 一般的で機械可読な形式で、少なくとも最上位の依存関係を含む SBOM を作成する（第 (1) 号）。
• 脆弱性に「遅滞なく」対応して修正し、技術的に可能な場合はセキュリティアップデートを機能アップデートと分けて提供する（第 (2) 号）。
• 協調的脆弱性開示（CVD）ポリシーを整備・運用し（第 (5) 号）、脆弱性報告の連絡先を提供する（第 (6) 号）。
• セキュリティアップデートが利用可能になれば「遅滞なく」配布し、カスタム製品で別段の合意がある場合を除き無償で提供する（第 (8) 号）。

第 14 条の報告：積極的に悪用された脆弱性を認識したら、ENISA の単一報告プラットフォームを通じて、調整役に指定された CSIRT と ENISA に同時に、24 時間以内に早期警告、72 時間以内に通知、是正または緩和措置が利用可能になってから 14 日以内に最終報告を行います。2026 年 9 月 11 日から適用され、2027 年 12 月 11 日より前に上市した製品も対象です。

脆弱性報告を受けた後、研究開発の社内処理ゲートをどう設計するか？

中心は「誰が受け付け、誰が検証し、誰が評価し、誰が修正し、誰が公開し、どれだけ速く行うか」を、監査可能なプロセスと期限として書くことです。

評価基準は製品の状況に合わせて調整できます（例：CVSS のローカライズ基準）。複数の製品ラインを持つメーカーは、脆弱性の影響範囲を横断的に評価する仕組みも必要です。

SBOM、定期的なテスト、セキュリティアップデートの配布を 29147 と 30111 が扱わない場合はどうするか？

EU 共同研究センター（JRC）と ENISA による 2024 年の対応付け分析では：

• 30111 は附属書 I 第 2 部の第 2・4・5・6・8 号に対応します。
• 29147 は第 2・4・5・6 号に対応します。
• SBOM（第 1 号）、定期的なテストとレビュー（第 3 号）、アップデートの安全な配布（第 7 号） はどちらの規格にも対応しておらず、ほかの規格や手順で補う必要があります。

この報告書は分析文書であって整合規格ではなく、適合推定は生じません。また、すべての側面を一つの規格で網羅できるものはないと指摘しています。CTO はツールチェーンとリリースプロセスに三つを加える必要があります。製品バージョンごとの SBOM、定期的なセキュリティテスト、セキュリティアップデートの配布の仕組みです。30111 の修正プロセスは、SBOM（製品に何が入っているかを知って初めて、どの部品の脆弱性が自社に関係するかがわかる）と、セキュリティアップデートの提供の仕組み（直したものを利用者に届ける）につながっていなければなりません。

旧バージョン、生産終了機種、上市済み製品も、サポート期間中は脆弱性に対応すべきか？

はい。CRA は製造者に対し、上市時からサポート期間全体を通じて、附属書 I 第 2 部に沿って脆弱性に有効に対応することを求めています（第 13 条第 8 項）。

• サポート期間：少なくとも 5 年（製品の想定使用期間がそれより短い場合はその期間）で、終了日（少なくとも年と月）を購入時に明確に表示します（第 13 条第 19 項）。
• セキュリティアップデートの保持：サポート期間中に出した各セキュリティアップデートは、少なくとも 10 年間またはサポート期間の終了までのいずれか長い期間、利用可能にしておきます（第 13 条第 9 項）。
• 上市済み製品：第 14 条の報告義務は、2027 年 12 月 11 日より前に上市した製品にも及びます（第 69 条第 3 項）。

CTO にとっては、旧バージョンの修正と試験に明確な担当者を置き、バージョンのブランチとビルド環境をサポート期間中に再現できるようにしておく必要があるということです。

エンジニアの人員：小さな会社に PSIRT は必要か？既存のインシデント対応手順で足りるか？

大きな組織は不要ですが、明確な受付窓口、責任者、回答プロセスは必要です。29147 の最低限の要求は規模の柔軟性を前提にしており、体制は簡素でよいものの、欠かすことはできません。

既存のセキュリティインシデント対応手順は良い土台ですが、脆弱性対応ではありません。インシデント対応（ISO/IEC 27035）は「既に起きた攻撃」を、脆弱性対応（30111）は「報告された弱点」を扱い、きっかけ、期限、成果物が異なります。CRA の監査で見られるのは脆弱性専用のプロセスと証拠です。30111 のプロセスは既存のインシデント対応（27035）とサプライヤー管理（27036）につなげます。ISO 27001 を持つ組織は、CVD のプロセスを既存の ISMS に組み込み、文書と監査の仕組みを共用できます。

積穗科研は CTO の ISO/IEC 29147・30111 対応をどう支援するか？

副社長・取締役クラスのコンサルタントが最初から最後まで自ら担当し、外注しません。29147 と 30111 は対で導入します。サービスページ記載の成果物：

• 29147（開示側）：security.txt と報告用メールアドレスまたはフォーム、報告の受付と回答の期限、セーフハーバー声明を含む協調的脆弱性開示ポリシー、アドバイザリーのひな形と公表手順、必要に応じた CVE 番号の申請手順。
• 30111（対応側）：脆弱性対応の方針とプロセス文書、評価基準、対応記録と期限の報告の仕組み、SBOM との連携手順、29147 の開示側とのインターフェース文書。すべてノーティファイドボディと顧客が監査できる水準で作ります。
• 実践経験：積穗科研自身の提供パイプラインは毎日 SBOM を生成・署名・監視しており、この仕組みが支援内容の生きた教材です。

サービスページに導入月数の記載はありません。

詳しく：ISO/IEC 29147 脆弱性開示導入支援、ISO/IEC 30111 脆弱性対応プロセス導入支援、29147 コンサルタントの選び方、CTO が研究開発プロセスに組み込む要求。無料のメカニズム診断を申し込む