先週、あるクライアントから緊急連絡が入った。「使っているプラグインに重大な脆弱性が見つかったらしいんですけど、どう対応すればいいですか？」というものだった。
CVEを確認すると、CVSSスコアが9.8。認証なしでリモートから任意コード実行が可能という、かなり深刻なやつだった。
その日の夕方から対応を始めて、最終的に影響調査・検証・本番適用・確認まで完了したのが翌日の昼過ぎだった。所要時間は約14時間。「WordPressは無料で使える」という言葉の裏に、これだけのコストが潜んでいることを改めて痛感した出来事だった。
今回はその経験をベースに、CVE対応にかかる実際のコストを数字で整理しておきたい。
CVE公表からクローズまでのリードタイム
実際に計測した結果から、CVE対応の工程を分解するとこんな感じになる。
| フェーズ | 所要時間（目安） | 内容 |
|---|---|---|
| 影響調査 | 1〜2時間 | CVE内容確認・影響プラグイン特定・サイト一覧洗い出し |
| 検証環境テスト | 2〜4時間 | ステージング環境でアップデート適用・動作確認 |
| 本番適用 | 30分〜1時間 | バックアップ→アップデート→動作確認 |
| 検収 | 1〜2時間 | 想定外の影響がないか全体動作確認・クライアント報告 |
| 合計 | 4.5〜9時間 | 1サイト・1プラグインのケース |
「4.5〜9時間」というのは、1サイト・1プラグイン・1件のCVE に対する数字だ。
これが複数サイトを管理している場合、対応件数は単純に掛け算になる。5サイトを管理していて全サイトに影響するCVEが出た場合、合計対応工数は22.5〜45時間になる計算だ。
「無料CMS」の隠れコスト
エンジニアの時間単価を6,000円/時間で計算してみる（社内稼働コスト込みの一般的な目安）。
上記の1件・1サイト対応でいうと：
4.5時間 × 6,000円 = 27,000円（最短ケース）
9時間 × 6,000円 = 54,000円（標準ケース）WordPressそのものは無料だが、CVE対応コストは1件あたり3〜5万円程度 かかることになる。
問題は、これが年に何件あるか、だ。
WPScanの公開データを見ると、WordPressプラグインのCVEは年間1,000件を超えるペースで報告されている。もちろん全部が自分のサイトに影響するわけではないが、プラグインを20個使っているサイトでは年に5〜10件程度は「対応が必要なCVE」に直面する肌感がある。
5件 × 40,000円 = 年間200,000円
10件 × 40,000円 = 年間400,000円これがランニングコストとして乗ってくる。有償CMSのライセンス費用と比較したとき、「WordPressのほうが安い」とは必ずしも言えないと考えている。
プラグイン数とCVEリスクの相関
構成によってリスクの大きさはかなり変わる。
運用を考えると、プラグイン数がそのままCVE被弾確率に影響するのは感覚的にも分かるが、実際に見てきたサイトの構成別で整理するとこうなる。
| プラグイン数 | 推定年間CVE件数（影響あり） | 対応コスト目安（年間） |
|---|---|---|
| 5個以下 | 1〜2件 | 4〜10万円 |
| 10〜15個 | 3〜5件 | 12〜25万円 |
| 20〜30個 | 5〜10件 | 20〜50万円 |
問題は、「プラグイン20個」という構成が中小企業のWordPressサイトではかなり標準的なことだ。SEO系・フォーム系・セキュリティ系・ページビルダー・SNS連携…とインストールしていくと、気づいたら25個になっていた、という話はよく聞く。
最初のアプローチとして「不要なプラグインを削除しましょう」と提案したが、「以前削除したら何かが動かなくなったことがあって」という理由で手が付けられない、というケースが多い。依存関係が明文化されていないので怖くて触れない状態だ。これは想定外だった。
そういう場合、まずプラグインのリストと役割をドキュメント化するところから始めることにしている。
# WP-CLI でプラグイン一覧と状態をCSV出力する
wp plugin list --format=csv --fields=name,status,version,update
# 最終更新が古いプラグインを JSON 形式で洗い出す
wp plugin list --format=json | \
jq '.[] | select(.update == "none") | {name: .name, version: .version}'このリストを眺めると、明らかに使われていないプラグインが2〜3個は見つかる。そこを削除するだけで、CVEリスクを10〜15%ほど下げられる計算になる。
対策の費用対効果比較
「では何から手をつけるか」という話になるが、コスト効果の順番はこうなると考えている。
| 対策 | 初期コスト | 効果の高さ | 難易度 |
|---|---|---|---|
| ① 不要プラグイン削除 | 1〜2日の調査 | ★★★（高） | 低（ただし事前調査が必要） |
| ② WAF導入（Cloudflare等） | 月3,000〜20,000円 | ★★（中） | 低〜中 |
| ③ 静的サイトへの移行 | 30〜80万円（移行費用） | ★★★★（最高） | 高（長期ROIは最善） |
WAFは導入がシンプルで即効性があるが、根本的な解決にはならない。既知の攻撃パターンは防げるが、CVEが公表されてから修正プラグインがリリースされるまでの数時間〜数日は、どうしても手薄なタイミングが生まれる。運用を考えると、「WAFを入れたから安心」とはならないという認識が重要だと思っている。
プラグイン削減は即効性が高い割にコストが低い。問題は「削除して壊れないか」という不安を取り除く事前調査に時間がかかることで、ここがボトルネックになりやすい。
静的化は長期目線では圧倒的にコスト効果が高い。CVEが発生しない構成にしてしまえば、対応工数はほぼゼロになる。移行コストは30〜80万円程度だが、年間のCVE対応コストが20〜40万円かかっている場合、2〜3年で元が取れる計算になる。
移行コスト: 500,000円
年間CVE対応削減: 250,000円
→ 回収期間: 2年このシミュレーションを出したとき、「そんなにかかっていたのか…」と言われることが多い。コストが見えていないだけで、実はかなりの額が継続的に流れている。
振り返って
今回の緊急対応を終えて、あのクライアントとは「次の更新時に静的サイト移行を検討したい」という話になっている。
ただ、静的化が全てのサイトに適切かというと、そうとも言えない。会員機能・カート・予約システムが必要なサイトには向かないし、移行そのものに一定の投資が必要だ。
今考えているのは、サイトの機能要件とCVE対応実績を組み合わせた「移行優先度スコア」を作ることだ。「このサイトは今すぐ移行すべき」「このサイトはプラグイン削減とWAFで十分」と分類できれば、限られたリソースを適切に配分できる。試みたことはあるが、スコアリングの重みづけがなかなか難しく、まだ実用段階ではない。
もし同じような課題に取り組んでいる方がいれば、ぜひ話してみたい。
