開源軟件存在漏洞致使系統崩潰

背景

某個項目的預演環境老是過一段時間就宕機，全部服務都響應超時。通過排查發現是kafka中止運行致使網關卡死，從而全部請求都沒法被處理。而後谷歌查了一下發現，這是由於kafka運行在windows平臺的一個漏洞，由於未能正常關閉打開的日誌文件致使的。網上也有關於這個漏洞的報告以及解決漏洞的合入記錄。修改方法也很簡單，先下載當前使用的kafka版本源碼，根據合入記錄把源碼修改一下，而後從新打包放到服務器上面，替換掉以前的包再運行便可。但有個問題，我這麼操做合規麼？

第三方開源軟件

項目中確定會使用不少開源軟件，大多狀況下都是使用maven進行依賴管理，也有些狀況會直接把開源軟件的源碼複製到項目中，和項目一塊兒編譯。少部分狀況下會將開源軟件源碼下載下來，而後編譯成包，而後再和項目一塊兒運行。

識別漏洞是否有影響

若是某個時間，官方發佈了一個CVE漏洞，那如何肯定此漏洞是否會對項目產生影響？針對上述三種狀況，識別出風險的難易程度是不一樣的。

首先是對於使用maven管理jar包的狀況，能夠很是簡單的知道當前使用的版本，再和漏洞影響版本作對比便可肯定是否對當前系統有影響。若是是把源代碼直接放在項目中的這種使用狀況，這就很是棘手了。由於不太容易肯定使用的開源軟件版本，甚至若是當時的開發走了，都沒法肯定系統中使用了哪些開源軟件，哪些代碼是自研的，哪些是第三方的代碼。

侵入式修改和整包引用

對於直接把第三方源碼下載下來在自研代碼中使用的行爲，通常定義爲侵入式修改。而與之對應的，把開源代碼包下載下來（或源碼編譯成包），不作修改，經過接口調用方式來使用的行爲，通常定義爲整包引用。通常來講，更推薦整包引用的方式來使用第三方項目。

整包引用有以下優勢：

1.能夠很是明確地知道當前系統中使用了哪些第三方代碼，方便判斷系統中是否存在第三方漏洞；

2.若是須要修改第三方代碼，可使用補丁方式進行修改，能較好地進行第三方代碼以及補丁的維護工做；若是須要升級第三方代碼，只須要把自研補丁進行適配便可，而侵入式修改可就難升級了。

3.能夠更清晰地知道哪些代碼由於使用了第三方代碼須要被動開源，減小法務風險。

固然整包引用的缺點就是開發成本高，原本能夠複製粘貼解決的問題，如今須要將整個代碼包引入。而且，若是須要對第三方代碼進行修改，還要使用補丁方式，很大程度上下降了代碼可讀性。

第三方代碼侵入式修改清理

若是不是整包引用的方式使用第三方代碼，就會存在我上面說到的不少問題，特別是漏洞識別和法務風險。業界有不少工具能夠進行代碼掃描，從而檢測系統中是否有對第三方代碼的片斷引用，如fossid和fossbot。通常掃描完成後，咱們須要將肯定是使用了第三方代碼的代碼段進行清理，改成整包引用第三方代碼包的方式來使用。若是引用的代碼段較少，直接將引用的代碼從新寫一份，替換掉原來的第三方代碼也能夠。

結尾

幸運的是，我使用的kafka框架發佈了一個修改了我此次遇到的這個bug的一個版本，我能夠直接用這個版本的包，編譯以後就可使用了。可是我能夠這樣作是由於公司沒有限制使用此軟件的版本，正常來講，公司會對全部用到的第三方軟件版本進行限制。若是限制了使用版本，那麼我則須要把kafka的源碼下載下來，而後使用補丁將此漏洞自行修復，而後再編譯成包在系統中使用。