云原生場景下軟件供應鏈風險治理技術淺談

于近日舉辦的CCF TF第61期交流活動，主題為開發安全與軟件供應鏈安全，特別邀請懸鏡安全創始人&CEO子芽發表演講。子芽憑借自身對行業的敏銳洞察以及懸鏡在相關領域的技術創新和實踐經驗，與CCF TF安全SIG主席&北京賽博英杰科技有限公司董事長譚曉生及其他嘉賓對軟件供應鏈風險治理進行了深度探討。

當下，云原生技術正驅動著產業數字化轉型進程不斷加速，由云原生和開源帶來的下一代軟件供應鏈安全正面臨新的挑戰。如何使開發的軟件更為安全，如何保障軟件供應鏈安全，是全球關注的焦點。

基于這樣的大背景，子芽以“云原生場景下軟件供應鏈風險治理技術淺談”為主題，詳細闡明了軟件供應鏈風險治理流程以及自動化智能化工具鏈——懸鏡安全原創專利級代碼疫苗和積極防御技術。

云原生時代面臨的應用安全風險

數字化時代，對于軟件應用有三個安全共識：

1. 數字化應用正成為社會運轉的基本組件。數字化時代，一切皆可編程，軟件定義萬物。軟件已然成為新一代信息技術的靈魂。

2. 現代軟件都是組裝的而非純自研。近5年，開源代碼在現代應用中所占比例由40%增至78%-90%。混源開發成為主要模式，軟件供應鏈安全威脅日趨嚴峻。

3. 代碼一定有未被發現的安全漏洞。平均每千行代碼就會出現2-40個邏輯性缺陷。缺陷是天生的，漏洞是必然的。

軟件供應鏈泛指一家企業和組織開展數字化業務所依賴的軟件，包括研發、運營、供應等各項活動所依賴的軟件以及與軟件評估、生產、分發等相關的任何活動，主要包括三個方面：軟件開發方（供應商/上游）、軟件供應方（供應商及運營服務商/中間）、軟件使用方（消費者/下游）。

在云原生時代，軟件供應鏈技術發生了躍遷式的演進，相較以往，有4處不同。

第一個是新制品，即軟件成分從傳統的閉源到混源再到以開源為主導；

第二個是新發布，即開發過程不斷升級，從傳統的瀑布式到敏捷再到當下DevOps研運一體化；

第三個是新技術，即數字化應用架構從早期的單體應用到SOA（Service-Oriented Architecture，面向服務的架構）再到微服務；

第四個是新環境，即數字化基礎設施從IDC物理機到虛擬化再到容器化。

伴隨這些演進而來的是新的安全風險。在敏捷業務交付的背景下，由于開源軟件的廣泛使用，微服務應用本身安全漏洞逐漸積累。新的基礎設施引入新的防護對象，比如云原生場景下的鏡像風險、微服務運行風險、基礎設施風險、網絡安全風險，其中微服務風險主要與數字化應用息息相關，包括通用漏洞、業務邏輯漏洞、異常行為代碼、微服務框架漏洞、微服務開源組件漏洞等。

近年來，軟件供應鏈攻擊事件頻發，風險涉及開源軟件漏洞、開源工具被污染、廠商預留后門、升級劫持、惡意軟件、源代碼污染、開發環境漏洞等。尤其是去年爆發的Log4j2.x核彈級漏洞，至今回想起來仍令人記憶猶新。

通過對這些事件進行梳理總結，可將整個軟件供應鏈的主要安全風險分為三個階段：軟件開發環節、軟件供應環節和軟件使用環節。每個環節都有相對應的安全痛點。

在開發環節，存在引用的組件攜帶漏洞、異常行為代碼或者后門，引入的開發工具、DevOps平臺和環境缺少管控以及開發人員安全意識薄弱等情況。值得一提的是，去年RSAC創新沙盒大賽的全球總冠軍Apiiro公司主要解決的就是開發環境中的供應鏈安全問題，這些風險不但來自應用本身，而且還源于環境和人員。

在供應環節，外包開發/外采過程中，沒有對交付的軟件進行安全規范，沒有提供安全保障措施，就會產生軟件供應鏈安全風險。在使用環節即常態化運營環節中也存在第三方組件漏洞等安全問題。

因而需要將軟件供應鏈看作一個整體，進行綜合的風險治理。

軟件供應鏈源頭的開源風險治理實踐

前面提到軟件開發方式從閉源到混源再到開源驅動，隨著開發方式的演進，數字化應用安全風險面除了傳統的Web通用漏洞、業務邏輯漏洞以外，還增加了開源成分的缺陷及后門、后門惡意代碼。

整個供應鏈上下游的軟件分為商采、開源和免費三種，因而開源風險治理自然成了整個軟件供應鏈安全保障的關鍵點之一。

開源風險治理存在四大痛點：

1. 看不清：無法清楚得知在數字化業務運行過程中動態加載被使用的組件數量和種類。

2. 摸不透：無法清楚得知開源軟件中真實可被利用的中高危漏洞的數量。

3.跟不上：受限于漏洞情報，無法準確確定開源軟件漏洞真實影響的范圍。

4. 防不住：無法對未知漏洞進行提前的積極防御。

建立規范的開源治理體系能有效解決以上痛點。第一步，統一開源組件的引入入口及流程規范，把控源頭；第二步，檢測和梳理資產，生成詳細的SBOM（軟件物料清單）；第三步，分批整改，引入代碼疫苗技術，幫助應用本身獲得威脅免疫能力，實現對外部威脅的積極防御；第四步也是核心，要以人為本，對整個IT過程中相關人員的安全素養進行賦能。

從SDLC軟件開發全生命周期的角度看，從編碼、構建、測試一直到運營階段的安全管理，開源風險治理乃至整個軟件供應鏈風險治理的核心是既要實現“安全左移”，從源頭做治理，又要在云原生場景下實現“敏捷右移”，要求安全措施、安全技術覆蓋云原生場景下的典型基礎設施和應用。

圖2 軟件供應鏈風險治理既要“安全左移”又要“敏捷右移”

眾所周知，于去年年底爆發的Log4j2.x遠程代碼執行漏洞堪稱核彈級漏洞。由于它屬于Javay語言生態基礎庫的高危漏洞，而基礎庫的相互引用影響是指數級的，粗略統計，70%左右的Java應用受到影響。而且該漏洞觸發無前置條件，攻擊者可以通過它輕松實現遠程代碼執行。

這類漏洞的爆發引發了業內對軟件供應鏈風險治理的深度思考。首先需要加強對源頭的檢測，在編碼、構建、測試等環節，通過自動化的安全能力比如IAST和SCA，對數字化應用進行持續檢測；其次，不同于早期的原生應用，需要通過代碼疫苗技術使應用自我防御一些未知漏洞，實現應用的出廠自免疫；第三，在常態化運營階段，需要結合漏洞情報能力和配套的管理措施，確保軟件物料清單的動態更新，實時掌握制品庫的詳細情況和安全體系的構筑能力。

代碼疫苗技術的進化之路

介紹懸鏡原創專利級的代碼疫苗技術之前，不得不先提及網絡安全的三次關鍵演進。

第一次演進是指網絡邊界過濾分析技術，比如傳統的防火墻、WAF等，作用在網絡層，優勢在于部署交付過程相對便捷，但是對外部威脅的洞察是粗粒度的。

第二次演進是指主機環境環境檢測響應技術，比如EDR等，能夠對應用或者外部異常行為進行細粒度的捕捉、分析和溯源，但是無法在云原生場景下，在容器化環境與基于微服務的應用架構下，對加密流量或者微服務中的應用流量進行實時的洞察和分析,所以催生了第三次演進，即應用運行時情境感知技術，也就是代碼疫苗技術。

代碼疫苗技術不僅善于解決對外部入侵威脅“看不見、看不清”的問題，實現內生積極防御，而且能實時捕捉應用運行時情境感知的上下文，并且不會對整個策略產生過多的維護成本。更為重要的一點在于，代碼疫苗技術能結合SCA軟件成分分析技術，實時分析數字化應用中的第三方開源成分，從而實現對重大組件漏洞的提前防御。

代碼疫苗技術經歷了一個演進過程。早在2012年和2014年，代碼疫苗技術中的IAST和RASP就分別被提出。起初，代碼疫苗技術受限于其核心單探針技術對應用性能和兼容性的影響，因而并沒有在業內形成推廣之勢。懸鏡之所以能在代碼疫苗技術方面取得成功，是由于隨著DevOps的逐漸興起，我們先在研發測試環境中將IAST探針打磨成熟，使之能支撐百萬級的高并發應用場景，在此基礎上再去拓展它的積極防御能力，這是一個循序漸進的進化過程。所以懸鏡當下所掌握的代碼疫苗技術，它的核心探針既能實現IAST灰盒安全測試能力，也能實現API挖掘分析能力，還能實現RASP的自適應出廠免疫能力和運營時的敏感數據追蹤能力。

代碼疫苗技術的核心分為兩個部分，一個是IAST交互式安全測試能力，另一個是RASP的積極防御能力。

其中IAST交互式安全測試又分為狹義和廣義兩種。狹義的IAST特指運行時動態插樁技術，主要包括被動的動態污點追蹤和主動的交互式缺陷定位。廣義的IAST主要包含流量學習和日志分析，在此基礎上對數據進行重放和分析，進而能定位漏洞所在位置。相較于傳統的白盒和黑盒技術，IAST這種灰盒技術具有非常大的優勢，善于精準識別和分析API、分析第三方開源成分以及精準追蹤動態敏感數據。

RASP的核心在于輕量級的探針、統一的管控平臺和配套的積極防御插件。第一，它能幫助應對重大未知威脅或典型威脅，使應用實現出廠免疫；第二，具備熱補丁功能，對動態發生的部分組件漏洞進行修復；第三，在云原生場景下，對微服務應用上下文進行捕捉和分析；第四，對攻擊來源回溯。

總而言之，相較于傳統的WAF和EDR，RASP具有以下幾大核心優勢：對未知漏洞的防御；對第三方組件漏洞的防御；對框架組件漏洞的防御；對WebShell的防御。

基于代碼疫苗技術的應用風險管理是一個閉環，在每個環節都具備對應的能力，如漏洞發現、漏洞驗證、漏洞分發和漏洞修復，能很好地結合IAST和RASP，在DevOps敏態環境下適應業務的快速交付。

代碼疫苗技術能將自身的灰盒安全測試能力、第三方的開源成分掃描能力以及RASP積極防御能力對SDL不同環節進行精準覆蓋。

結合整個軟件供應鏈全流程風險治理框架來看，在框架的每個環節都可以通過融入核心的自動化技術和配套的安全服務規范，形成高效的解決方案。

DevSecOps敏捷安全技術演進趨勢

IDC發布的云原生安全熱點技術相關報告將DevSecOps判定為變革型技術，且處于上升期。前文提到的云原生時代四大新變化，其中開發方式的變化以及應用架構的變化，都是以DevSecOps為主要推動力。

懸鏡曾與甲方用戶深度探討，在云原生安全構建過程中，究竟是以容器安全技術為主導，還是以DevSecOps安全技術作為支撐。在最終落地探索過程中，我們發現還是得依靠DevSecOps安全技術和相關安全廠商的支持，來形成整個方案的主體部分。

DevSecOps的核心是如何在DevOps研運一體化的各個階段嵌入安全，主要包含四大要素：組織、流程、技術和文化。

實際落地DevSecOps的過程主要分為三個階段。在第一個階段，要確保數字化應用在安全左移的過程中不存在中高危漏洞，或者漏洞能被快速捕捉和修復。在第二個階段需要建立體系，包括SDL安全開發賦能平臺、左移情境式威脅建模工具和配套的咨詢服務。在第三個階段，需要加入安全度量，只有通過度量才能明確持續改進的方向，此外在云原生場景下進行敏捷右移需要關注整個體系的安全運營效果，而BAS技術正是與之相關的關鍵技術，它能通過持續威脅模擬對現有防御體系進行持續驗證，度量其有效性。BAS可以和代碼疫苗技術的RASP形成內外聯動，初步搭建起積極防御體系。

DevSecOps敏捷安全技術是不斷發展的。懸鏡每年都會在自己舉辦的DevSecOps大會上發布DevSecOps敏捷安全技術金字塔，為該賽道指出技術未來演進方向。

圖3 DevSecOps敏捷安全技術金字塔V2.0版

懸鏡通過市場觀察和實踐發現，BAS目前只停留在頭部企業探索實踐階段，而IAST、容器安全和OSS/SCA，需求和建設程度都是相對比較靠前。金字塔往上具有一定深度的安全能力，比如RASP，能結合端點安全技術實現對整個護網場景中“最后一公里”的實時防御。此外RASP能與IAST、BAS綜合聯動，形成積極防御體系。而API Fuzz技術，雖說多年前便已被提出，但目前仍具有局限性，第一是其挖掘未知漏洞的能力仍有待商榷，第二是使用門檻較高，需要對其產生的異常數據結果做進一步專業的分析，第三是對性能的消耗較大，因而對硬件要求較高。

再往上一層是自動化的風險評估技術，包括安全測試編排等，目前懸鏡正與甲方用戶在該技術方向進行嘗試。以ASTO為例，它的核心是結合白盒、灰盒和黑盒的能力，從而發現更深層次的業務邏輯漏洞。

最頂層的CARTA，是希望實現風險與信任的平衡，綜合考慮漏洞與數字化應用所關聯業務，從而構建一個信任和彈性并存的研運一體化安全環境，進而使企業能夠敏捷和安全地對整個軟件供應鏈進行建設和保障。

最后需要再次強調的是，云原生時代下，不僅需要安全左移，還要做到敏捷右移，使常態化運營適應敏捷開發節奏和適合云原生場景，并且形成積極防御的安全能力。這是懸鏡認為的軟件供應鏈風險治理最佳實踐。