近幾年，伴隨云計算、容器技術以及 DevOps 的普及，DevSecOps 作為糅合了開發、安全及運營理念的全新方法，其關注熱度持續上升，并在全球范圍內得到廣泛應用。目前 IAST 被部分業內人士看作一種“更適合 DevSecOps 流程 構建”的應用程序安全檢測技術，受到行業的更多關注。

　　那么 IAST 是否真的更適合 DevSecOps 流程構建？它能夠提供哪些核心能力和關鍵技術，以及有哪些局限性？

　　要了解 IAST 是否真的更適合 DevSecOps 流程構建，首先要弄明白 DevSecOps 到底是什么。根據 Gartner 定義，DevSecOps（即 Development、Security 和 Operations）是指在不減少敏捷度和開發者效率，或在不要求開發者離開現有工具鏈的情況下，將安全盡可能無縫、無感知地集成進 IT 和 DevOps 開發中。

　　DevSecOps 有三個核心點：一是便于集成，安全工具可以很方便的與現有的 IT 或 DevOps 流程對接和打通，這也是實現 DevSecOps 的前提條件；二是無感知，要求安全工具對已有的 DevOps 流程不能產生任何的影響和干擾；三是在研發階段解決安全問題，而不是像傳統開發流程一樣，在軟件上線后由安全人員檢測問題，再反饋給研發人員來解決問題。問題越早的檢測和修復，企業的整體修復成本就越低，這也是 DevSecOps 的核心目的之一。目前來看，DevSecOps 在落地時遇到的主要痛點和難點也體現在這三個點上。那么，更適合 DevSecOps 流程構建的 IAST 到底是什么？有哪些特點？

　　IAST 是交互式應用程序安全測試（Interactive Application Security Testing），是一種新的應用程序安全測試方案，通過在服務端部署 Agent ，收集、監控應用程序運行時的函數執行、數據傳輸等信息，然后根據污點跟蹤算法、值傳遞算法等一系列算法進行漏洞的識別。

　　IAST 是一種應用程序運行時的漏洞檢測技術，所以它具備了 DAST 中檢測結果準確的特征；此外，IAST 采集到數據在方法內部的流動后，通過污點跟蹤算法來進行漏洞檢測，用算法來進行漏洞檢測，所以檢測結果也具備了 SAST中全面性的特征。

　　同時因為 IAST 安裝在應用程序內部，安全人員可以拿到類似于源碼級漏洞報告，這種漏洞結果對于開發人員很友好，可以方便開發人員進行漏洞修復。綜合來看，IAST 具有高檢出率、低誤報率、檢測報告詳細便于排查等一系列優勢，可以很好地在 DevSecOps 流程中解決痛點和難點。

　　如何用 IAST 來構建 DevSecOps ，或者說是構建 DevSecOps 流程時，IAST 必須具備哪些功能才能支撐這個流程的構建。大概有三點。第一點，IAST 必須柔和地嵌入 DevOps 流程，即十分便利地與 CI/CD 流程對接，包括與 Jenkins 、Gitlab 等工具打通等；第二點，當IAST 和 DevOps 流程對接時，需要做版本的控制，支持在 Agent 端直接指定項目名稱和版本，進行后續的版本跟蹤，以及版本的漏洞對比等；第三點，IAST可通過漏洞復測與回歸測試，驗證此前發現的漏洞是否依舊存在。

　　那么，IAST 的核心能力有哪些？其在具體的場景應用中又會存在哪些局限性？IAST 本質是做漏洞檢測，其核心能力主要包括四點：一是實時的漏洞檢測，保證不影響 DevOps 的原有效率；二是第三方組件的梳理和漏洞檢測，保證應用避免供應鏈的攻擊；三是靈活的漏洞檢測邏輯，讓用戶在使用內置檢測邏輯的同時，很方便地配置出具有業務屬性的特定檢測邏輯，來做業務層面的漏洞檢測；四是極低的運營成本，IAST 在企業內部使用時，一定是需要持續運營的，當出現了 IAST 沒有覆蓋到的漏洞情況時，可以用最低的成本來完善檢測策略和檢測邏輯，保證漏洞的檢出。

　　IAST 的局限性主要體現在 IAST 的內置漏洞策略有限、且無業務屬性，無法保證檢測所有的安全風險；推薦在上線前通過白盒、灰盒、黑盒、人工滲透測試一起來檢測漏洞，然后將 IAST 沒有覆蓋到的漏洞策略補充進來；上線后可通過外部的眾測、SRC 運營等手段，更全面地發現安全風險，同時將漏洞策略補充到 IAST 中，做后續的自動化測試。

更多信息可以來這里獲取==>>電子技術應用-AET<<