把Sec塞進DevOps不只是技術與工具變更那么簡單，更重要的是思維方式和內部流程的轉變，推進DevSecOps的關鍵原則是：別給人添麻煩。
創(chuàng)新互聯(lián)專注于鄂城企業(yè)網(wǎng)站建設,成都響應式網(wǎng)站建設公司,商城網(wǎng)站建設。鄂城網(wǎng)站建設公司,為鄂城等地區(qū)提供建站服務。全流程按需設計網(wǎng)站，專業(yè)設計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務
《Gartner 2017研究報告：DevSecOps應當做好的十件事》和《Gartner 2019研究報告：DevSecOps應當做好的十二件事》兩篇研究報告中都對成功實施DevSecOps進行了研究。兩篇報告一致認為實施DevSecOps的關鍵挑戰(zhàn)和第一要素是：“安全測試工具和安全控制過程能夠很好的適應開發(fā)人員，而不是背道而馳”。安全團隊想要將安全測試或安全控制成功的融入在DevOps中的前提是：
否則你將破壞DevOps的協(xié)作性和敏捷性，注定會成為眾矢之的，最終無法落地。由于破壞DevOps的協(xié)作性和敏捷性而失敗的慘痛案例筆者身邊就有好幾個。
應用安全測試在CI/CD軟件開發(fā)周期中的集成點
WEB應用安全測試目前在市場上有眾多的解決方案，其中最老牌、應用最為廣泛的應屬SAST和DAST這兩類的測試工具，通過在源代碼 (SAST) 或公開對外接口 (DAST) 上運行安全掃描，可以在應用上線之前識別并糾正許多漏洞。
然而隨著 DevSecOps 被廣泛接納，Gartner 在 2017 年的研究報告中明確提倡用 Interactive Application Security Testing (IAST) 替換 SAST 和 DAST，原文如下：
接下來筆者分析一下 Gartner 為何如此推崇在 DevSecOps 中采用 IAST 來替換 SAST 和 DAST。
1、SAST 因效率差、誤報率高無法敏捷的融入到 DevOps 中
首先我們對 SAST 實現(xiàn)原理進行簡單分析，SAST 一般實現(xiàn)都是在不運行代碼的情況下通過詞法分析、語法分析、控制流、數(shù)據(jù)流分析等技術對源代碼進行掃描，并利用復雜的檢查規(guī)則匹配發(fā)現(xiàn)與定位缺陷，最后生成結果。
雖然 SAST 目前可以集成到開發(fā)者IDE環(huán)境并融入到 DevOps 中，但 SAST 往往需要比較長的掃描分析時間，實時性比較差，同時誤報率也比較高，需要投入大量的安全團隊的資源來去除這些誤報。
除此之外，SAST 針對應用程序引用的第三方開源組件、開源框架也無法有效識別已知存在安全風險。
總之，SAST 實際應用在 DevSecOps 環(huán)境中并不輕松，除非你擁有非常充裕并且經驗豐富的安全團隊對其進行不斷的優(yōu)化、開發(fā)與維護。
2、DAST因適應場景有限及嚴重影響正常業(yè)務功能測試而無法融入到DevOps中
DAST 是目前應用最為廣泛的 WEB 應用安全測試工具，市面上有些廠商把 DAST 經過改造偷換概念自稱 IAST。IAST 產品魚龍混雜，筆者身邊就有因為選用了此類產品導致無法無縫融入 DevOps 的情況，為大家避免再次踩坑本文會花較大篇幅用于討論 DAST 相關技術。
DAST 的原理相對比較簡單，一般分為以下幾個階段：首先 DAST 利用爬蟲技術獲取盡可能全的應用URL后進行去重，然后分析和提取外部可能的輸入點；其次針對每個URL中的輸入點替換成不同漏洞類型的 Payload，實質上是篡改原始數(shù)據(jù)報文輪番地毯式向WEB應用重放 HTTP/HTTPS 報文，最終 DAST 收到WEB應用的響應報文對其分析來判斷漏洞是否存在。
由于爬蟲技術的天生缺陷，DAST 面臨著諸多的挑戰(zhàn)。首當其沖的是爬蟲無法爬取應用完整 URL 的問題。如：當應用具有 AJAX、Token、驗證碼、獨立 API 等情況，或者應用執(zhí)行必須依賴上步執(zhí)行結果邏輯的場景，比如在面對密碼重置、交易支付等場景應用時均無法進行有效的覆蓋。為了解決 DAST 爬蟲技術的缺陷開始對其進行改造，通常將 WEB/APP 客戶端訪問應用時的流量進行代理，方法有通過瀏覽器配置代理、*** 流量代理等方式。對于非加密環(huán)境還可以通過交換機流量鏡像、應用訪問日志導入、在應用服務器上部署客戶端獲取流量等幾種彌補方案，通過以上補救方案后 DAST 就可以規(guī)避一些爬蟲技術的缺陷。
分析完 DAST 爬蟲缺陷我們再來分析查找輸入點和 Payload 替換階段的缺陷。
根本原因在于 DAST 無法得知其測試應用所采用的加密算法與密鑰，不能還原成明文，只看到一堆亂碼密文無從獲取有效的輸入點，替換 Payload 就更無從談起了。對于應用只有加簽的場景對于 DAST 來說即使獲取了有效的輸入點，篡改原始報文替換 Payload 重放數(shù)據(jù)報文也不會被應用接受或處理。
那么假設 DAST 在面對沒有采用加密、加簽等場景的 WEB 應用時，是否可以無縫融入 DevOps 實現(xiàn) DevSecOps 測試階段的自動化安全測試呢？各位看官,且聽我慢慢道來。
首先我們假設 DAST 已經通過了良好的改造不再利用 DAST 爬蟲技術來獲取WEB應用的 URL（改良后有些廠商自稱IAST~_~，且稱之為偽 IAST），而是通過各種流量收集方式解決了獲取應用 URL 的問題。那么接著 DAST 開始進入篡改原始報文，將輸入點的值替換成 Payload，并重放數(shù)據(jù)報文的過程，然而 DAST 不能提前預知 URL 的輸入點會存在什么類型的安全漏洞因此只能將所有不同漏洞類型的 Payload 全數(shù)依次替換后重放數(shù)據(jù)報文。
這會造成什么后果？服務器流量被放大 20 倍，加資源勉強解決了，但掃描速度變得巨慢，我等也敢怒不敢言。因重放數(shù)據(jù)導致重復提交數(shù)據(jù)，使得自動化功能測試失?。óa生了臟數(shù)據(jù)、功能異常等問題），測試小姐姐跳腳了，這下忍無可忍了。情急之下靈光一現(xiàn)：采用延時檢測或定時計劃檢測功能，把漏洞檢測時間放在小姐姐測試結束后進行，不就 OK 了？！于是，嘴角一上揚微微一笑開始配置晚上 12 點后開始檢測。
第二天早上迫不及待登錄 DAST（偽IAST）系統(tǒng)查看掃描結果，顯示屏和大腦一片空白，漏洞呢？原來應用系統(tǒng)登錄會話超時、有些功能需要一次性Token，有些需要短信驗證，有些接口只能特定的IP才能訪問，有些需要回答一個隨機問題后才能進入下個階段……，這些都無解啊?。。?/p>
看形式只能使出必殺技，劍走偏鋒。喊上研發(fā)部門開會，為能使 DAST（偽IAST）正常工作，提出讓研發(fā)同步維護兩個版本，除正常功能外還需要再增加一個版本。這個版本要求不能有加密、會話不過期、沒有驗證碼、沒有一次性 Token、沒有簽名、沒有……話還沒說完研發(fā)老大拍案而起怒懟：老子 996 為了趕項目進度，你 MMP 還要來添堵，想讓我們 120 嗎？
最終結局可想而知，領導叫停 DAST（偽IAST）在功能測試階段的應用，美好的安全測試向左移，安全無縫融入到 DevOps，DevSecOps 測試階段的自動化安全測試夢想就這樣被破滅了。當然并不能說 DAST（偽IAST）一無是處，DAST（偽IAST）只是不太適用在DevSecOps測試階段的自動化安全測試或一些加密、加簽的一些復雜應用而已。
3、被動型IAST是DevSecOps測試階段實現(xiàn)自動化安全測試的最佳工具
首先讓我們來看一下Gartner對IAST的定義：
看到這里大家終于明白為什么說改良后的DAST是偽IAST了吧。根據(jù)Gartner的定義，IAST需要結合SAST和DAST兩者的技術優(yōu)勢，最終檢測出的漏洞詳情應非常容易確認是否真實存在，同時需要定位到存在安全風險的代碼位置。
IAST 漏洞詳情中都會包括漏洞形成的應用內部數(shù)據(jù)流的詳細傳播過程，以及漏洞存在的代碼位置，這都是為了能讓安全人員更方便的確認漏洞的真實性，讓開發(fā)人員更容易理解漏洞的形成原因，同時使得開發(fā)人員自主的去修復漏洞更加容易。
目前市面上 IAST 根據(jù)實現(xiàn)原理不同可以兩類，主動型 IAST 和被動型 IAST。這兩類工具的共同點是對應用開發(fā)語言關聯(lián)性非常緊密，均需要部署 Agent。Agent 會將可能引起安全風險的底層函數(shù)進行 hook。
主動型 IAST 結合了 DAST 的功能，篡改原始報文替換 Payload 進行數(shù)據(jù)報文重放，并在底層函數(shù) hook 點實時監(jiān)聽，當監(jiān)聽到 Payload 進入函數(shù) hook 點則判斷漏洞存在。
主動型IAST的優(yōu)勢是幾乎不存在誤報，檢測速度快于 DAST，但和 DAST一樣沒有辦法適用于有加密、加簽、一次性 Token 等復雜應用場景，同時還存在產生臟數(shù)據(jù)、破壞功能測試結果等問題。因此主動型 IAST 也不能無縫融入到 DevOps，實現(xiàn) DevSecOps 測試階段自動化安全測試。
最后來看看被動型 IAST，被動型 IAST 在漏洞檢測過程中始終保護靜默監(jiān)聽，不會主動去重放報文。被動型 IAST 可以比 SAST、DAST 檢測更多的通用漏洞，因為 Agent 可以查看應用的所有代碼、應用程序運行時控制流、應用程序數(shù)據(jù)流信息、環(huán)境配置信息、HTTP 請求和響應、使用的框架和其他組件、后端連接信息、數(shù)據(jù)庫連接等等。那么被動型 IAST 是如何檢測漏洞的呢？
被動型 IAST 判斷漏洞的主要原理實際上也并不復雜：被動型 IAST 認為外部傳入的輸入?yún)?shù)在沒有經過安全過濾的前提下，又傳播到了一個可能引起安全漏洞的風險函數(shù)，則會判定為漏洞存在，當然在實際商用產品中會加入很多其他邏輯。
原理
被動型IAST并不關心也不需要關心應用外部傳入的輸入?yún)?shù)是否加密，天然支持具有加密傳輸?shù)膱鼍啊?/p>
其次我們可以看到：被動型 IAST 檢測過程不需要重放數(shù)據(jù)報文，也就天然支持具有加簽、一次性Token、短信驗證、生物驗證等等復雜應用場景，同時不會影響正常的業(yè)務功能測試。
被動型 IAST 另外一個特色是檢測效率奇高，精準實時的漏洞檢測，可與功能操作同步完成安全測試。
當然 IAST 并非沒有缺陷，IAST 主要問題在于不同語言開發(fā)的 WEB 應用需要有不同類型的 Agent，特別是研發(fā)被動型 IAST 技術難度和投入都非常巨大，這也是為什么被動型 IAST 商用產品寥寥無幾的重要原因。
另外 IAST 沒有爬蟲技術也不主動重放數(shù)據(jù)報文，因此無法檢測沒有安裝 Agent 的 WEB 應用，對于需要進行遠程漏洞掃描的場景 IAST 無法適用。
總結一下
被動型 IAST 可以適用于任何加密、加簽、一次性資源等復雜場景的應用，同時檢測過程安全無危害，是 DevSecOps 測試階段實現(xiàn)自動化安全測試的最佳工具。
最后讓我們回顧一下Gartner報告中對DevSecOps的概述：
將安全性集成到 DevOps 中以交付 DevSecOps 需要改變思維方式，流程和技術。安全和風險管理領導者必須堅持 DevOps 的協(xié)作、敏捷性，以便安全測試在開發(fā)中實現(xiàn)無縫集成，從而使DevSecOps中的 ‘安全’ 透明。
所以在實際推進DevSecOps時應始終堅持“協(xié)作、敏捷、透明”，另外并不只是技術與工具變更，更重要的是思維方式和內部流程的轉變才能真正達到預期。
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
