Divulgación responsable - Reportar vulnerabilidades éticamente
Lectura de 2 min aprox.
責任ある開示 (Responsible Disclosure) とは、ソフトウェアやサービスの脆弱性を 発見した際に、まずベンダーに非公開で通知し、修正パッチが提供された後に 情報を公開するプロセスです。発見者とベンダーが協調して脆弱性に対処する この枠組みは、ユーザーを攻撃から守りつつ、セキュリティ研究の透明性も 確保するバランスの取れたアプローチとして、現在のセキュリティコミュニティで 広く受け入れられています。
フルディスクロージャーとの違い
脆弱性の公開方針には大きく 3 つの立場があり、それぞれ異なる哲学に 基づいています。
| 方針 | 概要 | 利点 | リスク |
|---|---|---|---|
| 責任ある開示 | ベンダーに先に通知し、修正後に公開 | ユーザーが保護された状態で情報公開 | ベンダーが対応を遅延させる可能性 |
| フルディスクロージャー | 発見後すぐに全情報を公開 | ベンダーに迅速な対応を強制 | パッチ前に攻撃者が悪用可能 |
| 非開示 | ベンダーにのみ通知し、公開しない | 攻撃者に情報が渡らない | ベンダーの対応を検証できない |
2000 年代初頭のフルディスクロージャー運動は、ベンダーが脆弱性報告を 無視する問題への反発から生まれました。しかし、パッチ未提供の状態で 攻撃コードが公開されるリスクが大きく、現在は責任ある開示が主流です。 Microsoft は 2010 年に「Coordinated Vulnerability Disclosure (CVD)」 という名称を提唱し、発見者とベンダーの協調を強調しています。
典型的なタイムラインと 90 日ルール
脆弱性発見
ベンダーに通知
修正開発・検証
パッチ公開
脆弱性情報公開
Google Project Zero が 2014 年に設定した「90 日ルール」は、業界標準の 開示期限として定着しました。ベンダーへの通知から 90 日が経過した時点で、 パッチの有無にかかわらず脆弱性情報を公開するというポリシーです。 この期限があることで、ベンダーが対応を先延ばしにするインセンティブが 抑制されます。実際に Google Project Zero は、Microsoft や Apple の 脆弱性を期限到来後に公開した事例があり、大手ベンダーのパッチ管理体制の 改善を促してきました。
バグバウンティとの関係
バグバウンティプログラムは、 責任ある開示を経済的に動機づける仕組みです。発見者がベンダーに脆弱性を 報告すると、深刻度に応じた報奨金が支払われます。HackerOne や Bugcrowd といったプラットフォームが仲介役を果たし、報告のテンプレート化、CVE 番号の取得支援、 法的保護の枠組みを提供しています。オープンソースのセキュリティ監査でも、 バグバウンティと責任ある開示の連携が重要なテーマです。
法的リスクとセーフハーバー
脆弱性の発見・報告には法的リスクが伴います。善意の研究者であっても、 不正アクセス禁止法 (日本)、CFAA (米国)、Computer Misuse Act (英国) などに抵触する可能性があるためです。この問題を緩和するため、多くの 企業がセキュリティポリシーに「セーフハーバー条項」を設けています。 セーフハーバー条項は、ポリシーに従って脆弱性を報告した研究者に対して 法的措置を取らないことを明示するものです。
米国では 2022 年に司法省が CFAA の運用方針を改定し、善意のセキュリティ 研究を起訴対象から除外する方針を示しました。EU の NIS2 指令も 協調的な脆弱性開示の枠組みを加盟国に求めています。しかし、日本では セーフハーバーの法制化が進んでおらず、IPA (情報処理推進機構) の 脆弱性届出制度が事実上の受け皿となっています。スタートアップのセキュリティチェックリストでは、 開示ポリシーの策定手順も紹介しています。
よくある誤解
「脆弱性を見つけたらすぐに SNS で公開すべき」という考えは危険です。 パッチが存在しない状態での公開は、攻撃者に悪用の機会を与えます。 また、ペネトレーションテストの 許可なく他者のシステムを調査する行為自体が違法となる場合があります。サプライチェーン攻撃の記事で 触れているように、脆弱性情報の取り扱いは攻撃の連鎖を防ぐ上でも重要です。
セキュリティの関連書籍は Amazonでも探せます。
¿Te resultó útil este artículo?