セキュリティポリシーのページは開示プロセスではない

本気で取り組むプロジェクトには必ずセキュリティページがあり、ページそのものは安い。役に立つ問いは、文書化された経路で送った報告が、一般の利用者が導入できる修正版につながるかどうかである。それには一つの主張ではなく四つの証拠が要り、どれも何かを探ったりせず外から確認できる。どれも他人のサーバーに対する試験を必要としない。すべてメモ一枚に収まる。

経路を見つけ、それが存在するか確かめる

文書化された経路、つまりセキュリティポリシーのページ、専用の連絡先、あるいは /.well-known/security.txt というファイルで、その Contact フィールドが RFC 9116 で定められているものから始める。

次に、親しみやすい前置きではなく範囲の段落を読む。どの製品が対象で、どのバージョンで、プロジェクトはどんな扱いを求めているのか。

別のプロジェクトに属する経路や、維持管理者ではなくホスティング事業者に属する経路は、評価しているソフトウェアの開示プロセスではない。

公開トラッカーか非公開の経路か

通常の不具合は公開トラッカーに置くべきで、そこから利益を得る。悪用可能な詳細を含む報告はそうではなく、公開の場に出すと、維持管理者がまだ読んでいる間に利用者を危険にさらす。

公開トラッカーだけを提供するプロジェクトは、文書に何と書かれていても、開示の経路を用意していない。

これはどれも、所有していないシステムを試すことを認めない。報告先は情報を送るための招待であり、無関係な公開サーバーを探る許可ではない。

一つの修正を最初から最後まで追う

過去の告知を選び、影響を受けたバージョンとそれを修正するリリースを挙げているか、利用者がそのリリースを実際に導入できるかを追跡する。

その足跡が、確認と修理の違いである。リリースを一度も出さない丁寧な返信は広報の成果にすぎない。バージョン番号とダウンロードリンクを添えた簡潔な告知は機能するプロセスである。良い告知は、何が影響を受けたか、影響は何か、どのバージョンが修正するか、どこで入手するかという四つのことに素早く答える。

リリース履歴が残りを埋める。明確な記録を伴う定期的なリリースは、修正を出荷できるプロジェクトを示しており、それは雄弁なポリシーより重要である。

クライアントの維持管理者かサービスの運営者か

VPN の場合、クライアントを書く人とゲートウェイを運用する人は、しばしば別の組織である。クライアントのコードの問題とサーバーの配備の誤りでは、連絡すべき相手が違う。

誤った相手に回すと通常は返送ではなく沈黙で終わるため、送る前に自分の発見がどちらに関わるかを決める。

不在が証明すること、しないこと

告知一覧が空であることは、製品に不具合がない証拠にはならない。若いプロジェクト、小さい表面、あるいは誰も見ていないことを意味しうる。

同様に、ポリシーのページがないことは悪意の証拠ではない。プロセスを確認できないという証拠であり、それが記録すべき正直な結論である。

何を書き残すか

確認できる連絡先、自分のバージョンを覆う範囲、修正版を示す告知、修正が出荷されることを示すリリース履歴という四つの事実を記録する。

そのうえで、不明なままのことを書き留める。そう書くレビューのほうが、欠けたポリシーを安全だという主張に変えるレビューより役に立つ。