科技雲報導原創。
在開源成為全球趨勢的今天，搶跑科技創新的金融機構成為開源技術的重度用戶。然而，由於我國金融機構對開源軟體的管理尚不完善，不具備較成熟的開源治理體系，金融機構在引入和管理開源軟體時總會遇到種種困難，這也帶來了一定程度的開源風險。
對於緊跟開源技術趨勢的金融機構而言，哪些開源軟體適合自身業務已經不再是問題，他們更加關心的是如何解決業務中的實際問題，例如：
銀行應如何構建開源軟體管理體系？開源軟體安全治理的最佳實踐是什麼？如何實現開源商業化？開源項目的評價標準是什麼？金融行業開源技術框架的管理方法和案例實踐有哪些？金融機構如何使用MySQL？金融機構如何參與和貢獻開源？構建金融開源生態圈的可行性有多大？
為了解決這些普遍性的行業痛點，一群來自金融行業的技術專家提出了一個大膽的想法：如果沒有答案，那我們就自己去尋找合適的行業方案。
2018年，一個略顯神秘和低調的金融行業組織形成了。這個最初由中國信通院聯合浦發銀行、農業銀行、興業銀行、中信銀行、人壽保險、太平洋保險等10餘家金融機構共同發起的「金融行業開源技術應用社區」（FINOC），首次開啟了國內金融行業對開源技術應用的自我探索之路。
有趣的是，不同於人們所熟知的金融科技類聯盟，這個「金融開源社區」有兩大特點：一是不收會費；二是每隔1-2個月社區就會發起研討會，而且每次研討必會輸出乾貨。
更為社區成員們津津樂道的是，研討會有一個必不可少的環節——「吐槽大會」，這也成為金融機構專家與同行們探討困擾已久的難題、吸取同業機構實踐經驗的一次絕佳機會。
成立兩年以來，「金融開源社區」在毫無推廣、只憑口口相傳的自然發酵下，如今已經吸引了35家頭部金融機構、8家知名科技公司、多位獨立技術專家的共同加入。這種對金融機構實際痛點的精準覆蓋、高頻次的行業乾貨輸出，讓「金融開源社區」在行業內名聲大振。
2020年12月中旬，「金融開源社區」在中國信通院的牽頭下舉辦了第15次線上研討會活動，研討主題是「開源組件安全問題與升級方式」。
在長達2.5小時的激烈討論中，來自浦發銀行、農業銀行、中國銀行、上海銀行、微眾銀行、寧波銀行、海通證券等多家金融機構的技術負責人，以及稜鏡七彩、新思科技、默安科技、奇安信等多家技術廠商的專家們，又一次在「吐槽大會」中碰撞出精彩紛呈的觀點。
這一次關於「開源組件安全問題與升級方式」的話題，反映了金融機構哪些普遍性的痛點？不同規模和性質的金融機構，又是如何在自己的實際業務中去解決開源升級和安全的問題？
為了讓更多金融機構和科技廠商能夠深入了解這一問題，本文整理了此次研討會的乾貨內容。以下為「金融行業開源技術應用社區研討會：開源組件安全問題與升級方式」實錄精編。
問題一：開源組件存在升級後由於再次披露漏洞需要頻繁升級，影響業務運轉，有沒有解決方案？
開源組件升級是一個不可避免的事實，由於升級框架或組件，往往會導致兼容性或安全問題。由於各個金融機構的應用與漏洞情況不同，行業內並沒有通用的解決方案。對於這一問題，多位技術專家給出了自己的看法，我們將其總結為六個方向的解決方案：
一、安全檢測「左移」
微眾銀行開源管理辦公室 鍾燕清：這個問題沒有一步到位的快捷方法，儘量在開發早期就執行安全檢測，形成「黑白名單」。在開發過程中，對開源引用情況、漏洞解決方案、安全評估、組件版本等都要有詳細的記錄，在整個DevOps過程中形成嚴格的漏洞控制追蹤流程，並給予強制+建議性的安全措施。
此外，要培養開發人員的安全意識，讓所有開發人員都既有意識，也有可用的工具，具備專業的能力來做這件事。
中國信通院開源專家 俊哲：安全檢測「左移」，就是要在開發早期就執行安全檢測；如果發現了安全問題，那麼選擇安全版本時，可選取最新的穩定版，並建立開源資產清單，以便持續跟蹤。
二、先評估後整改
中國銀行信息科技運營中心 李維銀：「先評估後整改」，即對漏洞的危害程度進行評估，再根據漏洞等級採取相應的修復措施。目前，我行採用了很多自動化工具，如果修復漏洞要改動配置，也會同步修改自動化腳本，以解決隱患。
農業銀行研發中心信息安全與風險管理部 姜曉璇：最終目標如果是「消滅漏洞「會比較困難，最好還是採取降低漏洞數據的策略，按比例修復漏洞，這樣可操作性比較大，開發人員也有選擇餘地。
如果兼容性允許，就升級到安全的版本；如果兼容性不允許，那就升級到漏洞數量比較少的版本，先解決存量開源組件的問題。對於增量開源組件，則直接使用安全策略，嵌入Devops流程。
隨著時間的增長，這種循環上升的態勢，應該能達到更好的效果。
中國信通院開源專家 俊哲：若評估漏洞風險對系統的影響情況較小，可以考慮不採取措施，但要記錄在案。
若評估漏洞風險對系統安全性影響較大，但因為業務連續性要求，導致難以承受升級帶來的系統兼容性風險，則可以考慮是否有漏洞風險的緩解措施可以使用，如：增加或修改安全配置、臨時禁用受影響的功能等。但緩解措施宜作為臨時處置方案，最終還是要升級到安全版本，從而從根本上修復漏洞。
有些情況下可能沒有適用的緩解措施，需要通過升級才修復高風險漏洞。在選擇升級版本時不宜簡單的選擇最新的版本，最好是選擇與當前所使用版本兼容的補丁版本或者版本號接近的安全版本。
有可能存在升級版本就會有兼容性問題的情況，由於開源軟體原始碼可公開獲得，可以考慮自己在使用的版本上，通過修改原始碼來修復漏洞，從而自己來保證兼容性。
三、先可知再可控
新思科技專家：提高項目的透明度，不管在開發還是測試環節，版本漏洞、漏洞嚴重情況等，都要能清楚的看見和管理。例如，漏洞有沒有影響到代碼，要進行快速判斷。即使是中高危漏洞，也不一定都會影響代碼。因此，除了透明度，還要提高評估的效率。
目前，我們會在產品中提供實時通知，對漏洞影響到現有版本提供動態監控，以工程化的手段，將開源組件版本的安全從前到後管理起來。
稜鏡七彩專家：由於企業應用程式、運行環境的不同，在漏洞修復時的策略也不一樣。例如：針對存量系統，應用程式的組件有安全問題，就需要跨部門協作。而增量系統，遇到大的開源組件有補丁，則通過治理工具或者外部安全服務進行管控和運維。
先可知再可控，就是要根據不同的環境、場景，詳細了解每個版本的情況，再提供更全面的治理工具。
管理規範性和機制常態化技術專家項曙明：開源管得不好，企業會增加管理成本，風險更大。因此，企業應構建快速發現和治理開源風險的能力，從管理機制、工具和培訓三個方面共同構建常態化的機制。
首先，從管理的規範性看，如何引入開原始碼、如何管理代碼，都應該從企業層面制定符合企業本身的開源漏洞治理方案，不要把修復漏洞的責任與義務全部附加給程式設計師。
其次，要約束項目組的用法，如：代碼治理、許可證治理等。儘量不要源碼引用，如果源碼引用，那就儘量對代碼進行解耦，以降低風險。
除了日常使用漏洞掃描工具、治理工具進行管理，出了問題有沒有能力快速應對？企業需要構建和檢驗自己快速應對風險的能力。
五、與社區聯動
微眾銀行開源管理辦公室鍾燕清：目前，我們在內部形成了小的組件社區，專門跟蹤開源社區、關注開源漏洞問題，並由內部專家進行維護，以保證系統的高可用性、低成本、快速升級；同時，我們也會對重要的組件做封裝，以達到升級時應用無感。
技術委員會成員專家 項曙明：企業應積極將發現的漏洞和代碼貢獻到開源社區，及時跟進社區的進度，並從社區得到反饋，這樣對企業了解自身開源風險其實是非常有益的。
新思科技專家：企業需要和社區形成緊密關聯，並指派專家參與到開源社區的活動中，和社區形成良性的互動，更好的應對開源組件的的風險。
六、自動化工具
技術委員會成員專家 史少鋒：大型企業一定要成立專門的安全小組，採用自動化工具來掃描和管理各類開源組件，一方面減少人力投入提高效率，另一方面及時告知，以降低安全風險。例如OWASP的 Dependency Track 項目就可以幫助自動化監測統計依賴變化以及各種安全漏洞。
問題二：除了升級，開源漏洞還有什麼解決辦法？
一、專業化漏洞研究團隊
中國信通院開源專家 俊哲：開源組件漏洞修復，絕大部分是通過升級解決的，建議升級到距離當前版本沒有漏洞的最接近的版本進行升級，這樣兼容性較好。
如果有特殊組件無法通過升級解決，需要專業化漏洞研究團隊，針對特定組件漏洞進行特定修復，這樣成本比較大。
奇安信專家：企業內部漏洞數量特別大的情況下，需要識別是否是企業內最應該修復的漏洞，需要收集已經POC的漏洞。此外，奇安信有專門的漏洞防護小組和分析報告，可以提供大型的漏洞分析和建議。
如果是社區已經不維護的組件出現漏洞，那就需要找專業漏洞挖掘團隊，專門去打補丁。
二、查看不同的漏洞庫
新思科技專家：不同的角色針對同一個安全漏洞可以通過不同的視角去查看漏洞的信息（CVE、CWE、CAPEC等）來協助判斷和評估漏洞的風險等級。
三、修改原始碼
農業銀行研發中心信息安全與風險管理部 姜曉璇：除了升級，還可以通過修改原始碼修復漏洞，但是需要注意代碼的改動量，修改量大的話容易無法持續監控。
問題三：一個組件的處置會涉及到依賴組件的同步升級， 如何處理？
新思科技專家：組件的直接與間接依賴，與漏洞是否需要修復沒有直接關係，需要考慮整個函數調用鏈路是否被觸發，如果被觸發需要有限考慮修復。當然，這需要整個項目部門合作、組件開發過程透明，理清組件之間的關係。
農業銀行研發中心信息安全與風險管理部 姜曉璇：攻擊鏈路很可能是通過間接組件發生的，這個常常會被大家忽略。希望能有安全工具，可以提供間接依賴組件的漏洞修復措施。
問題四：系統因漏洞升級主框架要重新做測試，導致運維工作量巨大涉及系統廣，配合度跟不上，這種情況如何解決？
中國信通院開源專家 俊哲：先評估該漏洞是否有緩解措施可以使用，若有緩解措施使用，可以在保持業務連續性的基礎上，為升級測試爭取更多的時間。若沒有緩解措施，也可考慮自己修改源碼進行漏洞修復。
如果經過評估該框架已經產生副作用，在系統依賴關係不緊密的情況下可以直接棄用。
問題五：有些高版本的組件，依賴高版本的JDK環境，一旦升級JDK，很可能整個項目代碼都得重構，修復代價非常大，這種情況是否有修復辦法？
默安科技專家：針對這種情況，可以對在用組件版本的原始碼進行修改後再重新打包，從而避免升級JDK。
問題六：在開源產業鏈條中，是否有專門針對熱門組件的商業化安全服務？
中國信通院開源專家 俊哲：目前有商業化公司針對熱門開源軟體的一些商業化服務，包括部署、安裝、運維等，針對開源組件，也可以向開源治理廠商訂閱商業化服務，如威脅情報、安全版本推薦、修復建議等。
上海銀行信息技術部 鄭位威：安全廠商的確會提供漏洞掃描報告PDF，內容包括威脅情報、安全版本推薦、修復建議等，但這都是一些通過做法，並沒有針對企業的實際情況，給出實際的落地方案。業內缺乏既懂安全，又懂技術的複合型人才，解決實際問題的商業方案也很少。
海通證券開發中心平臺部 周靖：建議廠商針對主流開發框架（例如Springboot2.x系列，熱門組件）定製安全版本，基本上能覆蓋日常 70%以上的常規安全漏洞和功能設計漏洞，剩下不多的漏洞則由企業根據自身特點進行定製化積累，將安全融合在框架、組件中。
除了針對以上話題展開了激烈討論，此次研討會還根據之前在金融開源社區內的調研，將大家反饋問題最多、升級代價比較大的組件版本，進行了展示和討論。
由於時間的限制，還有多個金融專家們關注的議題尚未得到充分討論，例如：什麼樣的流程與制度，可以讓安全部門與開發部門之間良好協作？如何衡量開源安全治理的好不好，工具與度量指標是什麼？
相信在這場意猶未盡的金融行業「吐槽大會」之後，技術專家們還將繼續各自的思考與實踐，並滿心期待下一次的江湖再見。
（免責聲明：此文內容為第三方自媒體作者發布的觀察或評論性文章，所有文字和圖片版權歸作者所有，且僅代表作者個人觀點，與極客網無關。文章僅供讀者參考，並請自行核實相關內容。投訴郵箱：editor@fromgeek.com）
來源：科技雲報導