過去の大きな事件を、攻撃の再現ではなく「いま自分の運用に効く教訓」に絞って振り返ります。
何が起きたか：ログを出力する処理が攻撃経路になった
Log4j は、ログを出力するというごくありふれた処理を担うライブラリで、Javaのアプリケーションに非常に広く使われていました。問題は、ログに含まれる文字列の中の特定の記述を、ライブラリが「外部を参照して解決する」機能として解釈し、結果として外部から指定されたコードを実行してしまう点にありました。
つまり、攻撃者が「ログに残るような場所」（ユーザー名、HTTPヘッダ等）に細工した文字列を入れるだけで、サーバー側でコード実行に至り得た。ログ出力という受け身の処理が攻撃経路になったことは、大きな驚きをもって受け止められました。
なぜ影響の有無をすぐに確認できなかったのか
多くのアプリは Log4j を直接入れた覚えがありません。フレームワークやSDKが内部で使っていたのです。これが**推移的依存（transitive dependency）**です。依存の依存の、そのまた依存。自分の「部品表」を持っていないと、影響の有無すら判断できませんでした。
最大の問題は、使っているかどうかを把握できなかったこと
「使っているか分からない」状態では、対処の優先順位も付けられません。自分の部品表（SBOM）を持っているかで、初動の速さが大きく変わりました。
時系列
2021-12-09〜10
脆弱性が広く知られ、世界中が一斉に「うちは影響あるか」の確認に走る。直後
緊急パッチ適用と暫定緩和策が走る。攻撃の試行も急増。その後
修正の不備を直す追随CVEが複数公表。「一度直した」では終わらなかった。
いま効く教訓
SBOM（部品表）を持つ
自分のアプリが内部で何を使っているかを可視化する。npm ls / ロックファイル / SBOM生成ツールで「実際に動いている依存」を把握。「直接入れたもの」だけ見ても足りない。
依存を機械で監視する
CVE が出た瞬間に、該当するかを自動判定（Dependabot / osv-scanner）。推移的依存まで含めて検査できるのが機械監視の強み。人力の巡回では必ず見落とす。
パッチ運用を速くする
緊急時に「すぐ上げて検証して出す」が回せるよう、普段から更新作業に慣れておく。依存追従のしくみも参照。
追随CVEまで追う
Log4Shell以降、修正の修正が複数出た。「一度直した」で打ち切らず、続報まで追いかける。
次に読む
- 用語：RCE とは / CVE とは
- 対策：依存の機械監視を運用に組み込む
- FW別：Spring Bootのセキュリティ対策（依存CVE・Actuator・認可）
- 事故：既知CVEの放置で1.47億人が漏れた話
- 事故：Heartbleed — OpenSSLの重大欠陥
出典と確認範囲
以下は上記の設定・影響範囲・対策を確認するための原典です。2026年10月23日に参照先を確認しました。各版・構成の条件は原典で確認してください。チェックリストの優先順位や教訓は当サイトの整理であり、記事全体の再検証や安全性の保証を意味しません。