12月10日，看到朋友圈中已經有人在通宵修改、上線系統了。隨即，又看到阿裏雲安全、騰訊安全部門發出的官方報告：” Apache Log4j2存在遠程代碼執行漏洞 “，且漏洞已對外公開。
看到相關消息，馬上爬起來把所有項目的日誌系統過濾壹遍，還好老項目采用的log4j，新項目采用的logback，沒有中招。隨後就看到朋友圈鋪天蓋地的相關消息。
作為壹個史詩級的事件，緊急修改漏洞是必然的。作為程序員，如果看到這則消息，連去核查壹下系統都做不到，那真的不是壹個合格的程序員。
經歷過這次事件，不僅是看熱鬧而已，還要思考壹下，作為小公司如何避免、提前預防、做好準備應對這類Bug。
Apache Log4j2是壹款優秀的Java日誌框架，與Logback平分秋色，大量主流的開源框架采用了Log4j2，像Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影響。所以，這樣壹個底層框架出現問題，影響面可想而知。
漏洞信息： Apache Log4j 2.15.0-rc1 版本存在漏洞繞過，需及時更新至 Apache Log4j 2.15.0-rc2 版本。
影響範圍：2.0 <= Apache log4j2 <= 2.14.1。
最新修復版本：/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
方案壹：升級版本，發布系統；
方案二：臨時補救：
攻擊偽代碼示例：
基於上述代碼的基本攻擊步驟：
騰訊安全專家的回復現如下：
log4j2漏洞復現
關於漏洞及解決方案，上面已經詳細聊了，問題基本得以解決。在大的互聯網企業，是有專門的安全運維部門來監控、掃描這些漏洞的。但在小公司，很顯然沒有這樣的條件。
那麽，我們該怎麽辦？同時，作為事件的經歷者，妳是否思考過這個事件中反映出的壹些其他問題嗎？
在大企業，壹旦發現這樣的漏洞，安全部門會第壹時間進行通知。但在小企業，沒有安全部門，妳是如何獲取到漏洞的消息的呢？
比如我所在的企業，是沒有安全部門的，但也幾乎是第壹時間得知漏洞消息，進行系統排查的。
如何獲得圈內第壹手消息，取決於也反映著妳在社交圈或技術圈所處的位置與現狀 。
很多朋友可能也看到了這則漏洞消息，但也就是看壹下熱鬧，然後該幹嘛幹嘛了，系統有漏洞就有漏洞了唄~
如果妳是如此，或者妳的團隊是如此，妳真的需要反省壹下職業素養問題了。
很多人可能覺得自己很牛，覺得自己懷才不遇，覺得工資收入低，覺得被虧待……那麽，對照壹下對這件事所作出的反應，基本就知道自己是不是被虧待了。
這樣的突發事件，也是對系統運維、團隊管理的壹個考驗，也是壹個仿真練習：大家都正在進行著當前業務的開發，有壹個突發Bug要修改，改壹半的代碼如何操作？如大面積發布？
第壹 ，改壹半的代碼怎麽辦？如果妳的團隊的代碼開發都是基於master（主幹）進行開發、提交代碼，針對這樣的突發事件，必然會面對改了壹半的代碼，提交了，想壹起發布但還沒測試，這種騎虎難下的局面。
所以，代碼的管理（如何打分支、合並分支、分支與主幹代碼不同環境的發布）必須得從日常的點滴做起，當突發事件發生時，也不至於手忙腳亂。
第二 ，有大量項目需要發布怎麽辦？當然，最古老的方式就是壹個系統壹個系統手動發布。如果是微服務及應用較多，不僅容易出現錯誤，而且耗時較長。這就提醒我們，構建自動化發布流程的重要性。
有安全部門的公司，會定期掃描系統漏洞，那麽沒有安全部門的公司只能坐以待斃嗎？
任何壹個漏洞對軟件系統來說都有可能是致命的，也是需要我們謹慎對待的。對於漏洞的處理及做出的反應也是從業者職業素養的體現。
而如果能從壹次次突發事件中學習、思考到更多內容，妳將比別人更快地成長。