脆弱性報告を受け付けない企業は危うい? CISAら5機関が共同指針:善意の研究者を訴えるな
「脆弱性を見つけても報告先がない」「修正されたのかも分からない」。そんな状況を変えるため、CISAやNSA、JPCERT/CCなど5機関が、企業向けの共同指針を公開した。善意の研究者との協力を前提とした新たな脆弱性管理の実務とは何か。
米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)は2026年7月15日(現地時間)、米国家安全保障局(NSA)やJPCERT/CC、オランダ国家サイバーセキュリティセンター(NCSC-NL)、英国国家サイバーセキュリティセンター(NCSC-UK)と共同で、協調的脆弱(ぜいじゃく)性開示(CVD)プログラムの構築・運用指針を公表した。
CVDとは、第三者がシステムやソフトウェアの脆弱性を発見したとき、情報を直ちに公開せず、まずは製品開発者や管理者に通知して修正期間を設けるプロセスだ。
今回の運用指針では、ソフトウェアメーカーやオンラインサービス提供者に対し、脆弱性を安全に報告できる脆弱性開示方針(VDP)の整備をはじめ、報告の受理・評価から修正、CVE番号の取得・付与、公表までの一連の手順を明確化するよう求めている。必要に応じて各国の事故対応組織など第三者の仲介機関を活用することも推奨した。
脆弱性を黙って直すな CISAら5機関が「サイレント修正」を避けるよう提言
多くの製品で開発段階のテストだけでは全ての脆弱性を見つけることは難しく、外部のセキュリティ研究者と連携することが製品の安全性向上につながる。適切なVDPを整備することで、研究者は報告方法や対象範囲を把握でき、企業側も報告の受付や修正、公表を円滑に進められる。
さらに、商用製品や一般公開されたオープンソースソフトウェア(OSS)については公開CVEを前提とした運用を推奨する一方、政府専用ソフトウェアについては非公開の手続きを採用するよう勧めている。ではCVD構築の第一歩とは何だろうか。
CVD構築の第一歩は、明確なVDPをWebサイトで公開することだ。今回の方針では、調査対象のシステムや許可するテスト内容、報告時に必要な情報、企業と研究者それぞれの役割、公表までの流れを記載するよう求めた。また、米国政府の運用指令「BOD 20-01」や欧州連合(EU)の「サイバーレジリエンス法(CRA)」が、対象組織にこうした方針の策定・維持を義務付けていることも紹介している。
参加資格は国籍や年齢などで不必要に制限せず、現実的な攻撃を再現できる範囲でテストを認めるべきだとした。一方で、検証に必要な範囲を超える悪用は認めず、マルウェアの投入やデータの改変・削除、総当たり攻撃、DoS攻撃など、機密性・完全性・可用性(CIA)を損なう行為は明示的に禁止するよう求めた。
報告窓口については、電子メールや専用Webフォーム、第三者機関を利用した安全な受付手段を用意するとともに、Webサイトに脆弱性報告先を示す「security.txt」を公開するよう推奨した。報告内容には脆弱性の概要やPoC(概念実証)の他、再現手順や影響評価などを含めることが望ましいとし、匿名での報告にも対応するよう求めている。
また、善意で脆弱性を調査した研究者を訴訟や法的責任から保護する「セーフハーバー」条項の整備も重要な要素として挙げた。企業は法務部門と連携し、VDPの範囲内で実施された調査については法的措置を取らない方針を明確化すべきだとした。その一方で、秘密保持契約(NDA)の一律要求や、利用者に知らせず脆弱性だけを修正する「サイレント修正」は避けるよう求めている。
報告窓口からCVE公開まで CISAらが示した脆弱性対応の実務
指針では、報告を受け付けてから修正、公表までの運用についても具体的な目安を示した。専用窓口は報告受理後2〜3営業日以内を目安に研究者に連絡し、一般の顧客サポート窓口とは分離して運用することを推奨している。
担当者は製品や利用者への影響を評価し、脆弱性の優先順位付け手法「SSVC」(Stakeholder-Specific Vulnerability Categorization)などを活用して対応優先度を決定する。危険度によっては新機能開発よりも修正を優先し、顧客が既存の緩和策を適切に実施していることを前提に判断してはならないとした。研究者には定期的に進捗(しんちょく)を共有し、透明性を確保することも求めている。
修正が必要と判断した場合は、パッチや設定変更、追加の緩和策を提供し、可能であれば研究者にも事前確認を依頼する。通常のリリースサイクルを待つのではなく、VDPで定めた期間内に情報を公開するとともに、同種の脆弱性が他の箇所にも存在しないか調査するよう推奨した。
CVEについては、脆弱性の発見経路を問わず、製品に影響する脆弱性にはCVE番号を付与または取得することを推奨している。ベンダー自身がCVE採番機関(CNA)でない場合は、CNAへの認定取得や既存のCNAを通じた採番を検討するよう求めた。CVE記録には根本原因を示すCWEや、技術的影響と悪用可能性を表すCVSSベクトルなど、正確な情報を記載し、確認と緩和が完了した後は不要に公開を遅らせないことが重要だとしている。
顧客向けのセキュリティアドバイザリーには、脆弱性の内容や影響を受ける製品・バージョンや根本原因、危険度、悪用状況、侵害の兆候、修正方法、緩和策、CVE番号、許可を得た場合の研究者名などを含めるよう求めた。アドバイザリーはログイン不要で閲覧できる場所に公開し、機械処理可能な「CSAF」の活用も推奨している。公開時期は研究者や仲介機関と調整して決定する。
運用開始後は、机上演習や外部から寄せられた報告件数・品質、社内の応答時間、開発部門への連携状況、重大案件発生時の経営層へのエスカレーションなどを定期的に見直すことが重要だとした。研究者からの改善提案や謝辞の公開、バグ報奨金制度の導入も、CVDの成熟度を高める取り組みとして紹介している。
人員や専門知識が不足する組織については、CISAなどの第三者調整機関や各国のCSIRTがCVD運用を代行・補完できると説明した。これらの組織は、報告窓口の運営や脆弱性評価、権限内でのCVE採番、複数のベンダーにまたがる案件の調整などを担う。CISAの開示基盤も、関係者間の安全な情報共有や修正作業、脆弱性情報の同時公開を支援する仕組みとして位置付けられている。
同指針は、CVDを自社で運用するまたは第三者機関を利用する場合でも、重要なのは研究者が安心して脆弱性を報告できる窓口を用意することだと強調する。こうした仕組みを整備しなければ、脆弱性の見逃しだけでなく、顧客の安全やセキュリティコミュニティーからの信頼を損なう恐れがあるとして、企業に透明性の高い脆弱性管理体制の構築を求めている。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
ニチレイ、不正アクセスによるシステム障害を公表 一部業務に影響
ニチレイは、不正アクセスでシステム障害が発生したと公表した。個人情報や顧客データ流出は未確認で調査継続中だ。国内のグループ会社の一部業務に影響が生じたとされている。
悪用成功率99%、Linuxカーネルに新ゼロデイ「Bad Epoll」が見つかる
成功率は約99%。Linuxカーネルで見つかった新たな権限昇格の脆弱性は、極めて短い競合タイミングにもかかわらず、高い確率でroot権限を奪えることが実証された。さらに、この脆弱性はAndroidにも影響する可能性があるという。
PHP利用者は見逃し厳禁 TLS通信でサービス停止を招くHigh脆弱性を修正
PHPに高危険度の脆弱性が見つかり、修正版が公開された。問題はTLS接続時のエラー処理にあり、特定の環境ではHTTPS通信の失敗をきっかけにサービス停止に発展する恐れがあるという。
Linuxカーネルに15年潜伏した脆弱性が見つかる 攻撃成功率は97%
Linuxカーネルで2011年から存在していた脆弱性が明らかになった。特別な権限を必要とせず、一般ユーザー権限から権限昇格やコンテナ脱出につながる可能性があるという。GoogleのkernelCTFでも高く評価された攻撃は、どのような仕組みで成立するのか。
KDDIの最大1422万件の情報漏えい事件 その裏には陸自USB問題と同様に中国の影?
KDDIで発生した最大1422万件に及ぶ情報漏えい。その背後には、単なる脆弱性悪用では片付けられない攻撃者の狙いが見え隠れしている。ダークWebやOSINT(公開情報調査)から事件を追跡し、流出データの行方や政府系サイバー攻撃との接点、今後想定されるリスクを専門家とともに解説する。