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