DevSecOps之應用安全測試工具及選型

上篇文章，有同學私信想了解有哪些DevSecOps工具，這裏整理出來，供大家參考（PS: 非專業安全人士，僅從DevOps建設角度，給出自己見解）

軟件中的漏洞和弱點很常見：84%的軟件漏洞都是利用應用層的漏洞。軟件相關問題的普遍性是使用應用安全測試（AST）工具的主要動機。通過使用AST工具，企業可以在軟件開發生命週期中快速地檢測潛在的安全問題，提高應用程序的可靠性和安全性，降低安全風險。

隨着越來越多的應用安全測試工具的出現，信息技術（IT）領導、開發人員和工程師可能會感到困惑——不知道哪些工具可以解決哪些問題。

如上圖所示，從下往上，成熟度和實現難度依次增大。

靜態應用程序安全測試

Static Application Security Testing (SAST)，僅通過分析或者檢查應用軟件源代碼或字節碼以發現應用程序的安全性漏洞，側重檢查代碼安全，如C/C++緩衝區溢出、身份認證與授權等, 避免產生可利用的弱點。
SAST 工具主要用於 SDLC 的編碼、構建和開發階段。

動態應用程序安全測試

Dynamic Application Security Testing (DAST)，通過運行程序來檢查應用軟件的安全性問題，側重從系統外部接口來進行鍼對性的測試，暴露應用程序接口的安全性漏洞。
DAST 是一種自動黑盒測試技術，測試這主要從外部進行測試, 它模仿黑客與您的 Web 應用或 API 交互的方式。它通過網絡連接和檢查應用的客戶端渲染來測試應用，就像滲透測試工具一樣。 DAST 工具不需要訪問您的源代碼或自定義來掃描堆棧。它們與您的網站交互，從而以較低的誤報率發現漏洞。

交互式應用程序安全性測試

Interactive Application Security Testing (IAST)，整合了SAST和DAST這兩種方法，可以發揮各自的優勢、降低誤報率，發現更多安全漏洞，從而提高安全性測試效率。
交互式應用安全測試就是通過把安全工具的代理嵌入到應用程序裏面，從而在測試應用程序的時候，這個安全代碼能夠監控到應用系統的網絡內容，堆棧等信息，從而嗅探出系統在動態行爲下的安全漏洞, 內容具體到發生漏洞的代碼行。

軟件構成分析

Software Composition Analysis (SCA)，專門用於分析開發人員使用的各種源碼、模塊、框架和庫，以識別和清點應用系統（OSS）的組件及其構成和依賴關係，並識別已知的安全漏洞或者潛在的許可證授權問題，把這些風險排查在應用系統投產之前，以加快確定優先級和開展補救工作。
此外，它們還可無縫集成到 CI/CD 流程中，從構建集成直至生產前的發佈，持續檢測新的開源漏洞。大白話，找出軟件裏面的“科技與狠活”

應用程序安全測試編排

Application Security Testing Orchestration (ASTO)，隨着數據中心規模的不斷增大，網絡以及安全服務數量也隨之不斷的增長，安全運維更是難上加難。面對越來越複雜的網絡和安全場景，安全編排(Orchestration)工具應運而生，能夠安全自動化和服務編排，如可以連接諸如Splunk、QRadar等安全數據分析工具，利用其提供的大量安全事件數據，通過自動化的腳本，採取一系列的方法進行安全事件的響應。

應用程序漏洞關聯

ASTO 將軟件開發生命週期內的安全工具進行整合，尤其在 DevSecOps中發揮舉足輕重的作用，而AVC（Application Vulnerability Correlation，應用程序漏洞關聯）工具是指工作流與流程管理工具，讓軟件開發應用漏洞測試和修復實現流線化。
這些工具將各種安全測試數據源（SAST、DAST、IAST、SCA 、滲透測試與代碼審覈）融入到一箇中央化的工具中，AVC 工具能夠將安全缺陷形成中心化數據，進行分析，對補救方案進行優先級排序，實現應用安全活動的協作。

上面5、6點，屬於比較綜合的方案，大白話，從“安全”的視角，去看看研發活動的產出 （代碼，製品，環境等等資產）有沒有安全漏洞風險，並且歸類融合去重統一，實現思路上，有點像DevOps流水線，劍走偏鋒。目前，國外類似的解決方案有一些，國內很少，我也在持續跟蹤研究中。

安全測試工具適用階段

如下圖所示

• SAST適用於應用程序開發早期或集成/構建階段，提供代碼級別的反饋；
• IAST可以在應用程序的運行時進行安全測試，並提高漏洞的發現率；
• DAST適用於應用程序發佈前進行黑盒測試；
• SCA可以檢測應用程序依賴的第三方軟件組件中的漏洞。

綜合使用這些工具，可以在應用程序的開發、測試和部署階段及時發現和糾正潛在的安全漏洞。

如何選擇適合自己企業的安全工具

如下圖所示，根據研發活動的過程，我對相關的安全工作做了領域和業務的劃分，部分工具可能會貫穿多個階段。

選型原則

1. 你需要解決什麼問題？哪些階段是你關注的？
2. 工具的成本，是否有資金支持採購商業軟件？雖然開源的安全工具很多，不過“安全”是個嚴肅且專業的領域，商業軟件還是有很多“硬核”實力
3. 發現安全問題了，你是否能解決修復？這決定了，你是否會使用這些工具，更重要的是背後的運營流程，否則工具只是工具
4. 你所在的行業的要求是什麼？政府和機構的要求是什麼？
5. 選擇的安全工具是否能融入DevOps流水線？是否周邊生態插件豐富？是否支持二次開發？
6. 是否有專業的安全人士，能夠使用選中的工具，並駕馭？
   

個人看法

• 從實踐難易程度和成本最低來看， “ 編碼階段“ 應該是成本最低，工具最多（比如sonarqube 估計是下面圖中，你最熟悉的，爛大街的），離開發人員最近的階段。
• 從”安全“左移的角度，在”編碼階段“進行實施安全活動，從DevOps角度，浪費也是相對較少的。唯一不足，就是代碼階段的掃描，誤報率稍微高，見仁見智。
• ”容器安全“，也是一個值得關注的，由於雲原生普及，周邊生態豐富，可以選擇的餘地會多些，對於”中小企業“來說，成本最低。
• 如果你的組織不差錢，直接商業工具，這個不用質疑，你的甲方爸爸也不會差錢，他要的是放心。

最後，安全工具僅僅是個開始，如何把工具融於流程，並且落地得到切實的執行纔是難點。”安全“是個即”嚴肅“，又”專業“，同時又容易”被忽略“的活動，任重而道遠。

PS: 下面圖目前是V1.0版本，後續會持續更新 （圖中標記的工具，可以做些嘗試，開源的；不差錢的，請直接商業工具，專業的人做專業的事情）

參考：

• https://www.synopsys.com/zh-cn/glossary/what-is-devsecops.html
• https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers
• https://sdtimes.com/security/a-guide-to-devsecops-tools/
• 10 Types of Application Security Testing Tools: When and How to Use Them
• https://www.synopsys.com/zh-cn/software-integrity/security-testing/static-analysis-sast.html
• https://www.synopsys.com/software-integrity/security-testing/web-scanner.html
• https://www.synopsys.com/zh-cn/software-integrity/security-testing/interactive-application-security-testing.html
• https://www.synopsys.com/zh-cn/glossary/what-is-application-vulnerability-correlation.html