対象：少人数で複数のWebアプリ（フレームワーク混在）を運用していて、依存ライブラリの脆弱性（CVE）対応を「一度ちゃんと直しきりたい」人。ここでは攻撃手順は扱わず、直して・消えないようにして・監視し続けるまでの実務だけを扱います。きっかけになりがちな事故の例は 公開済みRCEを放置して不正課金された話 を参照。
当サイトの視点：小さな現場ほど『仕組み2つ』で守れる
人手が少ない現場で効くのは、派手なツールより2つの規律です。①自動の変化検知（増えた脆弱性だけ鳴らす）②local→push→deploy（本番は受け取るだけ、編集しない）。当サイトも同じ考えで、依存監査（pnpm audit）を毎デプロイ前＋日次cronで回し、本番へは push-to-deploy で配るだけにしています。1回直すイベントではなく、鳴る仕組みを置いて回し続ける運用に倒すのが、結局いちばん安く長持ちします。
完了の「4定義」を先に固定する
中途半端に「終わった」と言わないための歯止めです。この4つが揃うまでは未完、と先に決めておきます。
① スキャン
現状を数字で把握する
② 修正
非devの重大/高を根治する
③ 隔離/引き継ぎ
直せない・孤立は明示的に
④ 監視
日次の変化検知を載せる
① スキャン：現状を「数字」にする
まず、どこに何があるかを機械で把握します。手動の不定期チェックは必ず途切れます。
ロックファイルを自動探索してスキャン
composer.lock / package-lock.json / pnpm-lock.yaml を探し、OSSのスキャナ（osv-scanner や pnpm audit）に毎日かける。ロックファイルを読むだけなので負荷はごく軽い。重大度は『1つの数字』ではないと知る
ノイズは『無視』でなく『根拠を持って除外』
② 修正：対症療法でなく「根治」する
止血（対症療法）と根治は別作業です。両方やって初めて終わりです。
対症療法だけ（封じ込め止まり）
- リバースプロキシで“それっぽい”リクエストだけ弾く
- 症状が止まったので「対応完了」と考える
- 脆弱な依存はそのまま＝RCE等が生き続ける
根治（正しい）
- 脆弱な依存を修正版へ更新して穴そのものを塞ぐ
- 更新後、兆候が消えたかをログで確認
- 止血と根治を別作業として両方やる
メジャー跨ぎは『本番に出す前にビルド検証』
パッチ当てと違い、メジャー版跨ぎ（フレームワーク14→15、UIツール4→6 等）は破壊的変更を伴う。盲目的に上げて本番ビルドが落ちると最悪。本番と同一ランタイム（同じNode/PHP版のコンテナ）に編集後ソースを置き、ビルド/型チェックを完全に通してから push する。落ちたエラーは1つずつ潰す（同期→非同期化のcodemod、CSSの複数行class、型名前空間の廃止 等）。旧コンテナが動き続ける構成なら、失敗時も無停止で切り戻せる。
修正の「永続性」まで含めて完了
中身が100点でも、次のデプロイで消える運用なら0点です。ここが一番やりがちな落とし穴。
本番の作業ツリーで直接commitしない
必ず local→push→deploy の一方向に統一
HTTP 200を『正常』と信じない
curl | grep）、エラーログに新規が出ていないか、DB依存やパラメータ付きの動的ルートまで踏む。キャッシュで反映が遅れることもあるので時間をおくかクリア後に。③ 隔離/引き継ぎ：直せないものを「明示」する
全部を今すぐ直せるとは限りません。直せない・別管轄・もう使っていない、を曖昧にしないのがコツです。
孤立・EOLコードは『消す前に隔離』
本当に未参照かを確定してから
直せない/別管轄は明示ハンドオフ
④ 監視：日次の「変化検知」を載せて初めて完了
ここまで来て、最後に鳴る仕組みを置きます。これが無いと、せっかく直しても再発に気づけません。
『全部毎日鳴らす』でなく『増えたら鳴らす』
スキャン結果を前回との差分（state file）で比較し、新規の重大/高が出た時だけ通知する。毎日同じ内容が届くとすぐ無視される（アラート疲れ）。通知はメール1通に要約（新規・解消・現状）し、cronで日次。共用サーバーでもスキャナ1バイナリ＋cronで十分回る（負荷は数ミリ秒〜・niceを噛ませれば安心）。
棚卸しで一緒に出てくる「秘密」と「鍵」
CVEを直しきる過程では、依存以外の穴もよく一緒に見つかります。代表が2つ——公開ディレクトリに置き忘れた秘密ファイル（webrootに古いトークンが放置、共通テンプレ由来なら全台に同じ穴）と、侵害され得る一時環境に渡したroot鍵。どちらも「1か所漏れたら全部」を生む典型なので、CVE対応と同じ棚卸しのタイミングで点検します（この2つはそれぞれ単独で深掘りする価値があります）。秘密の基本は 秘密の安全な保管 と 最低限チェックリスト を参照。
次に読む
よくある質問
Q脆弱性対応はどこまでやれば『完了』ですか？
4点が揃って初めて完了です。①スキャンで現状を数字にした②非devの重大/高を修正した③直せない・別管轄・孤立コードは明示的に隔離/引き継ぎした④日次の変化検知（再発・新規をキャッチする監視）を載せた。特に④を載せるまでは完了ではありません。依存は明日また脆弱になるからです。
Q毎日スキャンするとアラートに疲れませんか？
『全部を毎日鳴らす』とすぐ無視されます。前回結果との差分を取り、新規の重大/高が出た時だけ通知する『変化検知』にします。毎日同じ内容を送らないことが、結局いちばん長続きする設計です。
Q修正したのに、また脆弱に戻ることがあるのはなぜ？
本番の作業ツリーで直接commitすると、次のデプロイ（pull や checkout -f）で上書きされて修正が消えます。必ず local→push→deploy の一方向に統一し、本番は『受け取るだけ』にします。修正の中身が完璧でも、消える運用なら成果はゼロです。