歴史
Log4Shell（CVE-2021-44228）— 世界中が一晩で“使っているか分からない”脆弱性に震えた日
2021年12月、Javaのログ出力ライブラリLog4jに最高ランク（CVSS 10.0）のリモートコード実行が見つかりました。怖さの本質は『自分が直接使っていなくても、別のライブラリ経由で巻き込まれる』推移的依存。仕組みの図解、時系列、そしてSBOM・依存の機械監視・迅速なパッチという、いま効く教訓を図と表でまとめます。
過去の大きな事件を、攻撃の再現ではなく「いま自分の運用に効く教訓」に絞って振り返ります。
何が起きたか — “受け身の処理”が攻撃経路に
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 とは
- 対策：依存の機械監視を運用に組み込む
- 事故：既知CVEの放置で1.47億人が漏れた話
よくある質問
QLog4Shellは何が“新しい”怖さだった？
『自分が直接入れた覚えがなくても、別のライブラリの中で使われていて脆弱』という、推移的依存（transitive dependency）の怖さを世界規模で突きつけた点です。自分のSBOM（部品表）を把握していないと、影響有無すら判断できませんでした。
Qなぜログ出力が攻撃経路になったの？
Log4jが、ログ文字列の中の特定の記述を『外部を参照して解決する』機能として解釈したためです。攻撃者は、ログに残る場所（ユーザー名・HTTPヘッダ等）に細工した文字列を入れるだけでよく、受け身のはずのログ出力が実行経路になりました。
Q同じことを繰り返さないには？
①依存を機械で監視（Dependabot/osv-scanner）して該当CVEを自動検知、②SBOMを生成して『何を使っているか』を可視化、③パッチを素早く当てる運用、の3点です。追随CVE（修正の修正）まで追うことも重要です。