國內(nèi)企業(yè)要想快速、安全地構(gòu)建、管理和發(fā)布軟件，就得構(gòu)建一個從開發(fā)人員到設(shè)備一體化的安全、無阻礙的軟件流程。開發(fā)人員創(chuàng)建的代碼只是軟件開發(fā)的起始，如今，開發(fā)人員管理著整個軟件供應鏈。一家企業(yè)的軟件供應鏈由許多部分組成，包含各種來源：開源包、商業(yè)軟件、基礎(chǔ)設(shè)施即代碼(IaC)文件、容器、操作系統(tǒng)鏡像等。這種多樣性意味著企業(yè)的軟件供應鏈存在很多風險點，而且由于錯誤、疏忽、質(zhì)量差或惡意攻擊，安全威脅涉及面非常廣泛。
軟件供應鏈風險趨勢
了解易受攻擊的風險點位置，對于保障軟件供應鏈安全非常重要。但是，利用單點解決方案來逐一應對的做法，就如同打地鼠游戲，被擊碎的威脅可能在未注意的其他地方再次出現(xiàn)。
為全面保護供應鏈免受威脅，要從頭到尾始終保持警惕，甚至在開發(fā)者調(diào)用外部軟件包之前就要開始注意。不論是在專有代碼開發(fā)、代碼編譯和臨時構(gòu)建環(huán)節(jié)，還是在整體運算流水線中進行發(fā)布和分發(fā)，直到生產(chǎn)，乃至部署后，都要事無巨細地關(guān)注。除了揭示漏洞和其他安全問題，還需要知道具體場景，以便判斷出真正的風險。
軟件供應鏈威脅兩大主要途徑
第一種是利用供應鏈的“開放性”來獲取攻擊者計劃攻擊的軟件信息。一個常見的例子是，攻擊者試圖遠程映射一個網(wǎng)絡(luò)服務(wù)，或者釋放一個面向物聯(lián)網(wǎng)設(shè)備的軟件，從而熟悉其使用的開源包。然后，他們就能輕松地找到與這些軟件包相關(guān)的通用漏洞披露(CVE)信息，了解軟件包的安全配置，甚至嘗試尋找未知的漏洞(又稱零日漏洞)。當充分掌握有關(guān)漏洞利用路徑的信息后，攻擊者就可以進入第二階段了。
第二種是攻擊者會利用供應鏈，將惡意軟件包和惡意代碼注入公共或私人資源庫，或改變現(xiàn)有的代碼并將惡意部分納入其中。
四大突出風險威脅軟件供應鏈安全
1. 已知漏洞
第三方組件(如開源和商業(yè)軟件)可能帶有非故意性質(zhì)的漏洞，其中許多是已知的，并已在NVD和VulnDB的漏洞數(shù)據(jù)庫中被公開追蹤。
可以通過軟件組件分析(SCA)解決方案來揭露這種風險，該解決方案可以識別特定代碼或制品的軟件物料清單(SBOM)，并將其與已知的CVE聯(lián)系起來，主要是將已識別的軟件元數(shù)據(jù)與公共CVE數(shù)據(jù)庫進行交叉引用。
但是，還需要獲得足夠多的信息以便制定基于風險的決策，并使之自動化。一個可擴展的數(shù)據(jù)庫是必須的，不僅可以追蹤更多風險，還包括進行深入地安全研究，有助于了解能夠降低這些風險的所有方式，從而選擇最實用且最具成本效益的方法。
同樣重要的還有場景分析，以此確定漏洞被利用的可能性。例如，組件中易受攻擊的功能可能不會被應用程序使用，或者易受攻擊的程序從未在生產(chǎn)版本中運行，或者特定的配置會導致給定的CVE失效。
也可以從看似安全的組件中識別出可能的運行風險。例如，一個很久沒有維護的開源包可能未針對安全問題進行充分監(jiān)控。在此情況下，漏洞是不確定的，但潛在的威脅是可預見的。
這些已知的和可預期的風險能夠而且應該在以下幾個方面發(fā)現(xiàn)：
· 源代碼：將安全警惕性左移到代碼創(chuàng)建之時，可以節(jié)省后期修復的成本。安全團隊可以構(gòu)建一個獲批第三方組件的內(nèi)部資源庫，開發(fā)人員可以通過對其集成開發(fā)環(huán)境(IDE)的擴展來獲得對薄弱依賴項的警報。雖然本質(zhì)上是不完整的，但這種方法有助于避免已知的風險。需注意的是，它不可能是詳盡的，因為左移的安全工具通常會讓開發(fā)者承擔成百上千的工作任務(wù)，而這些工作任務(wù)從安全的角度來看不一定有影響，因為它們會忽略漏洞或安全問題的完整場景。
· 二進制文件：對關(guān)鍵二進制存儲庫(包括第一和第三方組件)中的所有軟件包、構(gòu)建和圖像進行自動軟件成分分析(SCA)掃描，確保整個軟件供應鏈受到保護，免受已知漏洞和運營風險的影響。作為應用程序生產(chǎn)階段狀態(tài)的最準確的代表，二進制文件能夠?qū)︼L險進行最高質(zhì)量的真實分析，并提供更準確的場景。借助二進制文件，還能分析對左移工具和生產(chǎn)中安全解決方案來說是“盲點”的問題。
2. 未知漏洞(零日漏洞)
編碼中的錯誤很常見。邏輯缺陷、不良加密和潛在的內(nèi)存損壞都會無意中導致應用程序易受惡意攻擊，如遠程代碼執(zhí)行(RCE)和拒絕服務(wù)(DoS)。這些錯誤可能潛伏在第一和第三方代碼中而不被發(fā)現(xiàn)，甚至在被識別前已潛伏數(shù)年。
這些問題被稱為“零日”問題，部分原因在于其存在時間長，但也因其緊迫性，而意味著團隊能夠在已部署軟件中對其進行修復的時間為零。
為捕捉和防止?jié)撛诘牧闳諉栴}，必須將不同二進制文件、進程和服務(wù)之間的流通性納入考量，對每個組件與應用程序進行測試。靜態(tài)代碼分析(審查代碼源)和動態(tài)代碼審查(測試運行中的代碼)工具通常各自能夠識別約85%的缺陷，但他們通常會在每個版本中產(chǎn)生成千上萬的條目，并且需要專業(yè)知識來闡釋結(jié)果并確定優(yōu)先次序。不過，一個可能存在的漏洞，但并不意味著它一定可以會被攻擊。
更先進的技術(shù)結(jié)合了符號執(zhí)行、數(shù)據(jù)流分析和自動模糊測試，可以顯著降低誤報率，并識別典型 SAST/DAST 無法發(fā)現(xiàn)的漏洞。結(jié)合對源代碼和二進制文件的分析，也可以產(chǎn)出更完善的結(jié)果，并幫助開發(fā)者、安全團隊和生產(chǎn)經(jīng)理專注于修復重要問題。
縱然竭盡所能，但還是可能會發(fā)現(xiàn)新的漏洞并影響到已部署的軟件。持續(xù)的SCA掃描有助于確保迅速獲得任何會影響生產(chǎn)階段軟件的最新CVE通知。豐富的SBOM元數(shù)據(jù)有助于迅速了解漏洞對機構(gòu)的全部影響，并在整體應用程序庫存中應對或補救。將代碼和制品庫適當進行整合，可以在整個機構(gòu)內(nèi)迅速采取行動，應對已發(fā)現(xiàn)的威脅。
3. 非代碼問題
并非所有的漏洞都存在于代碼之中，還可能存在于二進制文件(如EPMs)、jar文件容器、固件以及支持性制品(如配置文件或IaC文件)中。錯誤配置、不良加密、秘鑰和私鑰的暴露，或操作系統(tǒng)問題都會導致受攻擊面出現(xiàn)。
這些人為錯誤的副作用通常是由于缺乏關(guān)注而造成，并不是惡意為之，而且通常是在主要開發(fā)的熱點之外引入的。用于測試的配置可能被不經(jīng)意地推廣到生產(chǎn)階段。這些風險通常易于解決，但難于被發(fā)現(xiàn)，也更難于恢復。
即使是良好的意圖也可能導致惡意的后果，例如，在公共服務(wù)器上暴露密碼，就可能招致惡意代碼注入，從而暴露敏感數(shù)據(jù)。類似名稱的軟件包之間的依賴項混淆也可能在非30惡意的情況下發(fā)生，特別是當軟件包庫解析配置不良的情況下。
在這些問題發(fā)展到生產(chǎn)階段之前，及早發(fā)現(xiàn)是至關(guān)重要的。需要像對待代碼中的漏洞一樣認真對待這些潛在風險，并將這種警惕性納入流水線端到端安全態(tài)勢中。
4. 惡意代碼
故意的威脅(無論是來自外部注入攻擊還是惡意的內(nèi)部人員)往往是最難發(fā)現(xiàn)的，因其經(jīng)常被掩蓋，而顯示為已經(jīng)驗證的組件。特洛伊木馬、機器人程序、勒索軟件、加密軟件和間諜軟件的傳播通常是以較為良性的漏洞類型作為有效載體。利用有害的軟件包來植入常用存儲庫，入侵維護員賬戶以改變現(xiàn)有軟件包，或?qū)⒋a注入被破壞的源存儲庫，都是后門訪問攻擊的常用方法。
在部署后發(fā)現(xiàn)上述攻擊，通常為時已晚，損害已經(jīng)造成，而且可能代價非常高昂。這就是為什么應該在整體流水線中對其進行保護：
· 訪問控制：內(nèi)部軟件包庫必須通過整個機構(gòu)內(nèi)始終一致的權(quán)限和安全認證(包括多因素認證)，將寫入權(quán)限限制為關(guān)鍵角色和團隊成員。
· 代理存儲庫：緩存外部存儲庫(如Maven Central和npm)可提供不可篡改的第三方資源快照，因此任何后續(xù)的惡意覆蓋都會立即顯現(xiàn)出來。
· 測試和分析：先進的靜態(tài)和動態(tài)分析工具可以檢測和標記惡意代碼和有問題的軟件包。JFrog安全研究團隊已經(jīng)通過自身開發(fā)的工具，在公共軟件包庫中發(fā)現(xiàn)并披露了1300多個惡意軟件包。
軟件供應鏈風險管理的端到端警惕性
雖然這些風險趨勢中的一些問題能夠一次性解決，但單點解決方案只能作為警報系統(tǒng)，而且只在需要之處才能起到幫助。
鑒于同樣的原因，單獨的安全解決方案能夠起到的幫助也是有限的，因其能力范圍有限，因此無法幫助分析和判斷整個軟件供應鏈中風險的完整場景。當與存儲庫和軟件管理解決方案脫節(jié)時，即使安全單點解決方案非常準確，也很難針對所發(fā)現(xiàn)的問題采取有效的行動來進行補救和應對。
全面的安全態(tài)勢不能只關(guān)注流水線中孤立的各個點，必須能夠?qū)⒉煌瑔栴}和安全方面的發(fā)現(xiàn)這些眾多點聯(lián)系起來，而這是單獨的小眾解決方案所無法做到的。
為維護軟件安全，就需要做到端到端的警惕，從開發(fā)者的IDE一直到生產(chǎn)階段，在開發(fā)和生產(chǎn)環(huán)境中執(zhí)行一致的風險監(jiān)督并落實應對措施。安全解決方案必須應用于整個軟件供應鏈，并能夠大規(guī)模采取行動。為確保整個機構(gòu)內(nèi)的一致性，其運營必須圍繞所有二進制文件的單一可信來源，并與開發(fā)運維工具深度集成。
（文章作者：JFrog大中華區(qū)總經(jīng)理董任遠）
