DevSecOps測試介紹

把Sec塞進DevOps不只是技術與工具變更那么簡單，更重要的是思維方式和內部流程的轉變，推進DevSecOps的關鍵原則是：別給人添麻煩。

《Gartner 2017研究報告：DevSecOps應當做好的十件事》和《Gartner 2019研究報告：DevSecOps應當做好的十二件事》兩篇研究報告中都對成功實施DevSecOps進行了研究。兩篇報告一致認為實施DevSecOps的關鍵挑戰和第一要素是：“安全測試工具和安全控制過程能夠很好的適應開發人員，而不是背道而馳”。安全團隊想要將安全測試或安全控制成功的融入在DevOps中的前提是：

不要試圖改變程序員和測試人員的工作方法，也不要去增加他們額外的工作負擔。

否則你將破壞DevOps的協作性和敏捷性，注定會成為眾矢之的，最終無法落地。由于破壞DevOps的協作性和敏捷性而失敗的慘痛案例筆者身邊就有好幾個。

應用安全測試在CI/CD軟件開發周期中的集成點

WEB應用安全測試目前在市場上有眾多的解決方案，其中最老牌、應用最為廣泛的應屬SAST和DAST這兩類的測試工具，通過在源代碼 (SAST) 或公開對外接口 (DAST) 上運行安全掃描，可以在應用上線之前識別并糾正許多漏洞。

然而隨著 DevSecOps 被廣泛接納，Gartner 在 2017 年的研究報告中明確提倡用 Interactive Application Security Testing (IAST) 替換 SAST 和 DAST，原文如下：

考慮交互式應用安全測試 (IAST) 替代傳統的靜態應用安全測試（SAST）和動態應用安全測試 (DAST) 是可行的，我們建議這么做。IAST 是在DAST基礎上的一種改進形式，測試過程更加可視化，包括內部和外部的。IAST 綜合了 DAST 和 SAST 的優勢，在確保測試代碼覆蓋率的基礎上盡可能的做到了減少誤報。

接下來筆者分析一下 Gartner 為何如此推崇在 DevSecOps 中采用 IAST 來替換 SAST 和 DAST。

1、SAST 因效率差、誤報率高無法敏捷的融入到 DevOps 中

首先我們對 SAST 實現原理進行簡單分析，SAST 一般實現都是在不運行代碼的情況下通過詞法分析、語法分析、控制流、數據流分析等技術對源代碼進行掃描，并利用復雜的檢查規則匹配發現與定位缺陷，最后生成結果。

雖然 SAST 目前可以集成到開發者IDE環境并融入到 DevOps 中，但 SAST 往往需要比較長的掃描分析時間，實時性比較差，同時誤報率也比較高，需要投入大量的安全團隊的資源來去除這些誤報。

除此之外，SAST 針對應用程序引用的第三方開源組件、開源框架也無法有效識別已知存在安全風險。

總之，SAST 實際應用在 DevSecOps 環境中并不輕松，除非你擁有非常充裕并且經驗豐富的安全團隊對其進行不斷的優化、開發與維護。

2、DAST因適應場景有限及嚴重影響正常業務功能測試而無法融入到DevOps中

DAST 是目前應用最為廣泛的 WEB 應用安全測試工具，市面上有些廠商把 DAST 經過改造偷換概念自稱 IAST。IAST 產品魚龍混雜，筆者身邊就有因為選用了此類產品導致無法無縫融入 DevOps 的情況，為大家避免再次踩坑本文會花較大篇幅用于討論 DAST 相關技術。

DAST 的原理相對比較簡單，一般分為以下幾個階段：首先 DAST 利用爬蟲技術獲取盡可能全的應用URL后進行去重，然后分析和提取外部可能的輸入點；其次針對每個URL中的輸入點替換成不同漏洞類型的 Payload，實質上是篡改原始數據報文輪番地毯式向WEB應用重放 HTTP/HTTPS 報文，最終 DAST 收到WEB應用的響應報文對其分析來判斷漏洞是否存在。

由于爬蟲技術的天生缺陷，DAST 面臨著諸多的挑戰。首當其沖的是爬蟲無法爬取應用完整 URL 的問題。如：當應用具有 AJAX、Token、驗證碼、獨立 API 等情況，或者應用執行必須依賴上步執行結果邏輯的場景，比如在面對密碼重置、交易支付等場景應用時均無法進行有效的覆蓋。為了解決 DAST 爬蟲技術的缺陷開始對其進行改造，通常將 WEB/APP 客戶端訪問應用時的流量進行代理，方法有通過瀏覽器配置代理、*** 流量代理等方式。對于非加密環境還可以通過交換機流量鏡像、應用訪問日志導入、在應用服務器上部署客戶端獲取流量等幾種彌補方案，通過以上補救方案后 DAST 就可以規避一些爬蟲技術的缺陷。

分析完 DAST 爬蟲缺陷我們再來分析查找輸入點和 Payload 替換階段的缺陷。

如今在互聯網上的交易類 WEB/APP 應用為了保證數據的保密性和完整性必須在傳輸過程中對數據采用加密、加簽的方法，然而這對 DAST 這類安全測試工具幾乎是毀滅性打擊。

根本原因在于 DAST 無法得知其測試應用所采用的加密算法與密鑰，不能還原成明文，只看到一堆亂碼密文無從獲取有效的輸入點，替換 Payload 就更無從談起了。對于應用只有加簽的場景對于 DAST 來說即使獲取了有效的輸入點，篡改原始報文替換 Payload 重放數據報文也不會被應用接受或處理。

那么假設 DAST 在面對沒有采用加密、加簽等場景的 WEB 應用時，是否可以無縫融入 DevOps 實現 DevSecOps 測試階段的自動化安全測試呢？各位看官,且聽我慢慢道來。

首先我們假設 DAST 已經通過了良好的改造不再利用 DAST 爬蟲技術來獲取WEB應用的 URL（改良后有些廠商自稱IAST~_~，且稱之為偽 IAST），而是通過各種流量收集方式解決了獲取應用 URL 的問題。那么接著 DAST 開始進入篡改原始報文，將輸入點的值替換成 Payload，并重放數據報文的過程，然而 DAST 不能提前預知 URL 的輸入點會存在什么類型的安全漏洞因此只能將所有不同漏洞類型的 Payload 全數依次替換后重放數據報文。

這會造成什么后果？服務器流量被放大 20 倍，加資源勉強解決了，但掃描速度變得巨慢，我等也敢怒不敢言。因重放數據導致重復提交數據，使得自動化功能測試失敗（產生了臟數據、功能異常等問題），測試小姐姐跳腳了，這下忍無可忍了。情急之下靈光一現：采用延時檢測或定時計劃檢測功能，把漏洞檢測時間放在小姐姐測試結束后進行，不就 OK 了？！于是，嘴角一上揚微微一笑開始配置晚上 12 點后開始檢測。

第二天早上迫不及待登錄 DAST（偽IAST）系統查看掃描結果，顯示屏和大腦一片空白，漏洞呢？原來應用系統登錄會話超時、有些功能需要一次性Token，有些需要短信驗證，有些接口只能特定的IP才能訪問，有些需要回答一個隨機問題后才能進入下個階段……，這些都無解啊！！！

看形式只能使出必殺技，劍走偏鋒。喊上研發部門開會，為能使 DAST（偽IAST）正常工作，提出讓研發同步維護兩個版本，除正常功能外還需要再增加一個版本。這個版本要求不能有加密、會話不過期、沒有驗證碼、沒有一次性 Token、沒有簽名、沒有……話還沒說完研發老大拍案而起怒懟：老子 996 為了趕項目進度，你 MMP 還要來添堵，想讓我們 120 嗎？

最終結局可想而知，領導叫停 DAST（偽IAST）在功能測試階段的應用，美好的安全測試向左移，安全無縫融入到 DevOps，DevSecOps 測試階段的自動化安全測試夢想就這樣被破滅了。當然并不能說 DAST（偽IAST）一無是處，DAST（偽IAST）只是不太適用在DevSecOps測試階段的自動化安全測試或一些加密、加簽的一些復雜應用而已。

3、被動型IAST是DevSecOps測試階段實現自動化安全測試的最佳工具

首先讓我們來看一下Gartner對IAST的定義：

交互式應用程序安全測試（IAST）結合了靜態應用程序安全測試（SAST）和動態應用程序安全測試（DAST）技術。這旨在通過SAST和DAST技術的交互，提高應用程序安全測試的準確性。IAST 將 SAST 和 DAST 中優勢部分集成到了一個解決方案中。這種方法可以非常容易確認漏洞是否真實存在，并確定其在應用程序代碼中的漏洞代碼位置。

看到這里大家終于明白為什么說改良后的DAST是偽IAST了吧。根據Gartner的定義，IAST需要結合SAST和DAST兩者的技術優勢，最終檢測出的漏洞詳情應非常容易確認是否真實存在，同時需要定位到存在安全風險的代碼位置。

IAST 漏洞詳情中都會包括漏洞形成的應用內部數據流的詳細傳播過程，以及漏洞存在的代碼位置，這都是為了能讓安全人員更方便的確認漏洞的真實性，讓開發人員更容易理解漏洞的形成原因，同時使得開發人員自主的去修復漏洞更加容易。

目前市面上 IAST 根據實現原理不同可以兩類，主動型 IAST 和被動型 IAST。這兩類工具的共同點是對應用開發語言關聯性非常緊密，均需要部署 Agent。Agent 會將可能引起安全風險的底層函數進行 hook。

主動型 IAST 結合了 DAST 的功能，篡改原始報文替換 Payload 進行數據報文重放，并在底層函數 hook 點實時監聽，當監聽到 Payload 進入函數 hook 點則判斷漏洞存在。

主動型IAST的優勢是幾乎不存在誤報，檢測速度快于 DAST，但和 DAST一樣沒有辦法適用于有加密、加簽、一次性 Token 等復雜應用場景，同時還存在產生臟數據、破壞功能測試結果等問題。因此主動型 IAST 也不能無縫融入到 DevOps，實現 DevSecOps 測試階段自動化安全測試。

最后來看看被動型 IAST，被動型 IAST 在漏洞檢測過程中始終保護靜默監聽，不會主動去重放報文。被動型 IAST 可以比 SAST、DAST 檢測更多的通用漏洞，因為 Agent 可以查看應用的所有代碼、應用程序運行時控制流、應用程序數據流信息、環境配置信息、HTTP 請求和響應、使用的框架和其他組件、后端連接信息、數據庫連接等等。那么被動型 IAST 是如何檢測漏洞的呢？

被動型 IAST 判斷漏洞的主要原理實際上也并不復雜：被動型 IAST 認為外部傳入的輸入參數在沒有經過安全過濾的前提下，又傳播到了一個可能引起安全漏洞的風險函數，則會判定為漏洞存在，當然在實際商用產品中會加入很多其他邏輯。

原理

被動型IAST并不關心也不需要關心應用外部傳入的輸入參數是否加密，天然支持具有加密傳輸的場景。

其次我們可以看到：被動型 IAST 檢測過程不需要重放數據報文，也就天然支持具有加簽、一次性Token、短信驗證、生物驗證等等復雜應用場景，同時不會影響正常的業務功能測試。

被動型 IAST 另外一個特色是檢測效率奇高，精準實時的漏洞檢測，可與功能操作同步完成安全測試。

最后，被動型 IAST 不僅可以解決應用通用漏洞檢測問題，還能對應用引入的開源組件進行風險管理，這一點對應用開發安全來說也特別的重要。

當然 IAST 并非沒有缺陷，IAST 主要問題在于不同語言開發的 WEB 應用需要有不同類型的 Agent，特別是研發被動型 IAST 技術難度和投入都非常巨大，這也是為什么被動型 IAST 商用產品寥寥無幾的重要原因。

另外 IAST 沒有爬蟲技術也不主動重放數據報文，因此無法檢測沒有安裝 Agent 的 WEB 應用，對于需要進行遠程漏洞掃描的場景 IAST 無法適用。

總結一下

被動型 IAST 可以適用于任何加密、加簽、一次性資源等復雜場景的應用，同時檢測過程安全無危害，是 DevSecOps 測試階段實現自動化安全測試的最佳工具。

最后讓我們回顧一下Gartner報告中對DevSecOps的概述：

將安全性集成到 DevOps 中以交付 DevSecOps 需要改變思維方式，流程和技術。安全和風險管理領導者必須堅持 DevOps 的協作、敏捷性，以便安全測試在開發中實現無縫集成，從而使DevSecOps中的 ‘安全’ 透明。

所以在實際推進DevSecOps時應始終堅持“協作、敏捷、透明”，另外并不只是技術與工具變更，更重要的是思維方式和內部流程的轉變才能真正達到預期。