在過去幾年中，DevOps文化的出現(xiàn)從根本上改變了軟件開發(fā)的方式，使企業(yè)可以更快地推送代碼，并自動擴展支持新功能和創(chuàng)新所需的基礎設施。而將DevSecOps投入到開發(fā)和運營渠道中的安全性日益增強，現(xiàn)在正在改變應用程序安全性的狀態(tài)，但是一份最新發(fā)布的行業(yè)調查報告表明，這種差距仍然存在。

[[341168]]

安全測試所有權

調研機構Enterprise Strategy Group(ESG)公司最近發(fā)布的一份調查報告對北美地區(qū)的378位應用程序開發(fā)人員和應用程序安全專業(yè)人員進行了調查，發(fā)現(xiàn)盡管許多組織認為自己的應用程序安全程序很可靠，但仍繼續(xù)將具有已知漏洞的代碼用于生產(chǎn)環(huán)境。

發(fā)布易受攻擊的代碼并不是什么好事，但知道有漏洞總比毫不知情要好，因為企業(yè)的決策通常涉及一些風險評估和修復計劃，也許還有一些應對措施。一半的受訪者表示他們的組織經(jīng)常這樣做，三分之一的受訪者表示他們的組織偶爾也這樣做。他們提到的一些原因通常是在截止日期之前出現(xiàn)漏洞，或在發(fā)布周期中發(fā)現(xiàn)問題為時已晚。

這份報告強調了組織在開發(fā)過程中盡早地集成安全測試是很重要的原因，而且發(fā)布易受攻擊的代碼并不一定表示沒有良好的安全程序，因為這可能有多種不同的原因，并且沒有一種單一類型的安全測試能夠捕獲所有的錯誤。然而，調查還發(fā)現(xiàn)，許多組織仍在擴展其應用程序的安全性，只有33%的組織表示其程序覆蓋了代碼庫的75%以上，33%的組織表示其程序覆蓋了不到一半的代碼。

調查發(fā)現(xiàn)，將易受攻擊的代碼投入生產(chǎn)的決策者可能因組織而異。28%的組織的決策是由開發(fā)經(jīng)理和安全分析師共同做出的，24%的組織中的決策是由開發(fā)經(jīng)理單獨做出的，21%的組織的決策是由安全分析師做出的。

這實際上可能是應用程序安全性成熟的標志，因為DevSecOps是關于在開發(fā)管道中盡早進行安全測試，而在過去，安全測試只屬于組織安全團隊的范圍，他們通常在產(chǎn)品完成后執(zhí)行安全測試。

在組織中，開發(fā)團隊由于集成到他們的流程中而進行了安全測試。因此與安全團隊合作，由開發(fā)經(jīng)理做出可接受漏洞的決策是正常的，而團隊的安全負責人通常是一位具有應用程序安全知識和經(jīng)驗的開發(fā)人員。但是，這種決策仍應基于制定組織策略的首席信息安全官(CISO)做出，他最終負責管理組織整體的信息安全風險，并且可以確定哪些應用程序更容易受到攻擊，或者確定黑客可能攻擊的更敏感信息。這些應用程序在打補丁時可能有更嚴格的規(guī)則。

如果沒有正確評估風險，則采用帶有已知漏洞的代碼可能會造成嚴重后果。60%的受訪者承認，在過去12個月里，他們的應用程序受到了OWASP Top-10列出的漏洞進行攻擊。OWASP Top-10包含了Web應用程序最關鍵的安全風險，其中包括SQL注入、破壞身份驗證、泄露敏感數(shù)據(jù)、破壞訪問控制、安全性錯誤配置、使用具有已知漏洞的第三方組件等問題。這些問題通常不應該允許存在于生產(chǎn)代碼中。

根據(jù)ESG公司的這份調查報告，很多組織使用的各種應用程序安全測試工具包括：API安全漏洞(ASV)掃描(56%)、防止錯誤配置的基礎設施代碼安全工具(40%)、靜態(tài)應用程序安全測試(SAST)工具(40%)、軟件組成分析(SCA)測試工具(38%)、交互式應用程序安全測試(IAST)工具(38%)、動態(tài)應用程序安全測試(DAST)工具(36%)、可以幫助識別和解決安全問題用于集成開發(fā)環(huán)境的插件(29%)，掃描容器和存儲庫以及微服務中使用的圖像的工具(29%)、模糊測試工具(16%)、容器運行的配置安全工具(15%)。

然而在使用這些工具面臨的挑戰(zhàn)中，其中包括，缺乏發(fā)現(xiàn)并解決問題的開發(fā)人員(29%)，沒有使用組織有效投資工具的開發(fā)人員(24%)，安全測試工具增加難度并減慢了開發(fā)速度周期(26%)，以及來自不同供應商的應用程序安全工具之間缺乏集成(26%)。

盡管將近80%的組織表示，他們的安全分析師通過直接工作以審查功能和代碼，與開發(fā)人員合作進行威脅建模，或者參加開發(fā)Scrum會議，但他們自己似乎沒有接受更多的安全培訓。這就是只有19%的組織的應用程序安全測試任務是由開發(fā)人員正式擁有的原因，26%的組織是由開發(fā)經(jīng)理負責的。三分之一的組織仍然將這項任務分配給專門的安全分析師，另有29%的組織由開發(fā)和安全團隊共同擁有。

在三分之一的組織中，只有不到一半的開發(fā)人員接受過安全培訓;只有15%的組織表示，其開發(fā)人員都進行了這種培訓。不到一半的組織要求開發(fā)人員每年參加一次以上的安全培訓，其中16%的組織希望開發(fā)人員進行自我教育，而20%的組織只在開發(fā)人員加入團隊之后才提供培訓。

此外，即使在提供或需要安全培訓的情況下，大多數(shù)組織也無法有效跟蹤這種培訓的有效性。只有40%的組織對開發(fā)團隊或開發(fā)人員跟蹤安全問題和進行持續(xù)改進。

針對供應鏈攻擊的開源組件

任何成熟的應用安全程序也應該涵蓋開源組件和框架，因為這些組件和框架在現(xiàn)代應用程序代碼庫中占有很大比例，并且存在繼承漏洞和供應鏈攻擊的風險。在ESG公司的調查中，幾乎一半的受訪者表示，開源組件占到他們代碼庫的50%以上;8%的受訪者表示，他們?nèi)种拇a是由開源組件組成的。盡管如此，只有48%的組織投資于處理開源漏洞。

開源治理服務提供商Sonatype公司在其《2020年軟件供應鏈狀況報告》中指出，針對開源軟件項目的網(wǎng)絡攻擊同比增長430%。這些網(wǎng)絡攻擊不再是被動的，因為網(wǎng)絡攻擊者在這些漏洞公開披露之后就利用了這些漏洞。而網(wǎng)絡攻擊者試圖破壞惡意軟件并將其注入上游開放源代碼項目中，然后由開發(fā)人員將其代碼提取到自己的應用程序中。

GitHub安全團隊就名為Octopus Scanner的惡意軟件攻擊活動在今年5月發(fā)出了警告，該軟件是NetBeans IDE項目的后門程序。而受到攻擊或感染的組件也已定期分發(fā)到軟件包存儲庫(如npm或PyPi)中。

復雜的依存關系網(wǎng)絡使處理這個問題變得更加困難。達姆施塔特大學的研究人員在2019年分析了npm生態(tài)系統(tǒng)，它是JavaScript組件的主要來源。他們發(fā)現(xiàn)，一個典型的軟件包從平均39個不同的維護者中加載了79個其他第三方軟件包。npm上排名前五位的軟件包覆蓋了134774到166086個其他軟件包。

Sonatype公司在報告中說：“當惡意代碼被有意地和秘密地向上游注入開源項目時，除了植入它的人員以外，幾乎沒人會知道惡意軟件在那里。這種方法可以使對手秘密地在上游設置陷阱，一旦漏洞通過供應鏈蔓延，然后在下游進行攻擊。”

該公司稱，在2015年2月至2019年6月，用戶報告了216起這種供應鏈攻擊，但從2019年7月至2020年5月，有929起攻擊被記錄在案，因此這已成為一種非常流行的攻擊媒介。

對于黑客利用組件中已知漏洞的傳統(tǒng)攻擊而言，很多組織似乎沒有足夠的準備能夠迅速地做出響應。就Apache Struts2漏洞最終導致2017年的Equifax公司的泄漏事件來說，網(wǎng)絡攻擊者在這個漏洞公開之后的72小時內(nèi)便開始利用該漏洞進行攻擊。最近，SaltStack公司報告的一個漏洞在公開后的三天內(nèi)也被利用，導致許多組織措手不及。

Sonatype公司對679位軟件開發(fā)專業(yè)人員的調查表明，只有17%的組織在漏洞公開披露一天之后才得知。三分之一的組織在一周內(nèi)得知，而將近一半的組織在一周之后得知。此外，大約一半的組織在了解到這一漏洞之后在一個多星期之后才對漏洞進行響應，其中一半的組織花費一個多月的時間。

開源組件的可用性和使用量在逐年增加。在過去的一年中，JavaScript社區(qū)引入了50多萬個新組件版本，將npm目錄推至130萬個軟件包。直到今年5月，開發(fā)人員從npm下載的軟件包達到860億次。Sonatype公司預計到今年年底，這一數(shù)字將達到1萬億次。令人擔憂的是，達姆施塔特大學去年發(fā)布的研究報告表明，所有npm軟件包中將近40%包含或依賴具有已知漏洞的代碼，而npm軟件包中的66%漏洞仍未修復。

在Java生態(tài)系統(tǒng)中，開發(fā)人員在2019年從Maven中央存儲庫中下載的開源軟件組件達到2,260億次，與2018年相比增長了55%。根據(jù)2020年的統(tǒng)計數(shù)據(jù)，Sonatype公司估計，Java組件下載量每年將達到3,760億次。該公司維護中央存儲庫，并對數(shù)據(jù)有深刻見解，該公司報告說，10%的下載是針對具有已知漏洞的組件進行的。

對1,700個企業(yè)應用程序的進一步分析表明，它們平均包含135個第三方軟件組件，其中90%是開源的。這些開源組件中的11%至少具有一個漏洞，但是應用程序平均從這些組件繼承了38個已知漏洞。而由2,000到4,000個開源組件組合而成的應用程序并不少見，這凸顯了開源生態(tài)系統(tǒng)在現(xiàn)代軟件開發(fā)中的主要作用。

在.NET生態(tài)系統(tǒng)和微服務生態(tài)系統(tǒng)中觀察到了類似的組件使用趨勢，其中DockerHub在過去一年中收到了2.2個容器映像，并且有望在今年看到開發(fā)人員提出960億個映像拉取請求。公開報告的供應鏈攻擊涉及托管在DockerHub上的惡意容器映像，并且存在配置錯誤或漏洞的映像的可能性也很高。

基礎設施即代碼需要進行修正

DevOps運動從根本上改變了軟件開發(fā)，并使得新的微服務架構成為可能，在這種架構中，傳統(tǒng)的整體應用程序被分解為在各自容器中運行的單獨維護的服務。應用程序不再僅包含其功能所需的代碼，還包含指示其在云平臺上的部署并自動進行部署的配置文件，以及所需的資源。通過DevSecOps，開發(fā)團隊不僅負責編寫安全代碼，還負責部署安全基礎設施。

云計算安全廠商Accurics公司在最近發(fā)布一份調查報告中稱，該公司運營著一個平臺，可以檢測基礎設施中易受攻擊的配置，例如代碼模板和云部署，41%的組織在其配置中擁有硬編碼密鑰，這些密鑰用于提供計算資源，89%的部署配置了資源，并且運行時使用了過度寬松的身份和訪問管理(IAM)策略，而且?guī)缀跛胁呗远加绣e誤配置的路由規(guī)則。

該公司表示， CenturyLink公司在2019年9月發(fā)生的泄露事件中泄露了280萬條客戶記錄;Imperva公司在2019年8月發(fā)生的泄露事件中，泄露了包含電子郵件、哈希密碼的數(shù)據(jù)庫快照;Capital One公司在2019年7月發(fā)生的泄露事件影響了1億以上的美國人，這是利用其中一個漏洞進行攻擊造成的。

Accurics公司首席技術官Om Moolchandani說：“策略即代碼的實施應確保采用最佳實踐，如加密數(shù)據(jù)庫、旋轉訪問密鑰和實現(xiàn)多因素身份驗證。然而，自動威脅建模對于確定權限增加和路由更改等是否會在云部署中創(chuàng)建破壞路徑也是必要的。因此，當在開發(fā)過程中定義基礎設施(基礎設施即代碼)時，組織必須將策略作為代碼，安全性作為代碼進行擴充。”

他表示，一種稱為“代碼修復”的新實踐正在興起，安全工具不僅檢查云配置模板或正在運行的部署本身的漏洞，還會生成自動修復問題所需的代碼，并將其提交給開發(fā)人員。這可能會縮短組織進行補救的時間，這是一個主要問題，因為到目前為止，這一過程基本上都是人工完成的，導致許多問題被忽略。

在過去的幾年中，許多應用程序和基礎設施安全供應商一直在致力于重新設計他們的產(chǎn)品，以便他們能夠很好地與開發(fā)工具集成，因為開發(fā)人員的期望和工作方式與安全團隊不同。許多開源工具也可用于測試云部署。

滲透測試機構Bishop Fox公司在美國黑帽大會期間發(fā)布了一個名為Smogcloud的工具，該工具可以幫助安全工程師和云計算管理員找到他們在AWS云平臺泄露的數(shù)據(jù)資產(chǎn)，其中包括面向互聯(lián)網(wǎng)的FQDN和IP、配置錯誤或漏洞、不再使用的資產(chǎn)、當前未監(jiān)控的服務，以及其他影子IT。