不具合と脆弱性の違い
画面が崩れる不具合が全てセキュリティ問題とは限りません。一方、通常表示が正常でも、権限確認の欠落や危険な入力処理が残る場合があります。脆弱性の存在と、実際に侵害されたことも別です。更新で弱点を塞いでも、既に侵入されていた痕跡が消えるわけではありません。
情報を照合する手順
- 配布元・正式名・slug・現在版を記録する。
- 製品提供者の告知と脆弱性DBを確認する。
- 影響範囲、修正版、攻撃に必要な条件を読む。
- 自社の公開機能や権限で条件が成立するか確認する。
- 対応方針、担当、期限、判断の根拠を記録する。
似た名前の別製品や、版の範囲の読み違いに注意します。診断ツールが推定したバージョンは、管理画面やファイルで確認し直します。
深刻度の点数だけで優先順位を決めない
CVSSは技術的な深刻度を伝える指標です。自社への影響は、認証なしで攻撃できるか、該当機能を公開しているか、悪用が確認されているか、扱うデータが何かと合わせて判断します。点数が低めでも自社では重大になることがあります。
修正版がある場合とない場合
修正版があれば、バックアップと互換性確認を行い、緊急性に応じて反映します。修正がなければ機能停止、公開制限、削除、代替製品への移行を検討します。WAFなどの代替措置は、該当経路を防げるか確認し、恒久対応の期限を残します。
更新後に確認すること
現在版が修正版であることと、主要機能が正常なことを確認します。既に悪用の兆候があれば、ログ・変更ファイル・ユーザーの調査が必要です。脆弱性対応は「更新済み」の一言で終わらせず、該当性、対処、再確認を一つの記録として残します。
よくある脆弱性と影響の読み方
入力されたデータが安全に扱われない場合、不正なスクリプトの保存やDB操作につながることがあります。また、利用者の権限確認が足りなければ、想定外のデータ閲覧や設定変更につながります。記事内の一般的な名称だけで自社の該当性を判断せず、対象製品・版・機能・権限の条件を読みます。例えば「投稿者以上の権限が必要」という条件では、登録可能な利用者にどの権限を与えているかを確認します。自社の管理者しか操作しないから無関係と即断せず、不正取得された低権限アカウントから影響が広がらないかも考えます。
対応結果の記録例
「情報URL、現在版、影響範囲、公開機能、対応策、実施日時、確認結果」を一行にまとめます。非該当なら理由、更新待ちなら代替措置と期限を残します。新しい情報で影響範囲が修正される場合に備え、情報源と確認日も記録します。
無効化したプラグインも確認しますか？
はい。無効化してもファイルが残り、製品固有の経路が存在する可能性があります。停止していることだけで非該当にせず、告知の条件を確認します。
脆弱性が見つかったら侵害済みですか？
必ずしもそうではありません。脆弱性の存在、攻撃の試行、攻撃の成功を分けて調べます。侵害の兆候があるなら、通常の更新に加えて証拠保全と影響調査が必要です。