資安事件與漏洞
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 之後，對修復的再修復出現了多次。不要在『修過一次』就收手，要一直追到後續報導。
接下來閱讀
FAQ
QLog4Shell『新』在哪裡、為何如此可怕？
它在全球範圍內讓人直面了傳遞性相依（transitive dependency）的恐怖：『即使你沒有印象自己直接引入過，它也在另一個函式庫內部被使用著，並且存在漏洞』。如果不掌握自己的 SBOM（物料清單），連是否受影響都無從判斷。
Q為什麼日誌輸出會成為攻擊通道？
因為 Log4j 把日誌字串中的特定寫法當作『參照外部進行解析』的功能來解釋。攻擊者只需在會被記入日誌的位置（使用者名稱、HTTP 標頭等）放入經過構造的字串即可，本應是被動的日誌輸出由此變成了執行通道。
Q怎樣才能不重蹈覆轍？
三點：①用機器監控相依套件（Dependabot/osv-scanner），自動偵測對應的 CVE；②產生 SBOM，把『自己在用什麼』可視化；③建立迅速修補的維運機制。追蹤後續 CVE（對修復的再修復）同樣重要。