作者簡介：劉志誠，樂信集團信息安全中心總監、OWASP廣東區域負責人、網安加社區特聘專家。專注于企業數字化過程中網絡空間安全風險治理，對大數據、人工智能、區塊鍊等新技術在金融風險治理領域的應用，以及新技術帶來的技術風險治理方面擁有豐富的理論和相關經驗。

關于軟件供應鍊的理論，方法，模型以及普及性文章已經汗牛充棟，我個人也在至少3個場合，3篇文章進行過觀點，立場的表達和闡述。網安加社區的這篇約稿，我就從深入實踐的角度重新梳理一下自己認為存在普遍誤區和難題尚未突破的領域進行一次剖析，希望能給同仁們帶來一些啟發與思考。

我重點要談及的涉及到4個領域。

一是商業系統、軟件、組件，這是信息化時代，企業信息化系統的主流獲取方式，即使在數字化轉型呼聲此起彼伏的當下，對傳統行業而言，這仍是占據最大份額的信息系統實現方式。數字化原生企業或數字化轉型比較充分的企業，一些基礎的管理功能，非關鍵支撐系統以及底層信息化基礎設施，仍是難以繞開的信息化系統實現方式之一。

二是開源系統、軟件與組件，數字化時代信息化需求的複雜性，多樣性和易變性，催生了璀璨星辰般的創業企業，創業資源的整合需要生态的協同，開源模式不僅是單向的公益輸出，同樣是在社區汲取衆包資源，豐富産品能力的關鍵渠道，但開源軟件研發組織協同模式的松散性，目标的不确定性，商業價值的利益驅動，帶來更多的風險和問題。

三是移動互聯網時代APP的第三方SDK與服務，移動互聯網已經屬于一個進入中老年的詞彙，其實其崛起也就十幾年的時間，技術的演進和變遷，融合了微服務的理念，集成第三方SDK和服務時，重視了功能的協同，忽視了體系化的治理和管理，在《個人信息保護法》《數據保護法》密集出台的合規背景下，安全和隐私保護風險日益突出。

四是遺留遺棄系統，信息技術的更新換代周期極快，随着業務需求的頻繁變更，以DevOps為主流的敏捷交付模式，新系統，新功能上線，因業務變更，技術變更，一些系統被廢棄，但由于下線流程不規範，不标準，存在資源回收，業務面暴露等風險，對一些因零星業務需求未下線的系統，缺少維護資源，或商業軟件已經喪失了商業服務的相關保障。上述四個領域在軟件供應鍊安全中，存在的風險，需要的控制措施，在安全意識教育和管理流程的落實上，存在差異，不同企業不同安全團隊與技術團隊業務團隊協作的背景，模式不同，容易顧此失彼，給企業帶來額外的風險。

商業軟件一般而言是具有供應商，持續更新，處理和解決安全問題，有相應的合同通過服務水平協議（SLA）保障軟件的安全屬性，由供應商承擔相應責任。當然，相對于已經過了服務期，或不在供應商服務，保障範圍的軟件和曆史遺留系統，歸屬于遺留和遺棄系統處置。

理想的商業軟件是具備完善的産品研發安全管理的，所發布的軟件在軟件開發周期安全管理流程（S-SDLC）中需求階段進行了風險評估，設計階段進行了安全能力集成，研發階段進行了代碼、集成的安全測試，在客戶側部署和提供雲服務時，具備安全的預防能力建設，配置了相應的安全保障策略，支持客戶在安全檢測和監測過程中安全預警的應急響應和服務，承擔相應的安全責任，轉移客戶的相關安全風險。當然，現實環境中商業軟件企業要麼疏于安全的研發管理，要麼缺乏安全的研發管理能力，要麼因部署實施人員意識和能力不足，導緻的商業軟件帶傷帶病上線。

在個人實踐經驗中，某以移動設備安全管理（MDM）出名的國内廠商在檢測中發現6項以上高危漏洞，修複、響應，整改不及時，國外大廠Oracle 的ESB存在明文傳輸密碼的低級漏洞，還以整改需求屬于商業開發為由要挾付費整改，并且不支持SSL協議部署的補償方案，讓人大跌眼鏡。當然，在國家攻防演練活動中，頻繁曝出安全漏洞的廠商所犯的同樣是一些低級問題，是在研發過程安全管理階段流程、能力和意識缺失所帶來的安全風險。

因此，企業在采購商業軟件時，需要增加供應商安全能力評估的環節，作為采購的依據，在采購合同中明确供應商的安全義務與責任，避免在采購完成，部署，運營過程中的責任不清，響應不到位，整改不及時，責任不承擔的被動局面。實踐中，對供應商的評估包括能力評估，過程評估，可信評估以及明确的安全責任條款響應與合同約束，做到安全的一票否決權。

開源軟件的起因，背景，目的和運作模式差别巨大，供應商的能力，資質，目的和意願、承擔的責任和義務各不相同。同時，不同企業采用開源軟件的目的，目标，使用方式，也和業務的目标，目的，以及在開源軟件自身的貢獻和投入上的目的，目标也不相同，複雜性要遠遠超過商業軟件的範疇。軟件産品類的企業在采用開源軟件、組件時，除了關注安全風險外，還要關注相關的許可證協議，商業用途的責任和風險，這也是一些軟件成分分析（SCA）廠商的賣點之一，本文重點在于探讨安全風險的評估與治理，這部分就不再贅述。

單一性的業務應用系統因團隊的規模，以及業務的複雜度，開源組件的治理尚不複雜，但對多業務團隊，多應用系統，分布式開發團隊或敏捷開發團隊的模式下，如果缺少開源組件引入，應用，生命周期管理的體系化和統一化，會帶來治理的複雜性。某業界的朋友在存量開源組件治理過程中，幾百個開源組件涉及到幾千個研發工程，因企業未做組件的引入管控流程，整改安全風險過程，付出了極大的代價。

企業的架構委員會或者開源組件治理委員會，需要建立開源組件的引入評審機制，任何開源組件的引入需求，需要對開源組件進行可用性安全評估，包括開源項目的背景，主要貢獻企業，主要貢獻團隊，項目的目的，團隊的穩定性，版本發布的穩定性，應用的普及性，和用戶評價的可用性，對組件的架構，安全機制，管理機制，路線圖進行評審，全面确認與企業場景的匹配性，開源組件的可用性，可持續性，延續性和兼容性。建立可信制品庫，作為企業開源組件的唯一可信來源，對于開源組件的二次開發與修改，必須建立在企業的基礎上評估評價與實施，為安全漏洞的修訂和整改奠定基礎，避免版本、二次開發帶來的複雜性和安全風險。

目前市場的開源組件的安全治理主要集中在問題的發現環節，由于開源軟件的種類繁多，長尾效應，開源組件安全廠商難以實現窮舉的開源組件安全漏洞的驗證，也難以實現基于場景的代碼級修複建議，這個工作并未做到閉環。開源軟件由于供應商缺少義務約束，可能已經不再更新和修複漏洞的版本，難以實現風險的降低，而企業也有可能因為自定義的二次開發而難以直接升級開源項目的新版本，而缺少POC的驗證以及代碼級修複建議，其評級機制和安全修複安全團隊都需要面對研發團隊的質疑和挑戰。因此，開源組件的安全修複是目前難以逾越的鴻溝和面對的具體困難。

如何實現開源組件的安全修複，我跟主流的SCA廠商以及第三方運營SRC都有過些探讨，解決長尾問題的路徑包括，以行業特征為主的開源組件漏洞POC驗證能力和代碼級修複的訂閱服務，每個行業通過對TOP20企業的支持，基本可以涵蓋80%的開源軟件漏洞修複，20%可以提供以人力支撐為主的增值服務，而開源組件安全廠商在這個過程中可以建立自己的先發優勢和知識庫門檻。對于初始開源組件POC驗證和代碼級修複可以通過開源項目或運營SRC衆籌方式建立。可惜，至今為止，行動頗為有限。

APP在移動互聯網的價值和面臨的挑戰一直是數字化繞不開的話題，APP的下載和推廣成本日漸增多，小程序和H5在業務快速推廣，快速應用方面具有優勢，但在業務發展到一定階段後，平台制約和入口痛點往往繞不開回歸APP的話題，用戶終端環境的驗證，用戶的定位以及環境，行為數據的采集，在面對國家合規需求，用戶知情同意等一些列要求下夾縫中生存，在合規與業務需求之間尋找平衡。而在廣告，引流，終端能力方面具有優勢的第三方SDK，是APP快速開發，滿足業務需求的必備前提。不能忽略的是，第三方SDK是個雙刃劍，在滿足業務需求的同時，也帶來業務合規的風險。在網信辦牽頭下的APP安全治理逐漸深化，第三方SDK的合規與整改通報也經常見諸報端。這就要求企業對第三方SDK建立評估，管控和處置的生命周期管理能力。

某朋友的企業出現不同業務APP集成不同第三方SDK版本引起的研發流程變更的效率問題和APP研發第三方SDK基線評估和建立的問題。在這點上第三方SDK的引入評估與商業軟件管理一緻，做好引入的管理和控制，在第三方SDK的管理上需要借鑒開源組件的治理，建立統一的制品庫和統一的安全基線，避免重複引入風險安全組件的問題。

第三方SDK的隐私保護檢測和動态運行時監測的能力是容易忽略的點，這有别于傳統意義上的靜态檢測，第三方SDK後台服務涉及到動态的數據采集和處理，需要能夠及時的監測，避免違規風險。

業務下線是業務生命周期過程中的一環，軟件下線是軟件生命周期中關鍵的一環，兩者之間存在着密切的相關性，也有着具體差異，不同企業可能有不同的流程制度或不同的文化，不同的團隊支撐實現，而其中因協同不足，經驗能力不足造成的問題也不容小觑。

某朋友企業的業務下線和系統下線，基于約定俗成的敏捷模式，缺少标準化的流程和驗證機制，導緻下線系統僅下線域名解析，對軟件系統的服務停止，硬件資源回收，數據存檔和備份，缺少相應的流程和機制。而長期暴露在内網範圍内，因域名解析配置的問題，某些微服務架構在互聯網環境下可以通過域名拼接訪問，造成了相應的攻擊面暴露風險。

當然，上述例子涉及到的檢測、治理、驗證模式衆多，如果具備資産管理系統，具備流量分析與監控系統，具備資産暴露面的檢測與監測系統，都能實現問題的發現與控制措施的變更，本文僅從軟件供應鍊安全的角度，對遺留和遺棄軟件的治理，給出相應的解決方案。

需要建立完善的業務下線流程，其中涉及到的軟件系統需要從數據歸檔，資源釋放，服務下線的完整流程建立執行的審核，檢查，驗證機制，避免遺棄系統帶來的資源浪費和安全風險。

遺留系統因曆史原因，業務仍有零星需求不能下線，軟件系統因資源問題以及服務周期問題，難以對安全風險進行規制的響應和升級，這對安全團隊而言是比較大的考驗，補償措施和風險接受，以及應用級的行為檢測和響應，規避安全風險，可能是比較可行的方法。

軟件供應鍊安全作為當下的熱門領域，相應的方法論，理論研究和探讨，安全産品層出不窮，而場景化的需求決定能夠發現，解決，和管理相應的問題和風險，帶來實際價值才是選擇的唯一标準。作為安全團隊的負責人或軟件供應鍊安全的負責人需要在功能滿足和能力建設的基礎上，關注運營需求，不斷發現實踐過程中的不足和問題，深入思考，給出具有前瞻性和全局性的解決方案，本文給出一些容易疏忽和忽略的具體點，供大家參考，也希望能帶來一些啟發和幫助，促進軟件供應鍊安全領域的發展。

- End -

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!