SAST和DAST之間實現真正協同作用的潛力來自您的SAST和DAST工具，這些工具以真正驅動安全設計應用程序安全方法的核心方式相互支持。所以它不是SAST vs DAST，而是DAST-SAST。

那么是如何運作的呢？讓我們從基礎開始講。

什么是SAST？

SAST是靜態應用程序安全測試，即在不運行應用程序的情況下分析應用程序。從人工審核到指標分析，模式分析再到數據流分析，有多種方法可以做到這一點。這被認為是白盒測試。最常見的是，SAST用戶關注數據流分析，因為它使他們能夠在應用程序完成之前查找受污染數據等安全問題。

在靜態分析的早期階段，不但強調不僅要發現錯誤，還要發現可疑或有風險的代碼結構以及執行軟件工程標準。在安全領域，SAST主要是指流量分析。基本上SAST用于查找漏洞，類似于DAST，但在SDLC（軟件生存周期，軟件開發生命周期）中較早。

SAST的優點

更早的測試更好，因為它的成本要低得多，所以SAST的主要優點是它可以提前完成——早在整個應用程序或系統準備好之前。通過SAST，您可以深入了解代碼，從而準確了解代碼涉及的問題。

SAST的缺點

在缺點方面，使用SAST，您的測試不是針對真實系統，并且工具必須合成數據以嘗試驅動功能或數據路徑的覆蓋。因此，SAST工具存在誤報問題，這意味著它們可以告訴您一段代碼在實際安全時是不安全的。此外，SAST工具通常特定于特定語言。這使得構建和維護成本高昂（主要是工具供應商的問題），并且意味著您需要為應用程序中使用的每種語言提供工具。

什么是DAST？

DAST是動態應用程序安全測試。這意味著通常通過其輸入和接口測試工作應用程序（或設備）。通常這是黑盒測試，在某種意義上說，您正在使用該應用程序而不深入了解其內部（源代碼）。

DAST的優點

DAST的最大優點是，這些顯然是真實的測試，考慮到端到端的完整應用程序和/或系統。其次，DAST測試不依賴于對代碼的深入了解，并且工具不需要對每種語言的特定支持。

DAST的缺點

另一方面，DAST的最大缺點是它不包含對代碼的深入了解。這意味著當您發現問題時，可能需要一些實時和精力來精確縮小導致問題的底層代碼。

此外，DAST是一種“測試”技術，意味著它發生在設計和編碼之后。因此，這是驗證應用程序是否安全的一種非常好的方法，但如果它是用于保護軟件的主要方式，那么您真正嘗試在應用程序中測試安全性，這是一項麻煩的任務。您無法在應用程序中測試安全性，也無法在應用程序中測試質量 - 這就是為什么像GDPR這樣的新法規和即將出臺的FDA指南依賴于安全設計方法。

使用SAST補充DAST

擁有強大的SAST策略，將早期檢測檢查器與CWE等弱點以及CERT等安全編碼標準相結合，是保護應用程序和防止重復出現相同安全問題的最完整方法。但是為了補充DAST，我們可以將SAST與DAST正在做的事情聯系起來，通過從DAST獲得的信息告知我們的SAST活動。

為了更好地理解它是如何工作的，我喜歡將軟件看作裝配線，并從生產線的最后開始，使用3步改進過程來確保安全性。第1階段總比沒有好，但它遠沒有第3階段那么好。

發布前的安全測試（第1階段）

應用程序安全性的第一階段都是DAST。對于應用程序安全性，我們采用最終的應用程序，在發布之前構建，然后對其進行攻擊，嘗試以任何方式進行攻擊 - 這是DAST。如果我們找到了什么，我們會評估它是多么令人討厭，并在我們可以的時候進行修復，在必要的時候釋放。關于這個問題本身就存在一個很大的話題（發布具有已知弱點和漏洞的軟件），但我會將其留下后續再說。

因為這個測試結束了，總是有時間壓力，以及尋找和修復潛在問題的額外難度，但是做這個測試肯定比完全不做更好，所以這是一個好的開始。

早期檢測 - 轉移安全性（第2階段）

應用程序安全性改進之路的第二階段增加了SAST，以解決周期性問題。如何在應用程序準備好之前啟動安全測試？SAST就是我們的答案。SAST檢查器可以在我們有代碼后立即運行。SAST中的數據流檢查器通常可以直接與DAST發現的問題類型相關聯，因此很容易知道在SAST發現弱點時要查找什么以及它意味著什么。

這是一個很好的下一步，因為我們不僅有更多的時間來修復，而且測試更靠近源，因此找出出錯的時間要短得多。我們的SAST現在正在進行DAST的工作并提前完成。

預防 - 超前（第3階段）

數據流實際上只是在進行更多的測試安全性，因此我們如何進入下一個級別并將SAST與DAST相結合以相互補充？第三階段是我們實際意識到將兩種工具結合使用的價值。

要將SAST與DAST轉移到完全互補的情況，我們可以從DAST獲取結果來通知我們的SAST，調整我們的靜態分析規則配置并告訴我們需要尋找哪些類型的安全漏洞。通過這種方式使用DAST，它可以使SAST告訴我們我們需要的安全漏洞來源，我們如何緩解它們以及我們如何以不會發生的方式進行編碼。

那么這是如何工作的呢？首先，我們需要使用DAST的結果執行根本原因分析。例如，使用SQL注入，我們需要確保數據在進入時進行清理，因此我們不必依賴于通過無數路徑追蹤數據以查看它是否可以逃避清理。我們還需要查看CERT中的SAST標準，以便我們既可以避免可能有效但又不安全的構造，也可以強制執行可以加強我們應用程序的良好行為，即使它們在正常（不安全）編程中可能不是必需的。適當的SAST規則可以防止DAST出現問題，我們不斷向DAST學習如何配置和調整SAST。

從故障安全方法中受益

通過一起使用SAST和DAST，您最終會得到我認為的故障安全心態。因此，例如，在沒有安全設計的情況下，在GDPR之前，我們存儲了所有用戶數據而沒有加密，然后討論了哪些特定數據值得額外保護，如密碼或社會安全號碼。在安全設計，故障安全的環境中，我們采取相反的方法并加密所有內容，然后討論不加密的安全措施。這樣，默認行為是安全的或“故障安全的”，并且您成功地最大化了SAST和DAST。

所以要小心！進行類似DAST測試的SAST檢查器是那些能夠吸引用戶和分析師興趣的檢測器，但更大的價值來自于執行適當安全行為的無聊的基于標準的檢查器。這些檢查器將您從后期測試轉移到早期檢測，并且一直到實際的預防性編碼標準，這些標準會強化您的應用程序。SAST可以通過提供早期緩解來補充DAST，并允許DAST主要用于驗證應用程序是否安全，而不是試圖破壞應用程序。

如果您正在尋找具有所有這些功能的解決方案，請查看Parasoft。免費試用版可供您在您的組織中試用。

想要了解Parasoft、Parasoft SOAtest、Parasoft Virtualize更多信息或資源的朋友，請