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可以檢測應用程式依賴的第三方軟體元件中的漏洞。

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

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

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

選型原則

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

個人看法

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

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

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