それは、まず「存在しない」可能性があるからではないか。もしファイルが存在しないなら、問題は発生しない。しかし、存在する場合、アクセス権が適切かを確認する必要がある。たとえば、/opils/staff/product.phpがWebサーバーのDocumentRootに配置されており、外部からアクセス可能かどうか。これは、まるで「鍵をかけたドアが開いているか」を確認するようなものです。

パッチは「鍵をかける」ための手段です。しかし、公式サイトから提供されているものを適用する前に、そのパッチが本当に該当ファイルに適用可能かを確認しなければなりません。たとえば、パッチが「/opils/staff/」ディレクトリの構造に依存している場合、誤って適用すると逆に脆弱性を悪化させる可能性もあります。

これは「鍵をかけたドアに、鍵をかける仕組み」を再確認する行為です。たとえば、Categoryパラメータが「数字だけ」を許容するように変更するなど、エスケープ処理が適切かをコードレベルで確認する必要があります。これは、哲学ではなく、実際の運用です。

監視は「鍵が本当に効いているか」をチェックするためです。たとえば、WebログにSQLインジェクションの試行が記録されているかを定期的に確認しましょう。ベンダー情報確認は、公式サイトが「正しい鍵屋さん」であるかを確認するためです。非公式なサイトからパッチをダウンロードするリスクを避けるためです。

いや、これは「公開されたエクスプロイト」のため、ネットワークの向こうで誰かが「ドアの鍵を試している」かもしれません。我々は、少なくとも「鍵をかけているか」を確認する義務があります。それが、我々の責任です。