// シス担のミカタ
脆弱性管理

責任ある開示 せきにんあるかいじ

脆弱性セキュリティリサーチCVD（協調的脆弱性開示）バグバウンティゼロデイパッチ
責任ある開示について教えて

簡単に言うとこんな感じ！

セキュリティの穴（脆弱性）を見つけた人が、いきなりネットで公開するんじゃなく「まず作った会社に内緒で教えて、直してもらってから公表する」っていうルールのことだよ。悪用される前に修正できるから、みんなが安全になる「大人のお作法」なんだ！

責任ある開示とは

責任ある開示（Responsible Disclosure）とは、セキュリティ研究者やハッカーがソフトウェアやサービスの脆弱性（セキュリティ上の欠陥）を発見したとき、その情報をいきなり一般公開するのではなく、まずベンダー（開発・販売元）に非公開で報告し、修正パッチが提供されるまで公表を控えるという慣行・プロセスを指します。

発見者がただ黙っているのではなく、ベンダーに修正を促しつつ、一定の猶予期間（一般的には90日間が目安）を過ぎたら公表する、という「責任と期限」のセットで成り立っています。これにより、悪意ある第三者に脆弱性を悪用される前に修正が間に合う可能性が高まります。

近年は「責任ある開示」をさらに発展させたCVD（Coordinated Vulnerability Disclosure：協調的脆弱性開示）という概念も広まっており、研究者・ベンダー・PSIRT（製品セキュリティ対応チーム）・CERT/CCなどの第三者機関が協力して開示のタイミングや内容を調整するアプローチが主流になっています。

責任ある開示のプロセスと構造

開示の流れ

ステップ実施者内容
① 脆弱性発見研究者・セキュリティエンジニアソフトウェア・サービスの欠陥を発見
② 非公開報告研究者 → ベンダーベンダーのセキュリティ窓口（PSIRT等）に報告
③ 受領確認ベンダー報告を受け取った旨の応答（理想は48時間以内）
④ 修正開発ベンダーパッチ・アップデートを開発・テスト
⑤ パッチ公開ベンダー修正版をリリース、CVE番号（後述）を発行
⑥ 詳細公表研究者・ベンダー脆弱性の詳細と修正内容を協調して公表

猶予期間（ディスクロージャーデッドライン）の目安

機関・ポリシー猶予期間
Google Project Zero90日（修正済みなら即日公表も可）
CERT/CC（カーネギーメロン大学）45日
JPCERT/CC（日本）ベンダー調整次第（目安45〜90日）
ISO/IEC 29147組織が独自設定（合理的な期間）

覚え方：「見つけたら、まず耳打ち・直してから公表」

「脆弱性を見つけたら、1. 耳打ち（非公開報告）→ 2. 待つ（猶予期間）→ 3. 公表」の3ステップで覚えよう！

歴史と背景

  • 1993年頃〜：セキュリティ研究者の間で「フルディスクロージャー（Full Disclosure）」vs「秘密保持」の議論が激化。脆弱性をすぐ全公開する派と隠す派が対立
  • 2000年：Rain Forest Puppy（ハッカー名）がRFPolicy v2を公開。「ベンダーへの事前通知→一定期間後に公表」という実践的ガイドラインを提唱し「責任ある開示」の原型に
  • 2002年：MicrosoftがCISO Scott Charney主導でCoordinated Vulnerability Disclosure（CVD）の概念を推進し始める
  • 2010年代〜：GoogleのProject ZeroやFacebookなどが90日ルールを明文化し業界標準として定着
  • 2014年：ISO/IEC 29147（脆弱性開示）およびISO/IEC 30111（脆弱性ハンドリング）が制定され、国際規格として整備される
  • 2016年〜：HackerOneやBugcrowdなどのバグバウンティプラットフォームが普及し、企業が公式に報奨金を出して脆弱性報告を募る文化が拡大
  • 2022年：米CISA（サイバーセキュリティ・インフラセキュリティ庁）がCVDポリシーを連邦政府機関に義務化

関連する概念・アプローチとの比較

フルディスクロージャー・ゼロデイ公開との違い

開示アプローチの比較 責任ある開示 Responsible Disclosure ✅ ベンダーへ事前通知 ✅ 修正まで非公開維持 ✅ 猶予期間後に公表 ✅ 利用者を保護できる ⚠️ ベンダーが無視する 　 リスクあり 協調的脆弱性開示 CVD（推奨モデル） ✅ 研究者＋ベンダー協調 ✅ 第三者機関(CERT)調整 ✅ 公表タイミングを合意 ✅ ISO/IEC 29147準拠 ⚠️ 調整に時間がかかる 　 場合もある フルディスクロージャー Full Disclosure ❌ 即時・全情報公開 ❌ 修正前に悪用リスク大 ⚠️ ベンダーへの圧力にはなる ⚠️ 研究者の法的リスクも ※ ゼロデイ公開は 　 これに近い ← 利用者保護に配慮 ／ 即時公開 →

CVE番号とは？

脆弱性が公表されるとき、CVE（Common Vulnerabilities and Exposures）という共通識別番号が割り振られます。例：CVE-2021-44228（Log4Shell）のように CVE-年-連番 の形式で、世界中で同じ脆弱性を指す共通語として機能します。

CVE-2021-44228
 │    │     └── 連番（その年の脆弱性の番号）
 │    └──────── 発見・報告年
 └───────────── 識別子プレフィックス

バグバウンティとの関係

バグバウンティ（Bug Bounty）は、企業が「うちのシステムの脆弱性を責任ある方法で報告してくれたら報奨金を払います」と公式に宣言するプログラムです。責任ある開示の「報告→修正→公表」プロセスを仕組みとして制度化したものであり、両者はセットで考えられます。

関連する規格・RFC

規格・RFC番号内容
RFC 9116security.txt ファイルの標準化。Webサイトの脆弱性報告窓口を機械可読な形で公示する仕様
ISO/IEC 29147:2018脆弱性開示（Vulnerability Disclosure）の国際標準。開示プロセスの要件を定義
ISO/IEC 30111:2019脆弱性ハンドリングプロセスの国際標準。ベンダー側の対応手順を規定

関連用語

  • 脆弱性 — ソフトウェアやシステムに存在するセキュリティ上の欠陥・弱点
  • CVE — 脆弱性に割り振られる共通識別番号（Common Vulnerabilities and Exposures）
  • CVSS — 脆弱性の深刻度を数値化する共通スコアリングシステム
  • バグバウンティ — 脆弱性報告に報奨金を支払う公式プログラム
  • ゼロデイ脆弱性 — パッチ未公開の状態で悪用される脆弱性
  • PSIRT — ベンダー内の製品セキュリティインシデント対応チーム
  • JPCERT/CC — 日本のコンピュータ緊急対応チーム。脆弱性情報の調整機関
  • ペネトレーションテスト — 許可を得た上でシステムへの侵入を試みるセキュリティ検査