おっしゃる通りです。しかし、まずは現実に目を向ける必要があります。この脆弱性が発生したのは、特定のPHPファイルが存在し、IDパラメータの入力検証が不完全だったからです。まずは、そのファイルが自社のシステムに存在するか、確認すべきではありませんか？たとえば、/manage_tenant.phpというファイル名は、まるで「借りた部屋の管理」に特化したシステムの一部のように思えますが、それが本当にあなたのサーバーにあるのか、確認してみましょう。

これは哲学の領域ではなく、具体的な確認作業です。IDパラメータが正規の形式で入力されているか、たとえば数字だけが許容されているか、文字列がエスケープされているか、これらをチェックする必要があります。また、パッチが提供されている場合、その適用は「変更管理」のプロセスに沿って行うべきです。たとえ緊急性が高くとも、変更履歴を記録し、テスト環境で動作を確認する手順を飛ばしてはなりません。

これは「監視」の重要性を教えてくれます。NVDやベンダーの公式サイトで情報を確認し、パッチの有無を確認する習慣が必要です。また、この脆弱性がPHPベースのアプリケーションに影響を与えるなら、他の同様なシステムにも同様の問題がないか、横断的な影響調査を実施すべきです。たとえば、「他のファイルにもIDパラメータが存在するか」を確認するのも、現実的な作業です。

確かに、倫理と技術は切り離せません。しかし、現実的には、ベンダーからの情報確認とパッチ適用が最優先です。また、この脆弱性のCVSSスコアが7.3という数値は、私たちが「早急に対応すべき」という判断を促すものです。ただ、その判断は、冷静な分析と、現場の現実を踏まえた行動にこそ意味があります。たとえば、ファイルの存在確認から始めて、段階的に対応を進めるのです。

はい。ただし、そのバランスを取るためには、まず「ファイルが存在するか」を確認するという、シンプルなステップから始めるべきです。そのファイルが本当にあなたのサーバーにあるのか、確認してください。それから、哲学の時間はまた後で。