在應(yīng)用程序安全編排和關(guān)聯(lián) （ASOC） 系列的第一部分中，我們研究了這種新的應(yīng)用程序安全趨勢如何提高 DevSecOps 效率。現(xiàn)在，我們將重點(diǎn)關(guān)注 AppSec 團(tuán)隊(duì)因當(dāng)今快速開發(fā)周期而面臨的典型挑戰(zhàn)，以及 ASOC 工具如何通過自動化和可擴(kuò)展性解決這些挑戰(zhàn)。

問題：AppSec 跟不上 DevOps 的步伐

應(yīng)用程序安全團(tuán)隊(duì)經(jīng)常難以跟上 DevOps 團(tuán)隊(duì)生成的快速代碼發(fā)布。隨著開發(fā)速度的加快，測試不可避免地會落后。

很難在開發(fā)周期的后期返回應(yīng)用程序代碼并修復(fù)每個(gè)可能的問題。審查和修復(fù)六個(gè)月前編寫的代碼中的漏洞并不容易，開發(fā)人員通常不希望僅僅因?yàn)榭赡艽嬖诎踩L(fēng)險(xiǎn)而解決有效的代碼。結(jié)果是經(jīng)常發(fā)布不安全的軟件，這增加了違規(guī)的風(fēng)險(xiǎn)。

解決方案不是放慢開發(fā)速度，以便安全性能夠趕上;相反，成功的應(yīng)用程序開發(fā)需要速度和安全性之間的同步性，速度和安全性都得到應(yīng)有的持續(xù)和同等的關(guān)注。速度和安全性之間的協(xié)調(diào)是轉(zhuǎn)向DevSecOps的原因。

許多公司正在做出這種轉(zhuǎn)變。Gartner 最近的一份報(bào)告揭示了幾個(gè)關(guān)鍵數(shù)據(jù)點(diǎn)，這些數(shù)據(jù)點(diǎn)表明了向此應(yīng)用程序安全最佳實(shí)踐過渡的加速：

到90年，2022%的軟件開發(fā)項(xiàng)目將聲稱遵循DevSecOps模型，而40年這一比例僅為2019%

到 70 年，2023% 的 DevSecOps 計(jì)劃將包含自動化安全漏洞和配置掃描，而 30 年這一比例僅為 2019%

到 60 年，2021% 的快速開發(fā)團(tuán)隊(duì)將嵌入 DevSecOps 實(shí)踐，而 20 年這一比例為 2019%

這些計(jì)劃很有希望，但對于許多組織來說，將安全性完全集成到設(shè)計(jì)和開發(fā)過程中的真正 DevSecOps 方法可能具有挑戰(zhàn)性。全面的應(yīng)用程序安全測試既耗時(shí)又耗費(fèi)資源。分析師必須評估所有攻擊面的漏洞，包括自定義代碼、第三方組件以及軟件應(yīng)用程序所在的網(wǎng)絡(luò)。

AppSec 團(tuán)隊(duì)需要運(yùn)行各種工具，包括：

靜態(tài)應(yīng)用程序安全測試 （SAST） 工具

動態(tài)應(yīng)用程序安全測試 （DAST） 工具

交互式應(yīng)用程序安全測試 （IAST） 工具

軟件組合分析 （SCA） 工具

威脅建模工具

除了運(yùn)行上面列出的工具外，AppSec 團(tuán)隊(duì)還使用方法，例如：

滲透測試

手動代碼審查

網(wǎng)絡(luò)漏洞分析

漏洞賞金

這些工具和審查通常在不同的時(shí)間和頻率運(yùn)行，具體取決于給定項(xiàng)目在軟件開發(fā)生命周期 （SDLC） 中的位置。許多 AppSec 工具的配置和運(yùn)行都很復(fù)雜。載入和維護(hù)需要時(shí)間，我們鼓勵(lì) AppSec 團(tuán)隊(duì)在同一類別中運(yùn)行多個(gè)工具，例如多個(gè) SAST 工具和 DAST 工具。一個(gè)軟件開發(fā)項(xiàng)目在SDLC的過程中可能需要幾十種工具，每個(gè)工具都有自己的用戶界面（更不用說特殊性了）。

通常，相同的工具用于多個(gè)項(xiàng)目，需要多個(gè)配置。不相互集成的工具會產(chǎn)生不一致的結(jié)果，報(bào)告格式不同。識別誤報(bào)以及關(guān)聯(lián)結(jié)果并確定其優(yōu)先級可能需要數(shù)周（或更長時(shí)間）的時(shí)間。

此外，許多企業(yè)管理多個(gè)構(gòu)建服務(wù)器。例如，除了 TeamCity、Azure 和其他服務(wù)的多個(gè)實(shí)例之外，可能還有數(shù)百個(gè) Jenkins 服務(wù)器。如果沒有編排，就不可能將應(yīng)用程序安全性烘焙到這些系統(tǒng)中的每一個(gè)系統(tǒng)中。

使問題更加復(fù)雜的是安全團(tuán)隊(duì)成員與開發(fā)人員的比例較低。開發(fā)人員的數(shù)量超過安全團(tuán)隊(duì)成員的比例為 100：1。當(dāng)您考慮每個(gè)開發(fā)人員的工作速度時(shí)，安全性沒有太多機(jī)會識別和修復(fù)所有潛在漏洞。

難怪 AppSec 無法跟上開發(fā)團(tuán)隊(duì)的步伐并有效地跟蹤漏洞。

解決方案：使用 ASOC 實(shí)現(xiàn)應(yīng)用安全自動化和編排

組織需要一種方法來集中和協(xié)調(diào)所有開發(fā)管道中的 AppSec 測試，使其成為可擴(kuò)展、可重復(fù)和自動化的流程。這允許安全性以 DevOps 的速度移動并停止阻塞開發(fā)管道。

ASOC 是實(shí)現(xiàn)自動化和可擴(kuò)展性的解決方案。由于我們已經(jīng)在本系列的第一篇文章中詳細(xì)介紹了 ASOC，因此我們將只關(guān)注實(shí)現(xiàn)可擴(kuò)展性的方面。

配器

業(yè)務(wù)流程可提高 AppSec 測試的速度，并確保運(yùn)行所有適當(dāng)?shù)臏y試。業(yè)務(wù)流程可自動執(zhí)行掃描過程，以確保特定工具始終以特定間隔跨多個(gè)生成服務(wù)器運(yùn)行。ASOC 工具分析源代碼以識別使用的語言，然后自動找出要為特定應(yīng)用程序運(yùn)行的相應(yīng) AppSec 工具。這將創(chuàng)建一個(gè)一致且標(biāo)準(zhǔn)化的流程，無論有多少個(gè)不同的開發(fā)團(tuán)隊(duì)正在處理不同的項(xiàng)目。

工具編排為 AppSec 測試提供了標(biāo)準(zhǔn)化的自動化流程，從而可以更輕松地將新應(yīng)用程序載入安全管道。它還減少了安裝、配置和更新 AppSec 測試工具所需的時(shí)間。換句話說，編排允許 AppSec 團(tuán)隊(duì)根據(jù)需要擴(kuò)展其測試活動。

關(guān)聯(lián)和重復(fù)數(shù)據(jù)刪除

ASOC 工具自動運(yùn)行、收集和關(guān)聯(lián)來自每種 AppSec 工具和測試方法的結(jié)果，包括手動審查、漏洞賞金、源代碼分析器、自動和手動滲透測試、軟件組合分析器和網(wǎng)絡(luò)漏洞評估器。這減少了 AppSec 團(tuán)隊(duì)需要查看的結(jié)果數(shù)量。

優(yōu)先次序

智能自動化允許 AppSec 團(tuán)隊(duì)使用以前的原始結(jié)果和修復(fù)活動為每個(gè)應(yīng)用程序選擇安全測試工具的最佳組合。可以根據(jù)應(yīng)用程序的關(guān)鍵性、法規(guī)合規(guī)性要求和整體組織功能，針對每個(gè)開發(fā)管道優(yōu)化每個(gè) AppSec 工具的規(guī)則集。

Code Dx 分類助手是一個(gè) ASOC 工具，可進(jìn)一步改進(jìn)自動化過程。機(jī)器學(xué)習(xí)分類器根據(jù)先前的決策了解要處理的問題和漏洞。會審助手是專門為每個(gè)組織量身定制的，可減少誤報(bào)、干擾或安全團(tuán)隊(duì)成員必須分類的不太重要的結(jié)果的數(shù)量。每自動分類 240 個(gè)結(jié)果，您的組織就可以節(jié)省相當(dāng)于全職員工一周的時(shí)間。

集成和集中管理

ASOC 工具提供與 DevOps 的完全集成，無縫融入持續(xù)集成/持續(xù)交付 （CI/CD） 管道。與 Jira 等問題跟蹤工具集成后，開發(fā)人員可以在其首選的工作環(huán)境中進(jìn)行修復(fù)。開發(fā)人員可以在他們已經(jīng)使用的工具和環(huán)境中獲得有關(guān)安全相關(guān)問題的即時(shí)反饋。

ASOC 工具可讓您的 AppSec 團(tuán)隊(duì)管理敏感信息（如工具憑據(jù)和應(yīng)用程序登錄）的傳遞。它還監(jiān)控工具故障，并確保工具正確配置和更新。

ASOC 允許 AppSec 團(tuán)隊(duì)在集中式系統(tǒng)中報(bào)告和審核所有三個(gè)攻擊面（自定義代碼、第三方組件和網(wǎng)絡(luò)）。

DevOps 不會放慢速度，但 ASOC 工具使安全性能夠擴(kuò)展 AppSec 流程并快速移動，而不會讓問題在未被發(fā)現(xiàn)或未解決的情況下溜走。

審核編輯：郭婷