要約

  • RFC 9116 は脆弱性報告先の発見方法と情報の失効時点を標準化するが、メールの到達、案件番号の発行、担当者による引き受けまでは証明しない。
  • 開示経路の受領記録には、取得したファイルと期限、安全なテスト通知、配送結果、受領確認、キューの責任者、エスカレーション目標、再試験の条件を結び付ける必要がある。

分析

ある組織では、資産管理システムが /.well-known/security.txt を毎週確認している。HTTPS、文字コード、Contact、Expires はすべて正常で、期限も十分先だ。ところがメール基盤の移行時に、外部からの投稿を許可する設定だけが引き継がれなかった。内部の試験メールは届くため、障害は実際の研究者が送信するまで見つからなかった。

これは標準の欠陥ではない。文書の検証結果を、サービス全体の検証結果として扱ったことが問題だ。

RFC 9116 は、脆弱性を伝えたい研究者が窓口を推測する負担を減らす。正しいファイルには一つ以上の Contact と、ちょうど一つの Expires が必要だ。ウェブサービスでは /.well-known/security.txt に置き、HTTPS 経由で UTF-8 のプレーンテキストとして提供する。IANA の Well-Known URI レジストリでも security.txt は恒久的な項目として登録され、変更管理者は IETF である。つまり、発見と解釈の共通面ができる。

期限にも明確な役割がある。Expires を過ぎた情報は古いものとして扱い、RFC は一年未満の将来を推奨する。連絡先や参照先が更新されなければ、報告が組織に届かず、別の相手へ渡る危険があるとも警告している。公開者に定期的な見直しを促す点は重要だ。

しかし、期限は公開者が付けた文書上の時刻である。メールゲートウェイの配送証跡でも、フォームの保存結果でも、担当者が案件を引き受けた記録でもない。ファイルを書き換える権限を持つ人が、後段の運用を確認したとは限らない。

発見から保管までの境界

まず二つの時計を分ける。公開時計は、ファイルの作成、確認、失効を記録する。サービス時計は、通知の受け付け、確認、初期評価、担当付与、エスカレーション、結果連絡を記録する。前者を更新しても後者は進まない。

経路には複数の境界がある。最初は適用範囲だ。RFC 9116 では、ファイルは原則として取得元のドメインまたは IP アドレスに適用され、親やサブドメインへ自動的に広がらない。ポリシーが製品群を追加で扱う場合も、その関係を明記しなければならない。

次は配送である。構文上正しいメール URI でも、外部送信者を拒否することがある。フォームが表示できても、送信時にエラーになることがある。外部プラットフォームに案件が保存されても、顧客側の通知先が古い場合がある。ファイル取得の成功から、これらは観測できない。

暗号化も別の境界だ。Encryption は鍵そのものではなく、その取得場所や指紋を示す。RFC は鍵の真正性を研究者自身が確認するよう求めている。公開鍵が取得できても、受信チームが現在の秘密鍵を扱えることや、当番交代時に復号手順が移管されたことまでは分からない。

受領確認は、配送を組織の保管へ変える境界である。追跡可能な案件番号や返信時刻があれば、通知と後続処理を対応付けられる。自動返信だけの場合、それが監視中のキューと結び付いているかを確かめる必要がある。

最後は処理の権限だ。初期評価、範囲外通知の転送、修正担当との調整、結果の連絡を誰が行うのか。CISA の拘束的運用指令 20-01 は、対象となる米国連邦文民機関について、この後段を具体化している。報告を解決まで追跡し、修正を内部調整し、影響を評価し、範囲外を処理し、報告者と連絡する手順を求め、受領確認、初期評価、解決の目標時間も要求する。これは RFC 9116 の要件でも世界共通の法でもない。公開窓口と運用能力が別の統制であることを示す一次資料だ。

安全な合成テスト

受領記録は、まず公開面を固定する。正規の取得 URI、ファイルの指紋、取得時刻、表示された期限、対象となるホストやサービス、優先順に選んだ連絡先を記す。フォームなら版、暗号鍵なら観測した指紋も残す。

次に、受信チームが事前承認した合成テストを一件送る。実在の脆弱性、攻撃コード、秘密情報、個人情報は含めない。件名と本文で経路確認であることを明示し、閉じ方も説明する。送信時刻、配送の受諾または拒否、受領確認の時刻、案件番号、キューの担当と代行者、初動とエスカレーションの目標を別々に記録する。

成功を広げて解釈してはいけない。SMTP の受諾は一つの中継点までの事実にすぎない。フォームの完了画面は案件の永続保存を保証しない。自動返信は人による確認ではない。試していないエスカレーションは「未試験」とする。

試験そのものが負担にならない設計も要る。メールや DNS の移行、フォーム更新、ID 基盤変更、鍵のローテーション、委託先交代、担当変更、ポリシー改定、新ドメイン追加を契機に再実施する。通常時は公開期限より短い控えめな周期でよい。テスト識別子を事前共有し、実際の重大報告と競合させない。

狭い結論ほど実務に役立つ

受領記録は security.txt を置き換えない。ファイルは公開発見面として残り、Canonical、Policy、Preferred-Languages、Encryption はそれぞれ異なる曖昧さを減らす。電子署名は文書の出所と完全性を強められる。

記録が答えるのは、宣言された経路が最後にいつ組織の保管まで到達したかだけだ。「ファイル有効、メール受諾、確認なし」「フォーム保存、案件番号あり、代行者未確認」といった部分状態を残せる。この方が、一つの合否より修理箇所が明確になる。

ダッシュボードには、取得日、期限、テスト配送結果、確認までの時間、担当確認、未試験の項目を一行で示せる。リンク先に証拠と観測時刻があれば短くてもよい。それは将来の報告が正しいこと、優先順位が妥当であること、修正が期限内に終わることを保証しない。

情報源

  1. RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
  2. IANA Well-Known URIs レジストリ
  3. CISA 拘束的運用指令 20-01