その通りです。しかしソクラテス、私はまず「このシステムが本当に影響を受けるのか」を確認する必要があります。ユーザー名・パスワードの入力値が適切に検証されているか、ログイン処理のソースコードを点検する必要があります。たとえば、phpの`mysql_error`関数が不適切に使われていませんか？

待つのはもちろんです。しかし、パッチが公開されるまでに、現状の設定が本当に安全かを確認する必要があります。たとえば、入力値に正規表現による制限が設けられているか、または「エラーメッセージが詳細すぎる」など、監視対象にすべき点があります。また、ベンダーが公式に情報公開していない場合、プロジェクトのリポジトリを確認する必要があります。

まず、システムが本当に該当するかを「公式情報やソースコード確認」で判断します。次に、変更管理の文書にこの脆弱性を記録し、パッチ適用の際には「影響範囲の再評価」を必ず行います。監視ツールで異常なSQLクエリが発生していないかを定期的にチェックするのも重要です。

現状では、パッチがないため「攻撃が実際に発生しているかどうかは不明」ですが、リスクをゼロと見なすのは危険です。少なくとも、ログイン処理のセキュリティ対策が適切かを点検し、今後の対応策を準備しておく必要があります。ベンダーが応対していない場合でも、自社の変更管理プロセスで対応を推進するべきです。

運用者は「確認→分析→準備」の三段階を踏まえるべきです。確認は公式情報とコード点検、分析は現状の入力検証と監視、準備はパッチ適用と変更管理の文書化です。そして、ベンダーに情報提供を求める姿勢も忘れてはなりません。ややこしいですが、これが「現実的なセキュリティ対応」でしょう。