Claude Securityでコードを調べ、その結果を踏まえて改善を進めている。セキュリティの専門家ではない僕にも、普段の実装やレビューとは違う角度から、自分の作ったものを検める手段が増えた。毎日コードを書いているからといって、そのコードの危うさまで毎日見えているとは限らない。ありがたく使わせてもらっている。

そんな折、PHPに「PHP2Shell」と名付けられた重大な脆弱性が見つかった。普段PHPを書かない僕も、勤務先のコーポレートサイトについて影響を調べ、対応することになった。自分の得意な言語だけを気にしていれば済むほど、会社のシステムは行儀よく揃っていない。使っていないつもりの技術も、視野を少し広げるとしっかり動いているのである。

AIを使って脆弱性を発見したという報告も読み、日々触っている言語やフレームワークにも同じことが起こりうると感じた。ただし、AIによる発見と、攻撃へのAIの利用は区別する必要がある（Wiz：PHP2Shellの解説）。同じ時期には、GMOインターネットグループも「お名前.com デスクトップクラウド」への不正アクセスを公表している。こちらは公表資料で侵入経路を調査中としており、PHP2Shellとの関連も、攻撃へのAIの利用も確認されていない（GMO：第2報）。それぞれの事実を無理につなげることはできないが、自分たちの備えを考え直すには十分な出来事だった。

僕の本業はWebアプリケーションを設計し、作り、運用することだ。とはいえ、セキュリティ専任の人がいなければ、開発者が普段の仕事に加えて守りも引き受ける。問題のあるコードを減らすことも、侵入された場合の被害を小さくすることも、その仕事に含まれるだろう。そして、問題が判った後には、修正を届ける仕事が待っている。コードを調べる道具が便利になるほど、その先を自分たちで進められるかも気になってくる。

指摘の先にある仕事

Claude Codeで使えるClaude Securityプラグインは、公式ドキュメントによれば、コードベースを把握して脅威モデルを作り、脆弱性を探す。その後は別のエージェントが指摘を検証し、結果をもとに修正パッチを提案させることもできる。僕はすでにこれを使って改善を進めているが、ここで得られるのは、あくまでコードを見直すための手がかりだ。実行したという実績だけを積んでも、コードが勝手に直るわけではない。

Cloudflareが公開しているsecurity-audit-skillも興味深い。READMEでは、コードの構造や信頼境界、入力経路を把握し、調べた範囲を記録しながら問題を探す手順を、コーディングエージェントに与えている。続いて別のエージェントが、指摘を反証するつもりで検証する。報告は確認済み・要追加検証・否定済みの3つに分かれる。こちらを僕が試したわけではないが、調査と検証の手順が公開されているのはありがたい。

こうした結果を読む時は、指摘の数より、その指摘がどこまで確かめられているかを見たい。調べていない箇所が残っているのか、追加の検証を要するのか、それとも問題として成り立つのか。指摘が出なかった場合にも、確認できた範囲は限られる。何も出なかったから安全、と受け取るには話が早いのだ。Claude Securityの公式も、静的解析や依存関係のスキャン、コードレビューとの併用を前提に説明している（公式ドキュメント）。

だから、僕としてはAIの監査を普段の開発につなげたい。CIには既知の脆弱性やルールにもとづく検査を繰り返させ、その上でAIに、コードの文脈や処理の組み合わせを踏まえた問題を探してもらう。手作業だけでは忙しい時に抜けるし、見る人によって観点も違う。PRの作成時と定期実行の両方で確認する機会を設ければ、思い出した時だけ点検するより続けやすいはずだ。

調べたいものツール例見つける手がかり
依存ライブラリDependency Review、npm audit公表済みの脆弱性を持つ依存関係
自分たちのコードCodeQL、Semgrepセキュリティ上問題のある実装
リポジトリ中の秘密情報Gitleaks混入したAPIキーや秘密鍵
コンテナやインフラ設定Trivyパッケージの脆弱性や設定不備
動いているアプリケーションZAPレスポンスやHTTPヘッダーなどに現れる問題

GitHubのDependency Reviewなら、PRで変更された依存関係を調べ、脆弱性があるものが持ち込まれる時にチェックを落とせる。CodeQLはソースコードを解析し、TrivyやZAPは別の対象を検査する。なにを調べたいかによって道具は変わるし、コードを変えなくても新たな脆弱性の公表によって結果は変わる。チェックをPRの時だけで済ませたくないのは、そのためだ。

ただ、検出する機会を増やせば、結果を読む仕事も増える。通知を見る人、マージを止める条件、誤検知の扱い、すぐには直せない指摘の扱いも決めておく必要がある。誰も引き受けないまま通知だけが増えても、未読の数字が立派に育つだけだろう。僕が欲しいのは件数の多い報告書より、妥当な指摘が修正へ進む流れである。

修正を届けられるか

指摘が妥当だと判れば、直してテストに残す。ここでテストしたいのは、新しく作った機能が動くことだけではない。許していない操作を、きちんと拒めることも確かめたい。たとえば組織ごとにデータを管理するアプリケーションなら、別の組織のデータIDを渡しても読み書きできてはいけない。

閲覧権限のユーザーが直接APIを叩いても更新できないか。リクエストに余分な項目を加えて、所属組織や権限を書き換えられないか。こうした観点の洗い出しや実装にも、AIの力を借りられる。OWASPのテストガイドも、認証・認可・セッション管理などを個別の確認領域として扱っている（Web Security Testing Guide）。普段の機能開発で確認する操作から、目を向ける範囲を広げるわけだ。

むろん、期待する挙動まで今の実装から推測させてしまうのは困る。実装が間違っていた場合、その間違いを律儀に守るテストが出来上がってしまう。権限のルールや仕様は、人が確かめてから与える必要がある。テストが通ることを喜ぶ前に、なにを正解にしたのかを見ておきたい。

一方、PHP2Shellのように、使っている技術そのものに脆弱性が公表される場合もある。こちらは自分のコードの監査だけでは済まない。依存ライブラリ、ランタイム、コンテナのベースイメージ、CMSやプラグインまで含め、なにをどこで使っているかを把握しておく必要がある。外部の会社に運用を任せているものも、誰に訊けばいいのか、誰が更新するのかが判らなければ、影響の確認から手間取ることになる。

影響が判っても、更新後の挙動を確かめる手段がなければ判断は難しい。ログインや主要な業務処理を自動で確認できれば、毎回すべてを手でなぞる負担は減らせる。テストは実装の誤りを探すだけでなく、修正版を当てる時の手がかりにもなる。通っただけで何も問題がないと断言はできなくても、判断材料がまったくない状態よりは、ずっと更新しやすい。

その次には、本番へ出す手順が要る。問題が起きた時の切り戻し、必要に応じたサービスの一時停止、認証情報の失効や変更も考えておきたい。ログの調査やバックアップからの復元も含め、必要になってから初めて調べる仕事を少なくしておく。AIに構成や手順の整理を手伝わせることはできるが、実際にその手順を実行できるかは自分で確かめるほかない。手順書の存在と、復旧できることは同義ではないのである。

そう考えると、コードの監査、CIの検査、テスト、構成や運用手順の把握は、別々の雑務というより連続した仕事に見える。問題を見つけ、その指摘を確かめ、直し、動作を確認して本番へ出す。うまくいかなければ戻し、必要なら影響を抑える。途中のどこかが判らなければ、そこで対応が止まる。僕の手元でパッチが出来上がっただけでは、まだ利用者のいるシステムは変わっていないのだ。

地味な仕事の順番

もっとも、こうした準備がいつでも優先されるなら苦労はしない。ライブラリやランタイムを更新しても、新機能のように画面は華やがず、売上が増えるとも限らない。いま動いているものに、なぜ時間を使うのか。エンジニア以外の人に説明するのは、なかなか骨が折れる。しかも更新する側にも、互換性の問題や動作確認という負担がある。

その横では機能開発や問い合わせ対応が待っている。どれも必要な仕事なので、更新は少しずつ後ろへ送られていく。専任の担当者がいないならなおさらだし、僕自身も普段の開発と並行して対策を進める立場である。この積み残しを、怠慢の一言で片づける気にはなれない。

さらに年月が経てば、担当者が辞め、仕様も構成も判る人がいないまま動き続けるシステムも出てくるだろう。なにをしているかは判らないが、止めると困ることだけは判っている。そうなると、更新のたびに考古学から始めることになる。使っている場所、担当、確認方法、戻し方を調べ直す間にも、対応の時間は過ぎていく。

これはPHP2Shellそのものが生まれた原因の話ではない。広く使われている技術に重大な脆弱性が公表された時、使う側に積もっていた事情が、修正を当てるまでの時間を左右するという話だ。英国のNCSCも、AIによって既知の脆弱性を悪用する能力が高まり、公表から悪用までの時間はさらに縮まると評価している（Impact of AI on cyber threat from now to 2027）。日頃の更新やテスト、構成や手順を記録する時間には、その時の調査を短くする意味もある。

以上、PHP2Shellをきっかけに、自分が進めている改善と、その先に必要な備えを考え直した。Claude Securityによる監査はすでに使っているし、結果を踏まえた改善も進めている。ここにCIのチェックやテストをつなげ、更新を届けられる状態を保っていきたい。専門家ではない僕がすべてを1人で判断できるとは思わないが、日々の開発で引き受けられる仕事はある。

問題を見つける道具が増えた今、その指摘を直せる自分たちでありたい。

参考資料