DevOps經歷的 Log4j痛苦經歷 - Reddit

banq發表於2022-03-22
dev

我的公司一直在為log4j的修復而苦惱：
巨大的微服務架構意味著數百個應用程式需要更新、重建和重新部署他們的repo。
更糟的是，自從log4j之後，該公司對所有的庫都進行了嚴格的掃描和修復要求。如果在幾天內沒有得到解決，儲存庫中的映象有任何CVE，現在就會被升級到有副總裁參與的作戰室...。
我們的CI/CD肯定沒有準備好，而且一直在努力保持我們的數百個正在執行的應用程式的頂部，因為新的漏洞被發現...... 而我們是一家大公司（比如，最大的公司之一）。

我只是想知道其他開發者有什麼經驗...... 你是否有100-1000個應用程式，而log4j對你的組織來說是個小菜一碟？
巨大的影響使其他一切都停滯不前？
你是否利用了像whitesource、snyk等SCA的優勢？
你們使用什麼工具來管理這樣大量的程式碼/repo級的變化，是容易還是困難？
gitlab是不是為你做了所有的事情？
而且，如果你確實有100-1000個應用程式，而下一個log4j的情況出現了，你是否設定了自動修復它的時間？如何解決？
  
Reddit網友：
我們有大約5個共同的架構，由DevOps團隊和架構團隊管理。每個人都從一個實現該架構的 repo 中提取，並在此基礎上開發他們的應用程式。更新中央架構，每個人都會繼承，應用程式會受到保護。
第三方應用程式是另一個問題。Zookeeper是狗屎
 
我的公司相當大，不是怪物，但足夠大。我們在處理更多的現代微服務方面沒有什麼困難，所有的微服務都有一個所有者團隊，修復和部署工作在幾天內就完成了。我們確實在遺留問題上做了努力...... 有些程式碼已經12年沒有被碰過了（這是我需要修復的最古老的程式碼），是的，新的掃描每天都會發現新的CVE...... 修復起來還是很麻煩的。
 
有300多個應用程式需要更新。花了幾周的時間來發布所有的新版本。現在又有新的工具來掃描漏洞，我們應該更新所有的關鍵庫。
 
這裡是大公司 SRE：它需要我們大約 100 人待命的一個完整週末，基本上是為我們許多很多盒子中的每一個更新補丁，然後在我們整理完所有內容時多次重新啟動所有內容。幸運的是，漏洞本身沒有任何實際影響，因為我們幸運地擁有良好的網路隔離。
  
我遇到的挑戰是，我的公司提供了幾個不同的SaaS應用程式，其中我的開發團隊支援3-4個。當log4j漏洞被公佈時（12月中旬），我們沒有立即進行自動掃描來確定哪些是有漏洞的，所以我們自然而然地詢問開發人員他們的應用程式是否有漏洞。
由於是12月中旬，每個人都在燃燒他們最後的假期，我們只有一個骨幹人員，開發人員不能給我們明確的指示，告訴我們該怎麼做或什麼是有漏洞的，儘管我們有來自管理層的最後期限，所有東西都需要在3天內修復。

更糟糕的是，我們的一些應用程式是單使用者的，所以我們需要客戶的批准才能獲得不定期的停機時間，那接近年底的時候，溝通很慢，所以我們只是決定緊急改變是可以的，因為這些改變與安全有關。

更糟糕的是，儘管我們在devops中部署了應用程式，但我們有一個實施團隊，與客戶一起工作，以定製東西。這就造成了我們的標準化的偏移，所以如果一些傻瓜移動了檔案，或者做了一個沒有記錄的改變，那麼.jar檔案就不在它應該在的地方（他們應該開一個票，這樣我們就可以更新模板/指令碼並重新部署）。因此，我們的自動化查詢和替換可能會失敗。在規模上，這就成了一個問題，因為我們有時不得不用RDP/SSH來手動尋找這個檔案。

當我們最終認為我們已經完成了工作，並且沒有什麼問題時，2月份的時候，一個開發團隊說他們搞錯了，他們的應用程式有漏洞，而且已經有兩個月了，開發團隊需要立即替換jar檔案，這樣我們才能透過第三方審計。
 

實際上是從 Jar 檔案中刪除了幾個類。只需將更改合二為一。將該 log4j 庫推送到伺服器的其餘部分。這有什麼難的？

zip -d log4j-core-2.0.2.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

  
 

相關文章