個人開発の脆弱性対策を、7段階のフローにした

9月の終わりに、ブログを置いているレンタルサーバー（XServer）から、「WordPressの脆弱性に関する注意喚起」というメールが届きました。私のブログは、もうWordPressではありません。それでも「本当に関係ないのか」を、AI（Claude Code）と一緒に確かめました。

確かめてみると、ブログは対象外でした。ただ、調べる途中で、ブログとは別の所に、直したほうがよい所を見つけました。そこで、知らせが来たときだけ慌てて調べるのをやめ、脆弱性対策を毎週回すフローに変えました。自分でサーバーや手元のAIの道具を動かしている方に向けて、この記事では、その経緯と設計、2週間回してみた結果をまとめます。

届いたお知らせの中身

メールにあった脆弱性は、CVE-2026-87902です。CVEは、公開された脆弱性に付く世界共通の番号です。深刻さは、CVSSという共通の物差しを使い、0〜10点で表します。7.0以上が「高（High）」、9.0以上が最も重い「緊急（Critical）」です。

調べると、次のような脆弱性でした。

項目	中身
対象	WordPress 4.7.0〜7.1.1
何が起きるか	ログインしなくても、外からサイトを乗っ取られるおそれがある
深刻度	Patchstackの評価で9.2（緊急）。米国の政府機関のデータベース（NVD）では8.1（高）
直った版	7.1.2（古い系列は7.0.6・6.9.9・6.8.10）
状況	修正が出てから数時間で、攻撃が始まっている

出典はPatchstack、The Hacker News、NVDです。なお、メールの中のリンクは開かず、同じ脆弱性を扱っている別の情報源を、自分で検索して確かめています。注意喚起を装った偽のメールもあるためです。

私のブログに関係あるかを、実物で確かめる

このブログは、今年の夏にWordPressからAstro（HTMLを前もって作っておく静的サイトの仕組み）に作り直しました。サーバーの上で、WordPressを動かすPHP（プログラムの言語）は動いていないはずです。

ただ、「はず」のままにせず、外から実際に確かめました。WordPressの入口にあたるURLを7か所（wp-login.php・wp-admin/・xmlrpc.php・wp-json/・readme.html・wp-content/・wp-includes/）開くと、すべて「ページが無い」（404）でした。また、ブログを本番へ反映するたびに、公開用のフォルダを丸ごと置き換える作りになっているので、古いWordPressのファイルは残っていません。

つまり、このブログは対象外です。

調べる途中で、別の穴が見つかった

今回いちばんの学びは、ここからです。

関係あるかを確かめるついでに、「今、外から届く状態になっているものは何か」も一緒に洗い出しました。すると、WordPressとは関係のない所で、直したほうがよい所を2つ見つけました。

Macのファイアウォール（外からの接続を止める仕組み）が無効になっていた
手元で動かしているAIの道具の1つが、同じネットワークから認証なしで使える状態になっていた

ファイアウォールは、その場で有効にしました。AIの道具のほうは、Macを家の外へ持ち出さないので急ぎ度を下げ、このあと作ったフローに乗せて直しました（結果は後の節に書きます）。

Macなら、待ち受けているものは lsof -nP -iTCP -sTCP:LISTEN で、ファイアウォールの状態は /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate で確かめられます。

もし届いたメールの1件だけを見て「うちは関係ない」で終えていたら、これらには気づかなかったと思います。待っているだけだと、目に入るのは、たまたま届いた知らせだけです。私が本当に知りたかったのは「自分が動かしているものの中に、危ないものが無いか」のほうでした。

脆弱性対策をフローにする

そこで、Claude Codeと一緒に、脆弱性対策のフローを設計しました。流れは次の7段階です。

点検：週に1回、自分が動かしているものの版を集め、公開されている脆弱性の情報と突き合わせる
抽出：自分に当てはまるかどうかを決まった規則で振り分け、急ぎ度を付ける（当てはまらないものは「対象外」として理由と一緒に残す）
通知：新しく見つかったものだけを、Macの通知で知らせる
方針：1件ずつ本当に当てはまるかを実物で確かめ、対策案を報告書にする
承認：私が項目ごとに「やる／保留」を決める
実施：承認されたものだけを直し、直ったかを確かめる
記録：判断と対応を台帳に残し、月に1回振り返る

1〜3は、毎週土曜の朝に自動で動きます。自動にするのは、この「読むこと」と「知らせること」だけです。何かを変えるのは、必ず5の承認のあとにします。

設計で決めたこと

動かしているものの一覧を持つ

最初に作ったのは、私が動かしているものの一覧です。ブログ、サーバー、自動化の道具（n8n）、手元のAIの道具、コードが使っている部品、鍵やトークンの期限、そして外から何が届くか（待ち受けているものとファイアウォール）まで入れています。n8nは、決まった時刻や外からの呼び出しで、処理を自動で動かす道具です。

一覧に無いものは、点検されません。そのため、新しい道具を入れたら一覧に足すことを、一覧の先頭と手順書に書いておきました。

急ぎ度を5つに分ける

見つかったものは、次の5つに分けます。

急ぎ度	条件
至急	攻撃が確認されていて、外から届き、自分の版が影響を受ける
要対応	深刻度が「高（High）」以上（CVSSで7.0以上）で、自分の版が影響を受ける
要確認	版が分からない、または設定しだいで当てはまる
参考	深刻度が「中」「低」で、自分の版が影響を受ける（報告書には載せ、通知は件数だけ）
対象外	使っていない、影響する版の範囲の外、または直った版を使っている

開発のときだけ使う部品は、深刻度が高くても「要確認」に下げます。ただし、攻撃に使われたと確認されたものは下げません。

「対象外」にするときも、理由を必ず台帳に書きます。今回のWordPressなら「静的サイトで、入口はすべて404」です。あとから同じ知らせが来ても、なぜ対象外にしたかを辿れます。

新しく払う費用は0円で組む

新しく払う費用は0円にしました。脆弱性の情報は、無料で使えるものだけです。AIは、もともと使っているClaude Codeの範囲で動かします。

OSV.dev：Googleが公開している脆弱性のデータベース。コードが使っている部品の名前と版を送ると、当てはまる脆弱性を返してくれる
GitHubのセキュリティ勧告：GitHubが集めている勧告のデータベースと、使っている道具の公式リポジトリに出る勧告。コードの部品ではない、手元やサーバーで動かしている道具はここで見る
CISA KEV：米国の政府機関が公開している「実際に攻撃に使われた脆弱性」の一覧

また、点検と抽出にAIは使いません。決まった規則で分けるだけにしています。AIが働くのは、私が頼んだときだけです。4の「方針」づくりと、承認したあとの6の「実施」がそれに当たります。

AIに任せる所、人が決める所

方針づくりの手順は、Claude Codeの手順書（Skill）にしました。「このセキュリティのメール、対策が要る？」と聞けば、Claude Codeは次の順に動きます。

脆弱性の情報を、複数の情報源で確かめる
自分の環境で実際に測る
急ぎ度を決める
対策案と戻し方を報告書にまとめる

一方で、決めることと、管理画面やシステムの設定を触ることは、私の役割です。今回のファイアウォールも、Claude Codeが手順を示し、私が設定し、Claude Codeが有効になったかを確かめました。

手順書には「やってはいけないこと」も書きました。承認の無い変更をしない、メールのリンクを開かない、そして対策が済んでいない穴の詳細を公開の場に書かない、などです。この記事も、その決まりに沿って書いています。

2週間回してみて

土曜の朝の自動点検は、これまでに2回動きました。そのたびに報告書ができ、新しく見つかった分だけがMacの通知で届いています。

この2週間で直したのは、次の5つです。どれも、急ぎ度を付けて対策案をまとめ、私が決めてから直しました。

見つけたもの	やったこと
ブログを作る部品の脆弱性10件	部品の版を上げて、その時点の10件を0件にした
自動化の道具（n8n）の版の遅れ	最新の安定版に上げた
自動化の入口（外からURLを呼ぶと処理が動き出す口）のうち2つが、認証なしで動かせた	合言葉やパスワードを付けた
AIの道具が、同じネットワークから使えた	このMacの中からしか使えない設定にした
サーバーに、古いWordPressの登録（データベース）だけが残っていた	ファイルは無く、入口もすべて404だった。控えを残してから消した

きっかけのWordPressの脆弱性は対象外でしたが、最初に直したファイアウォールを含めると、直すものは6つ見つかりました。このうちブログの部品の脆弱性は、週1回の自動点検が見つけたものです。

これから

次は、通知をチャットにも送り、スマホで見られるようにします。また、7の「月に1回の振り返り」は、まだ回していません。最初の振り返りで、同じ種類のものが繰り返し出ていないかを確かめます。

脆弱性の知らせは、これからも届き続けるはずです。そのときは一から調べ直さず、同じ手順で確かめ、同じ台帳に残します。それだけでも、慌てる場面はかなり減ると考えています。

これは私の環境に合わせたやり方なので、1つの参考として見ていただければと思います。