背景
某個專案的預演環境總是過一段時間就宕機，所有服務都回應超時，經過排查發現是kafka停止運行導致網關卡死，從而所有請求都無法被處理，然后谷歌查了一下發現，這是因為kafka運行在windows平臺的一個漏洞，因為未能正常關閉打開的日志檔案導致的，網上也有關于這個漏洞的報告以及解決漏洞的合入記錄，修改方法也很簡單，先下載當前使用的kafka版本原始碼，根據合入記錄把原始碼修改一下，然后重新打包放到服務器上面，替換掉之前的包再運行即可，但有個問題，我這么操作合規么？
第三方開源軟體
專案中肯定會使用很多開源軟體，大多情況下都是使用maven進行依賴管理，也有些情況會直接把開源軟體的原始碼復制到專案中，和專案一起編譯，少部分情況下會將開源軟體原始碼下載下來，然后編譯成包，然后再和專案一起運行，
識別漏洞是否有影響
如果某個時間，官方發布了一個CVE漏洞，那如何確定此漏洞是否會對專案產生影響？針對上述三種情況，識別出風險的難易程度是不同的，
首先是對于使用maven管理jar包的情況，可以非常簡單的知道當前使用的版本，再和漏洞影響版本做對比即可確定是否對當前系統有影響，如果是把源代碼直接放在專案中的這種使用情況，這就非常棘手了，因為不太容易確定使用的開源軟體版本，甚至如果當時的開發走了，都無法確定系統中使用了哪些開源軟體，哪些代碼是自研的，哪些是第三方的代碼，
侵入式修改和整包參考
對于直接把第三方原始碼下載下來在自研代碼中使用的行為，一般定義為侵入式修改，而與之對應的，把開源代碼包下載下來（或原始碼編譯成包），不做修改，通過介面呼叫方式來使用的行為，一般定義為整包參考，一般來說，更推薦整包參考的方式來使用第三方專案，
整包參考有如下優點：
1.可以非常明確地知道當前系統中使用了哪些第三方代碼，方便判斷系統中是否存在第三方漏洞；
2.如果需要修改第三方代碼，可以使用補丁方式進行修改，能較好地進行第三方代碼以及補丁的維護作業；如果需要升級第三方代碼，只需要把自研補丁進行適配即可，而侵入式修改可就難升級了，
3.可以更清晰地知道哪些代碼因為使用了第三方代碼需要被動開源，減少法務風險，
當然整包參考的缺點就是開發成本高，本來可以復制粘貼解決的問題，現在需要將整個代碼包引入，并且，如果需要對第三方代碼進行修改，還要使用補丁方式，很大程度上降低了代碼可讀性，
第三方代碼侵入式修改清理
如果不是整包參考的方式使用第三方代碼，就會存在我上面說到的很多問題，特別是漏洞識別和法務風險，業界有很多工具可以進行代碼掃描，從而檢測系統中是否有對第三方代碼的片段參考，如fossid和fossbot，一般掃描完成后，我們需要將確定是使用了第三方代碼的代碼段進行清理，改為整包參考第三方代碼包的方式來使用，如果參考的代碼段較少，直接將參考的代碼重新寫一份，替換掉原來的第三方代碼也可以，
結尾
幸運的是，我使用的kafka框架發布了一個修改了我這次遇到的這個bug的一個版本，我可以直接用這個版本的包，編譯之后就可以使用了，但是我可以這樣做是因為公司沒有限制使用此軟體的版本，正常來說，公司會對所有用到的第三方軟體版本進行限制，如果限制了使用版本，那么我則需要把kafka的原始碼下載下來，然后使用補丁將此漏洞自行修復，然后再編譯成包在系統中使用，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/573.html
標籤：其他
上一篇：day12 面向物件（下）