阿里安全專家：軟體供應鏈安全風險管控，任重而道遠
作者：阿里巴巴安全部 杭特
硬體中的韌體，控制器的實現，甚至人工智慧（AI）晶片中的演算法，都可以看成是廣義的軟體。“軟體定義世界，資料驅動未來”，軟體成為影響世界發展的重要因素。前美國聯邦調查局（FBI）員工號稱曾在歐盟通訊的系統裡置入過演算法級後門，這個傳言似乎離我們相對遙遠。但是，最近幾年，軟體供應鏈的安全問題卻呈現出迅速增長的趨勢。
從XCodeGhost引起大眾的注意，到NetSarang公司因入侵導致的XShell軟體後門事件，之後又發生了多起開發基礎庫（PIP/NPM）原始碼汙染導致的後門植入，今年則有Gentoo Linux發行版的GitHub/">GitHub因賬號安全導致所有軟體包存在威脅，以及賬號登入管理庫（libssh）後門甚至可以影響F5裝置的事件等。軟體供應鏈導致的安全問題越來越向上遊發展，也越來越隱蔽。可以預見，在不久的將來，軟體供應鏈安全的影響會更廣泛，甚至會涉及工業生產設施、醫療系統、無人機、自動駕駛汽車等物件。
一方面是功能需求的突然爆發，一方面是軟體開發人員的相對短缺。面對社會全面網際網路化帶來的海量需求，有限的開發人員不得不大量複用各種軟體模組（包括各種開源軟體）來提升開發效率，對軟體供應鏈形成極大依賴，其中的安全風險不容忽視。
一、軟體供應鏈上每個環節都會對安全造成影響
既然軟體供應鏈是一個鏈條，那麼，鏈條上的每一個環節都會對安全造成影響，而這些影響對於末端的使用者來說，是很難感知到的。
第一，最上游的作業系統和基礎庫的程式員。這個物件群體的特點是影響面極廣，因此，無論是程式設計師主動或者被動嵌入後門，都會造成災難性的後果。以2017年的無線通訊WPA2 KRACK劫持漏洞為例，其安卓系統下漏洞引入的物件是基礎庫wpa_supplicant，全世界所有的安卓系統都依賴這個基礎庫進行無線接入，但是，實際上該軟體的開發者只有一兩個人。類似的基礎庫還有成百上千，然而，這些開發者的安全意識未必更強。對於大型網際網路企業來說，表面看起來安全水位不低，但是，如果換一種思維，從這些企業依賴的眾多基礎軟體供應鏈開發者為目標，難度將大大降低，影響面將涉及幾乎每一臺主機。
第二，下游的使用基礎庫、IDE開發系統的程式設計師。以XCodeGhost為例，由於使用了嵌入惡意功能的非官方XCode 整合軟體開發環境（IDE）工具，包括微信在內的數百款IOS App都受到影響。程式設計師由於個人偏好，會使用多種型別的IDE、程式碼管理工具、程式碼編輯工具、編譯工具鏈、整合測試系統等。每種軟體都是相對複雜且容易遭受“毒手”的物件，甚至包括各種網上可以下載的外掛。
第三，IT運維人員。運維人員常用的軟體包括各種登入管理軟體、系統監控軟體、業務釋出系統、日誌分析軟體等。由於運維的特性，這些軟體一般都以最高許可權執行，因此，如果依賴的軟體包含惡意行為，將直接洩露系統的關鍵資訊（如登入號、業務資料）。這也是為什麼XShell、Putty、WinSCP、SecureCRT的無論官方還是非官方版本都出現過後門的原因。
第四，末端使用者。雖然他們大多是病毒木馬的受害者， 如果這些使用者恰巧是辦公網的敏感使用者，或者某些特定場景的使用者，也會受到攻擊者的“關愛”。例如，別有用心的人曾在計算炮彈彈道的移動應用上做過手腳，每次使用時都會向外傳送資訊，進而暴露武器使用者的地理位置。
二、“事件驅動”觀念導致軟體供應鏈安全問題嚴重
雖然前面列舉了軟體供應鏈安全的種種危害和相關事件，但是，目前國內相關方面還沒能“嚴陣以待”，還有亟待提升的空間。
1. 重視程度不足，“不覺得會是個事兒”
安全本來就是冰山一角，相對於病毒木馬和漏洞，軟體供應鏈安全問題的出現概率較低。對於這種影響面巨大，卻相對罕見的情況，絕大多數部門和企業都是被“事件驅動”。每當有軟體供應鏈安全事件發生，及時處理就可以了，如果把發現未知威脅作為核心考核指標（KPI），產出是極其不確定的，也鮮有組織和企業願意投入資源。總歸一句話，相關職能部門和企業“不覺得會是個事兒”。
2. 檢測難度更高，“自動化檢測更困難”
相對於程式碼質量與漏洞掃描，軟體供應鏈安全相關的自動化檢測更為困難，主要原因是：第一，缺乏嚴格地定義與分類。與漏洞有完善的CWE和OWASP等分類不同，軟體供應鏈安全的相關問題沒有標準的定義與分類，通常只是一個籠統的“未定義功能”或者後門，英文中有一個bugdoor與之相近。未定義功能與軟體本身的行為有比較強的相關性，一個功能在一個軟體裡是正常的，在其他的軟體裡卻可能是異常的。第二，缺乏通用的測試集。既然沒有定義與分類，與之對應的測試集也處於空白狀態。第三，缺乏相關的學術理論與實踐。第四，缺乏相應的開源軟體與商業產品。第五，軟體種類極多，且檢測方式差異較大，既包括基於原始碼的C/Java/Python/NodeJS等多種語言，也包含基於二進位制的x86/arm/IR等物件。不同種類的軟體，其檢測規則會有較大的差異，存在極大的工程量。
3. 國家政策導向空白，“急需完善”
目前，國家在重點專案引導中並沒有以軟體供應鏈安全為主題的專題，在產品審查測評過程中，也鮮有供應鏈安全相關的流程要求及檢測手段。面對如此高的風險，相對於美國標準委員會流程上的NIST-800-161及國防部（DARPA）的商用資訊技術軟體及韌體審查專案（VET）研究專案，國內基本上的對策就是一片空白，急需完善。
三、解決軟體供應鏈安全問題需各方努力
目前，我國應在瞭解國外先進經驗的前提下，通過研究立項、標準制定、測評要求等方式儘快縮小差距，並督促企業進行風險控制。
1. 瞭解國際先進經驗才能“知己知彼”
美國的NIST-800-161標準發表於2015年4月，美國國家標準與技術研究院（NIST）的這個標準其實並不單純聚焦軟體供應鏈安全技術，而是資訊與通訊技術（ICT）系統的風險管理指南。更多的是從風險控制的視角，制定流程、規則，識別、評估風險等級，確保資訊系統風險可控。
專門以軟體供應鏈安全檢測技術為目標的研究專案（VET）是美國國防部DARPA於2013年底建立的，針對商用資訊科技軟體及韌體進行審查的研究專案。其主要目的就是探索各種檢測軟硬體存在的隱蔽行為。專案週期4年，專案經費約5000萬美元。
工業界的嘗試Grafeas專案是由Google、IBM、紅帽公司（Red Hat）、傑蛙科技（JFrog）等公司聯合開發的開源專案，用於統一設計和管理軟體供應鏈，從而提升其安全性。
2. 開展相關研究專案、流程標準及測評專案
相對美國自2013年開始的研究專案，2015年給出的風險管理指南，我國在這方面仍處於空白。應通過研究專案、流程標準、專案測評准入等方式，對該風險進行有效控制。具體包括：
第一，研究專案引導。對軟體供應鏈安全風險進行定義和分類，積累通用測試集，探索程式碼和二進位制檢測能力，完善相關的學術理論和實踐，篩選出優秀的研究團隊和方法論。
第二，流程標準開路。探索符合國情的軟體供應鏈安全風險管理指南，指定流程規範，對風險進行評估和規範。
第三，測評准入。對重點專案進行測評准入，軟體供應鏈安全管理能力應成為一票否決因素。
3. 督促企業相關投入
重點專案和企業應該具備軟體供應鏈安全風險管理能力，如發現風險應及時上報，持續確保核心系統的安全可靠。
四、思考
除了前面列舉的對策，還需要澄清一個誤解，並提出一個建議，供參考。軟體設計中超過90%的部分通過“拿來主義”實現的現實，“自主可控”的呼籲，以及採取“平臺方式”讓大家群策群力的方式等，都是值得思考的問題。
1. “拿來主義”觀念的核心軟體安全是否靠譜
從軟體開發角度，模組化是提效的基本要求，再加上開源軟體的極大豐富，網民才能享受眾多的應用、物聯網裝置和新奇酷炫的人工智慧科技。據統計，每款軟體中自主開發的平均比例不超過10%，超過90%的部分是通過“拿來主義”，複用各種第三方開源/閉源軟體實現的。另外，IT從業者還會大量使用IDE開發軟體、下載軟體、網管軟體等。那麼，會不會有惡意的開發者，在自研軟體中加入惡意功能？90%“拿來主義”的非自研部分，以及工作、生活中使用的核心軟體，是不是真的安全可靠無後門呢？這些問題，值得思考。
2.“自主可控”是否能夠解決軟體供應鏈安全問題
實現“自主可控”是否不存在軟體供應鏈安全問題？答案顯然是否定的。自主可控只是核心系統為自己實現，仍存在以下問題：無法消除惡意開發的風險、程式碼實現仍有可能存在漏洞、仍有大量外部依賴程式碼，安全性仍然無法保證。因此，無論是否自主可控，都將面對同樣的軟體供應鏈安全風險，不可大意。
3.“平臺方式”的群策群力是否可以借鑑
互聯時代，所有的大型網際網路公司都面臨同樣的安全風險。實際上，有需求的組織和企業很多，而很多學術機構雖有技術儲備，但是，缺乏突破口和衡量能力的尺子，何不採取平臺的方式，集合買方和賣方，讓大家都參與進來，群策群力？阿里以軟體供應鏈安全的定義和檢測能力為比賽目標，吸引了很多對此有興趣的高校和企業參加。相關參與方的能力已超出舉辦方的預期，目前積累了各種安全風險的樣本和檢測方案，阿里也願意用自己的企業信譽為這些優秀的團隊及其能力進行背書。
（本文刊登於《中國資訊保安》雜誌2018年第11期）
宣告：本文來自中國資訊保安，版權歸作者所有。文章內容僅代表作者獨立觀點，不代表安全內參立場，轉載目的在於傳遞更多資訊。如需轉載，請聯絡原作者獲取授權。