近期，國外知名的專注于應(yīng)用安全的 Veracode 公司發(fā)布了他們一年一度的《軟件安全報告》至今已連續(xù)發(fā)布了12版。在最新的報告中(第12版)，Veracode 公司深入觀察了軟件開發(fā)和軟件安全近十年的發(fā)展?fàn)顩r，提供了詳實的數(shù)據(jù)分析和對比結(jié)果，并結(jié)合當(dāng)下主流的應(yīng)用缺陷掃描能力橫向?qū)Ρ冉o出了提高軟件安全性的最佳實現(xiàn)路徑。這對于持續(xù)關(guān)注國內(nèi)外安全行業(yè)應(yīng)用安全領(lǐng)域發(fā)展態(tài)勢的同行來說，具有一定的借鑒意義。
概述
世界正變得比以往任何時候都更緊密地聯(lián)系在一起。連接使我們的生活更輕松，但它也增加了風(fēng)險。一個安全漏洞可能會產(chǎn)生多米諾骨牌效應(yīng)，使軟件在全球范圍內(nèi)都受到攻擊，例如去年年末爆發(fā)的 Log4j 高危漏洞以及近期出現(xiàn)的 Spring Framework 遠程執(zhí)行代碼 (CVE-2022-22965)，幾乎影響了全球絕大多數(shù)軟件。但是，塑造了安全格局的不僅僅是增強的連接性，還有超強的競爭力和不斷創(chuàng)新的需求。為了加快速度，許多軟件開發(fā)團隊已經(jīng)轉(zhuǎn)向本地云技術(shù)、微服務(wù)架構(gòu)和開源代碼來加速和擴展他們的努力。此外，軟件開發(fā)團隊已經(jīng)采用了敏捷方法，并且在開發(fā)過程中盡可能自動化更多的步驟。
雖然這種演變提高了軟件開發(fā)生命周期的速度，但也帶來了新的復(fù)雜性和風(fēng)險。在我們的第 12 版軟件安全狀況報告中，我們將在 Cyentia 研究所的幫助下探討這些趨勢，以評估軟件安全狀況是如何繼續(xù)發(fā)展的。我們的目標(biāo)是幫助業(yè)內(nèi)同行對軟件安全計劃作出明智的決定，以便各位同行可以最小化風(fēng)險，并滿足網(wǎng)絡(luò)安全條例的要求，如美國白宮在2021年5月12日發(fā)布的關(guān)于改善國家網(wǎng)絡(luò)安全行政命令中所列出的要求。
2021年5月，拜登政府發(fā)布了一項關(guān)于網(wǎng)絡(luò)安全的行政命令，概述了向美國政府銷售軟件的供應(yīng)商的新安全要求。這些要求包括軟件開發(fā)過程中的安全測試以及正在使用的開源庫的物料清單，因此，已知的漏洞將被披露，并且能夠在將來進行跟蹤。雖然該命令僅影響短期內(nèi)向聯(lián)邦政府銷售軟件的公司，但它也需要制定一個試點計劃，最終將改變所有軟件供應(yīng)商的安全要求。
”商業(yè)軟件的開發(fā)往往缺乏透明度，對軟件抵御攻擊的能力缺乏足夠的重視，并且缺乏防止惡意行為者篡改的適當(dāng)控制?，F(xiàn)在迫切需要實施更加嚴格和可預(yù)測的機 制，以確保產(chǎn)品的安全運行，并且如預(yù)期的那樣?！标P(guān)鍵軟件”——執(zhí)行對信任至關(guān)重要的功能(例如提供或要求提高系統(tǒng)特權(quán)或直接訪問網(wǎng)絡(luò)和計算資源)的軟件—— 的安全性和完整性是一個特別令人關(guān)切的問題。因此，聯(lián)邦政府必須采取行動迅 速提高軟件供應(yīng)鏈的安全性和完整性，優(yōu)先處理關(guān)鍵軟件?！?/span>
近十年軟件開發(fā)發(fā)展變化
與去年類似，我們查看了活躍應(yīng)用程序的整個歷史，而不僅僅是查看一年內(nèi)與應(yīng)用程序相關(guān)的活動。通過這樣做，我們可以清楚的了解到應(yīng)用程序的整個生命周期，從而得到更精確的度量和觀察結(jié)果。除了回顧過去，我們還通過考慮可能有助于提高應(yīng)用程序安全性的最佳實踐來設(shè)想未來如何增強軟件安全性。
Veracode 用大量的數(shù)據(jù)量化了很多關(guān)于應(yīng)用程序安全性狀況的發(fā)展變化，近十年是互聯(lián)網(wǎng)高速發(fā)展的時期，我們需要后退一步，審視過去，展望未來，看看哪些方面是穩(wěn)定的，哪些方面發(fā)生了變化，并試圖理解哪些原則經(jīng)受住了時間的考驗，哪些發(fā)生了動搖。
首先，我們來看看人們是如何使用軟件分析工具的，以及這些年來它們是如何改變的。我們將看到這些掃描反映出的發(fā)展趨勢。我們也將看到開源軟件是如何繼續(xù)成為大多數(shù)應(yīng)用程序不可或缺的一部分。其次，我們將分析軟件的缺陷，看看這些軟件開發(fā)趨勢是如何在引入軟件的漏洞過程中表現(xiàn)出來的。接下來，我們將檢查漏洞是如何修復(fù)的，以及開發(fā)人員是否在修復(fù)漏洞方面做得更好。最后，我們將展望未來， 思考開發(fā)者究竟能做些什么才能編寫出更安全的軟件。特別是，我們將看到開發(fā)人員花時間學(xué)習(xí)如何修復(fù)漏洞的簡單行為有助于更快地修復(fù)漏洞，并有助于防止將來出現(xiàn)安全漏洞。
1、經(jīng)過安全掃描的應(yīng)用程序數(shù)量是十年前的三倍多
掃描的應(yīng)用程序數(shù)量相比于十年前增加了三倍
從上圖中，我們可以看到經(jīng)過安全掃描的應(yīng)用程序數(shù)量比以往任何時候都多。這種增長不僅僅是因為有更多的組織機構(gòu)產(chǎn)生。 去年，大多數(shù)組織平均每季度創(chuàng)建超過 17 個掃描應(yīng)用程序，而十年前只有大約 5 個。
其可能原因有以下兩點：一是組織正在創(chuàng)建更小、更模塊化的應(yīng)用程序；二是組織正在將他們的安全掃描范圍擴展到低危的應(yīng)用程序。
從上圖中可以看到應(yīng)用程序的風(fēng)險程度的分布一直相當(dāng)穩(wěn)定。在過去的 10 年里，這種傾斜是非常一致的，大多數(shù)應(yīng)用程序的風(fēng)險程度都是“高”或“非常高”，只有少數(shù)應(yīng)用程序的風(fēng)險程度是“低”或“非常低”。
2、微服務(wù)逐漸成為主流
微服務(wù)一種是松散耦合的應(yīng)用程序的集合，通常有一個小的代碼庫，通過 API 進行通信。微服務(wù)的優(yōu)勢在于，如果更改一個部分不太可能影響其他部分，則可以更容易地處理應(yīng)用程序的各個部分。
從上圖可以看出，大約在2018年之前，使用多種編程語言的應(yīng)用程序數(shù)量緩慢但穩(wěn)定地增長，達到峰值(不包括異常值)，約20%的應(yīng)用程序使用多種編程語言。但是，隨著微服務(wù)的概念越來越受歡迎，這一數(shù)字出現(xiàn)了急劇下降，目前只有不到5%的應(yīng)用程序使用多種語言。
在 2018年，大約有 20% 的應(yīng)用程序包含了多種軟件開發(fā)編程語言。今年，只有不到 5% 的應(yīng)用使用了多種編程語言，這意味著軟件開發(fā)人員將轉(zhuǎn)向更小的、只有一種編程語言的應(yīng)用或微服務(wù)。
使用不同編程語言開發(fā)的軟件代碼庫平均大小與首次靜態(tài)掃描的時間關(guān)系
從上圖可以看出，對于微服務(wù)型架構(gòu)，我們認為可以用多種編程語言編寫的應(yīng)用程序的規(guī)?？隙〞兴陆?，這一趨勢是好事情。使用 JavaScript、Python和 .NET 開發(fā)的應(yīng)用程序數(shù)量都在下降，這表明軟件開發(fā)人員更趨向于使用微服務(wù)，其他幾種常見編程語言的情況如下：
JavaScript
隨著時間的推移，JavaScript 應(yīng)用程序變得越來越小，這可能是因為包含了更加多樣化和健壯的庫生態(tài)系統(tǒng)
PYTHON和.NET
Python和 .NET 規(guī)模有所減少，但這可能更多地只是均值回歸，而不是真實趨勢
C++與Java
同時，使用C++和Java等更為成熟的語言編寫的應(yīng)用程序在過去幾年中保持著差不多的大小
Scala
與其更重量級的教父 Java 相比，Scala 應(yīng)用程序(未展示圖表)的規(guī)模有所下降，Scala 的受歡迎程度可能與不同的架構(gòu)目標(biāo)有關(guān)。
Go
有趣的是，Go(未展示圖表)是一種通常與微服務(wù)相關(guān)的語言，實際上已經(jīng)看到了應(yīng)用程序大小的增加
ANDROID
在Android N發(fā)布之前，Android應(yīng)用程序的規(guī)模越來越大，而Android N改用了OpenJDK。這使得應(yīng)用程序的規(guī)模大大縮小，隨后又出現(xiàn)了緩慢而穩(wěn)定的增長。我們不認為這是一種趨勢，但很高興看到軟件生態(tài)系統(tǒng)中的重大事件在數(shù)據(jù)中得到驗證。
3、安全掃描頻次比十年前增加了20 倍
有人說“軟件正在吞噬世界”，也有人說“敏捷正在吞噬軟件世界”這可能也是對的。持續(xù)測試和集成(包括對管道進行安全掃描)正在成為一種規(guī)范，我們可以從開發(fā)人員掃描其應(yīng)用程序的頻率中看到這一點。十年前，開發(fā)人員平均每年掃描兩到三次。 現(xiàn)在，大多數(shù)開發(fā)人員每天會進行靜態(tài)掃描，并且每周進行動態(tài)掃描。軟件組合分析(SCA) 掃描也是至少每周進行一次。在軟件生命周期中，你越早發(fā)現(xiàn)問題，你就越有可能在問題變得更大之前迅速解決它們。
包括管道安全掃描在內(nèi)的持續(xù)測試和集成正在成為常態(tài)。十年前，應(yīng)用程序每年參與安全掃描兩三次。而現(xiàn)在，90%的應(yīng)用程序每周參與安全掃描一次以上，其中大多數(shù)每周掃描三次。
持續(xù)集成模式的部分優(yōu)勢在于能夠輕松地向管道中添加新的組件。靜態(tài)測試是必須的。動態(tài)測試的使用也在不斷增長，而且由于軟件開發(fā)人員越來越意識到開源軟件固有的潛在風(fēng)險，SCA 的使用也在不斷增長。
從 2018 年到 2021 年，我們看到采用多種安全掃描類型組織增加了 31% ，其中很大一部分組織使用了完整的靜態(tài)、動態(tài)和 SCA 掃描套件。
4、三方庫的安全性依舊堪憂
大多數(shù)應(yīng)用程序(取決于編程語言)具有一種杠鈴效應(yīng)，幾乎完全由第三方代碼或幾乎完全由內(nèi)部代碼組成。當(dāng)然也有一些例外。Java 的 OOP 設(shè)計哲學(xué)將類粘合在一起，直到你的代碼開始看起來像一個正常運行的應(yīng)用程序，這使代碼重用變得輕而易舉。當(dāng)有完美的第三方類可以免費使用時，為什么還要編寫自己的類呢?結(jié)果就是，Java 應(yīng)用程序中的大部分代碼都來自第三方，并且在過去幾年中在這個方向上發(fā)展得更加迅猛。
不同編程語言所開發(fā)的軟件中第三方庫的占比情況
不同編程語言TOP10三方庫的使用情況
上圖展示了我們感興趣的六種語言中最受歡迎的 10 個庫是如何隨著時間的推移而演變的。在堆積區(qū)域圖中，每個波段代表使用特定庫的掃描存儲庫的百分比。帶子越厚，代表庫越受歡迎。當(dāng)圖表的整體高度增加時，表明這 10 個庫的受歡迎程度都在增加。如果庫的受歡迎程度經(jīng)常起起伏伏，那么我們可以預(yù)見，隨著時間的推移，帶子的顏色將會大幅增加，并逐漸消失。我們在上圖中沒有看到這種情況，那些頂級庫的流行程度基本上是一致的。開發(fā)人員將堅持使用可靠的庫，并且可能不會嘗試重構(gòu)他們的代碼庫來獲取最新的熱門的可替代軟件庫。當(dāng)軟件庫沒有漏洞時，更新進展緩慢，但軟件庫出現(xiàn)漏洞時，更新速度就相對較快。只要開源軟件庫的開發(fā)者繼續(xù)修復(fù)安全漏洞，開發(fā)者們就會繼續(xù)使用這些庫。
在過去幾年中，軟件中是否使用了更多或更少的存在漏洞的第三方庫呢?
近幾年不同編程語言開發(fā)的軟件中使用有漏洞的三方庫的占比
在過去四年中，存在已知漏洞的軟件庫的比例從35%下降到不到10%
盡管存在安全漏洞的軟件庫的數(shù)量有很明顯的下降并且大多數(shù)組織采用了多種安全掃描能力，但是仍然有 77% 的第三方軟件庫在漏洞出現(xiàn)三個月后仍未修復(fù)。
從積極的方面來看，對第三方軟件庫存在的漏洞進行補救的時間有了明顯的改善。在 2017 年，要達到 50% (半衰期)的臨界點需要三年多的時間，而現(xiàn)在只需要一年多一點的時間。
通過分析對比近十年的數(shù)據(jù)，我們可以看出應(yīng)用程序的安全性在不斷提升：
存在OWASP Top 10 和 CWE/SANS Top 25 中列出的缺陷的應(yīng)用程序數(shù)量占比
上圖分析了 OWASP Top 10 和 CWE/SANS Top 25 中列出的缺陷，以及那些被歸類為“高?！被蛞陨系娜毕?。隨著時間的推移，如果仔細觀察每一個缺陷，我們就會注意到一些高峰和低谷。盡管線條可能會跳來跳去，總體上都在緩慢地減少。
靜態(tài)安全測試(SAST)、動態(tài)安全測試(DAST)和SCA對比
1、缺陷發(fā)現(xiàn)能力對比
靜態(tài)掃描需要直接查看分析源代碼，因此，在不同的編程語言開發(fā)的軟件中查找的缺陷也不同。靜態(tài)掃描非常擅長檢測內(nèi)存管理不正確或輸入未正確驗證的缺陷。鑒于此，靜態(tài)分析的結(jié)果非常依賴于開發(fā)語言也就不足為奇了。在C++語言中使用緩沖區(qū)/內(nèi)存管理發(fā)現(xiàn)缺陷是很常見的，但是在.NET或Java語言中不存在這些缺陷。因此，即使CRLF注入是靜態(tài)分析的頂部缺陷類型，它甚至不在C++或PHP的前10個缺陷中。
不同編程語言開發(fā)的軟件中通過靜態(tài)分析發(fā)現(xiàn)的缺陷數(shù)量變化
動態(tài)掃描利用運行時環(huán)境，并針對運行時環(huán)境運行。它沒有深入研究底層語言的特性，而是可以在代碼的執(zhí)行和接口中發(fā)現(xiàn)更多的缺陷。請注意，此處最常見的缺陷類型通常與靜態(tài)分析結(jié)果不重疊。服務(wù)器配置和信息泄漏一直是所有底層語言中發(fā)現(xiàn)的主要缺陷類別。這些缺陷在不同的語言中是如此一致，因此不值得展示這些差異。每種語言的總體趨勢如下圖所示。
通過動態(tài)分析發(fā)現(xiàn)的缺陷數(shù)量變化
軟件組合分析是第三種掃描，它通過跟蹤各種開源項目和包，然后識別代碼庫中包含的項目和包來進行操作。這允許與開發(fā)人員共享這些庫中的所有現(xiàn)有信息。第三方軟件中的缺陷可以從各種來源報告，如靜態(tài)代碼掃描、人工代碼審計、安全研究人員報告缺陷等。我們再次發(fā)現(xiàn)，這些類型的缺陷因語言而異，如下圖所示(但請注意，縱軸對不同語言使用不同的比例)。一些語言(Java、JavaScript和Python)在使用時表現(xiàn)出明顯的下降趨勢，.NET和C++沒有顯示出它們第三方庫中的那種類型的下降。
不同編程語言開發(fā)的軟件中通過SCA發(fā)現(xiàn)的缺陷數(shù)量變化
2、缺陷修復(fù)速度對比
到目前為止，我們一直在研究應(yīng)用程序、檢測方法、缺陷類型及其流行程度，以及開發(fā)人員如何隨著時間的推移改變他們的安全實踐。但是，實際上又解決了多少問題呢?這是一個很好的過渡點，可以考慮有多少缺陷得到修復(fù)，以及修復(fù)的速度有多快。通過觀察我們一直在追蹤的數(shù)以百萬計的缺陷，并預(yù)測任何一個特定的缺陷會持續(xù)多久，就可以既考慮到已經(jīng)修復(fù)的缺陷，也考慮到尚未修復(fù)的缺陷，使我們能夠更準(zhǔn)確地度量一段時間內(nèi)的預(yù)期修復(fù)率。
從上圖可以看出，動態(tài)缺陷修復(fù)速度最快，SCA缺陷修復(fù)速度最慢，靜態(tài)分析的缺陷修復(fù)速度介于兩者之間。讓我們重點關(guān)注上圖所示的50%的水平虛線。它代表了修復(fù)大約一半缺陷所需的時間，我們可以稱之為缺陷的“半衰期”。
在通過SCA識別的缺陷中，甚至有一半都要在一年多后才能修復(fù)，這似乎很荒謬——尤其是當(dāng)我們看到通過動態(tài)分析發(fā)現(xiàn)的缺陷在同一個半衰期指標(biāo)下持續(xù)不到5個月時。但如果我們告訴你這實際上是一個巨大的進步呢?看看下圖，我們跟蹤了半衰期指標(biāo)隨時間的變化。從這個歷史角度來看，SCA 發(fā)現(xiàn)的缺陷展示了巨大的改進?；氐?017年，要達到50%(半衰期)的修復(fù)率需要三年多的時間，而這一點已經(jīng)被推到了我們今天所看到的程度：剛剛超過一年。
在查看SCA缺陷并對情況正在改善感到樂觀之后，再看看靜態(tài)掃描?？磥硇迯?fù)工作已經(jīng)從2017年左右的歷史低點有所回落，半衰期不到200天。目前，補救措施已放緩至不到300天。這里的部分挑戰(zhàn)是，競爭激烈的商業(yè)市場要求軟件能夠及時發(fā)布，軟件開發(fā)團隊被迫在及時交付和風(fēng)險之間做出艱難的權(quán)衡。有些缺陷可能無法在截止日期前解決。
如果我們想追蹤修復(fù)的速度，缺陷修復(fù)半衰期是一個很好的指標(biāo)，但依賴它作為一個完整的衡量標(biāo)準(zhǔn)是一個挑戰(zhàn)：因為它不能解釋在給定時間段內(nèi)修復(fù)的所有缺陷。為了衡量在一段時間內(nèi)修復(fù)了多少缺陷，我們必須查看開發(fā)團隊修復(fù)缺陷的總體能力。
3、缺陷修復(fù)能力對比
為了衡量修復(fù)能力，我們查看了一個開發(fā)團隊在一個月內(nèi)面臨的所有缺陷，然后查看其中有多少缺陷在該月內(nèi)得到了修復(fù)。當(dāng)然，不同的應(yīng)用程序會有所不同，但下圖顯示了過去五年的總體趨勢。
下圖中的點代表單個應(yīng)用程序，線代表了總體趨勢。請記住，這里的能力是指在給定的一個月內(nèi)，未解決缺陷總數(shù)中已修復(fù)缺陷的數(shù)量。這為我們提供了每月修復(fù)缺陷的百分比。很高興看到靜態(tài)缺陷和SCA 缺陷的修復(fù)在任何一個月都呈上升趨勢，即使增長幅度不大，并且需要更長的修復(fù)時間(根據(jù)上圖可證明)。通過動態(tài)分析發(fā)現(xiàn)的缺陷的修復(fù)已經(jīng)有點反彈，但隨著我們獲得更多數(shù)據(jù)，我們應(yīng)該可以看到它穩(wěn)定下來。
不同掃描類型的月度缺陷修復(fù)能力
總結(jié)
小型模塊化應(yīng)用的敏捷開發(fā)已經(jīng)吞噬了整個世界，無論開發(fā)人員是否選擇微服務(wù)架構(gòu)、敏感開發(fā)模式，如果不能及時修復(fù)軟件安全缺陷，那么隨著時間的推移，安全債務(wù)就會不斷累積，盡早解決缺陷有助于緩解未來的工作。使用多種類型的掃描(靜態(tài)、動態(tài)和軟件組合分析)可以更全面地了解應(yīng)用程序的安全性，并有助于更快、更全面地修復(fù)漏洞。此外，該報告也指出，通過給開發(fā)人員培訓(xùn)掌握修復(fù)漏洞的技能，并持續(xù)教育開發(fā)人員，對漏洞的及時修復(fù)很有幫助。
開源的代碼以及三方軟件庫對于開發(fā)人員來說將繼續(xù)是福也是禍。我們沒有看到任何跡象表明第三方庫的使用發(fā)生了巨大的變化，甚至開發(fā)者使用的庫也沒有改變。開發(fā)者使用的已知缺陷軟件庫似乎越來越少，這一點讓人感到樂觀。在整個報告中，最令人振奮的可能是，幾乎所有的應(yīng)用程序都在朝著更安全的應(yīng)用程序穩(wěn)步發(fā)展。盡管漏洞修復(fù)的能力和速度并沒有增加。但是將多種類型的工具嵌入到持續(xù)集成管道和 IDE 中可以加快開發(fā)人員修復(fù)漏洞的速度。
來源：嘶吼專業(yè)版
