DevSecOps的未來

■ Gunter Ollmann

如果說DevOps代表了人員、流程與技術的組合，以不斷為客戶提供價值，那么DevSecOps則代表了這些價值與安全性的融合。將安全嵌入到DevOps中的理念顯然是明智的也是必要的，但是如果僅僅通過附加一個不同的標簽就說是融合，那不是真正的融合，倒像是一種“乳化作用”——看似相溶但實際并未溶合在一起。

RSAC 2020期間舉辦的創新沙盒競賽已經落下帷幕，但由此帶來的熱點話題歷來是安全圈里爭論的焦點，該競賽中有好幾家與應用安全及開發安全密切相關，可見，人們對DevSecOps的競逐還將持續下去。

DevSecOps在整個開發過程中都包含離散的安全元素和功能。“安全即代碼”（Security as Code）是開發和安全運營團隊都交口稱贊的。但是，當仔細考量時，DevSecOps的安全性元素是離散的，打個比方，猶如是懸浮在水中的微小而不相溶的油滴一樣，就像前面提到的“乳化”一樣混合而不是無形地纏繞在DevOps的結構中。

當前的DevSecOps大致可分為兩個核心功能：在整個持續集成和持續部署（Continual Integration and Continual Deployment，CI/CD）工作流程中，自動檢查和防控已知和潛在的安全漏洞，以及對安全生成的測試流程運行監控和響應。

具體來說，我們將來自CI/CD工作流的應用與其他層的離散安全工具“包裹”起來，通過監控、警告防御各種威脅，與工作流內部相比，可以更經濟、更可靠地阻止外部威脅。這些安全層幾乎總是獨立于其所防御的應用而運行。如果我們要“提升”安全性并將DevSecOps回滾到DevOps，則需要對此進行更改。

盡管安全運營（SecOps）團隊在管理和響應由其邊界、服務器和行為防御系統生成的警告方面變得越來越高效，但仍需要將相同的測試、響應工作流和決策制定納入CI/CD工作流程以及應用本身，以幫助企業成功應對不斷變化的威脅，例如對抗性AI、數據湖污染（Data Lake Tainting）和行為中毒（Behavioral Poisoning）。

太多的DevSecOps工作流程依賴于人員。這其實是一種障礙，當攻擊者改用較新的自動化攻擊或基于AI的攻擊時，系統漏洞和數據泄露問題在修復、防御和應用補丁之前將反復發生。

未來的模式將不再是一個個“保護代碼”和“保護應用”的獨立操作，而是進入自我防護應用領域。

聽起來很宏偉，但是要想保護應用安全，還有一些核心要素和機會需要發展。

?來自構成應用的安全技術的遙測（Telemetry）需要對應用程序和CI/CD工作流程可用且可消耗。

?應用必須做到何時外部安全工具和監測工具在受到攻擊時發出警告，并能夠在有利時做出響應。例如，一個應用可能能夠安全地解析資金轉賬請求，但是由于知道WAF在之前500毫秒內由于同一會話的惡意SQL注入有效載荷而識別并阻止了之前的12個HTTP POST提交，因此它可以利用某些信息（可能是通過欺騙攻擊者提供虛假且可追溯的證據）來處理第13次轉移和用戶會話。

?安全技術需要對威脅和行為的術語、危害程度和影響進行標準化。通過對數據連接器和遙測進行標準化，新一代基于云的SIEM能夠提供一定程度的（特定供應商的）標準化，并且成為CI/CD和應用消耗的實時安全測試的來源 。應用開發框架需要了解此術語，并且理想情況下，應預先配備庫和函數以響應最佳實踐。

?通過越來越多的采用和融合AI，CI/CD工作流程可以加快工作流程對安全測試做出響應的速度。例如，基于服務器的安全代理識別內存溢出和隨后的不必要的進程啟動，而SIEM能夠重構會話序列以突出顯示事務字符串（0-day漏洞利用）。一個智能且自動化的CI/CD流程應能夠使用該信息來識別易受攻擊的代碼并糾正邏輯缺陷或錯誤，并對實時應用進行更新及修復，而無需開發人員參與。

安全責任必須并且將繼 續“測試左 移”（Shift Left）。為此，安全測試需要既可訪問又可并入應用和DevOps工作流程中，并且開發人員本身要在集成信息方面有著深入的了解。更好的開發人員工具（例如安全的編碼語言和框架、可訪問的最佳實踐庫和功能，以及智能的在線開發人員指南和校正工具）將有助于縮小差距。

快速發展的人工智能和機器學習技術如果合并到CI/CD工作流中，將能夠加快安全集成和安全部署的步伐。這其中仍有大量工作要做，今后，創新型公司將在這一領域有很大的機會為流程增加更大的價值。

同時，CISO和DevOps領導者應努力消除CI/CD工作流程中的人為障礙。隨著人工智能技術的發展，攻擊者也在通過自動化方式來提高攻擊速度，這使得未來的防御和響應將以毫秒為單位，而不是現在的幾天和幾周時間。