淺談軟件漏洞檢測方法：SAST、RAST？整合檢測最實際

目前仍然處於早期發展階段的軟件安全面臨著兩大挑戰。首先是確保開發者要誠實地修復他們發現的安全缺陷，無論缺陷屬於什麼類別。第二是擴展到涵蓋整個企業範圍的產品組合。

修復你所發現的問題

應用安全技術專家和行業分析師一直不斷地探討用於檢測軟件安全缺陷的方法。SAST、DAST、IAST 和 RASP 都是 Gartner 認可的漏洞檢查方法，它們都被扔到這場戰鬥中。可悲的是，從技術上來說，並沒有單一贏家。這是因為每種方法都有其缺點。

自 Cigital 在 1999 年推出其 ITS4 以來，SAST（即靜態應用安全測試）已經過了多年的發展。擴展 SAST 是一個挑戰，在兩種情況下會遇到這個挑戰。第一種是通過圍繞一種工業級強度工具（例如 Coverity、IBM Appscan Source 或者 HP/Fortify）。第二種是部署基於 IDE 的桌面工具，例如 Cigital SecureAssist。

很多人可能會認為 DAST（即動態應用安全測試）是關於動態黑盒測試。一般來說，DAST 工具只適用於使用簡單通信協議（例如 HTTP）的軟件。它對 Web 應用的動態測試很有意義，但 DAST 在其設計中只有有限的目標。這意味著 DAST 很適合 Web 應用，但並不適用於大多數其他類型的軟件。

IAST（即交互式應用安全測試）將動態和靜態方法整合到交互式解決方案中。很明顯的是，早期 IAST 方法（與 DAST 一樣）限制為 Web 應用。如果你的產品組合中只有 Web 應用，IAST是很好的方法。

RAST（即運行時應用自我保護）是一種新方法，它主要是重寫軟件讓軟件可以在運行時被監控。這是一種很早已出現的想法，同時它有著一個很大的缺陷：如果你在最後一刻重寫軟件，當你因為軟件故障而受到指責時不要感到驚訝，即使你的重寫與故障沒有關系。從記錄來看，RASP 還是會帶來效率影響，雖只有 1% 到 10% 的範圍，但這也是需要考慮的；如果你允許 RASP 阻止應用代碼在攻擊出現期間運行，你等於為自己建立了一個很好的「拒絕服務引擎」。總之，這是很新的方法，亦是一種讓你負上全責，可能會因而掉了工作的方法…..

事實證明，探討這些技術方法是非常愚蠢的行為，特別是當涉及 SAST、DAST 和 IAST 時。多年以來，在該領域的人員通過各種方式整合這些技術來解決軟件安全中的重要問題。單靠一種方法幾乎永遠不是正確的答案。

人的因素

軟件安全的小秘密解釋了這其中的原因：工具本身並不能解決軟件安全問題，特別是單純尋找漏洞的簡單工具。這是因為如果你不真正解決你發現的安全缺陷，你並不能在安全方面帶來改進。如果沒有聰明的工作人員參與，這些工具都無法修復缺陷。它們在發現漏洞的方式略有不同（我們甚至不會提及缺陷）。而這個真理適用於所有 web 應用安全領域。

如果我們退一步考慮這些技術，可以很容易看到 SAST 的優勢超過 DAST 或其他任何動態測試方法。當涉及修復軟件時，如果你知道代碼中哪裡存在問題，則更容易修復這些問題。在另一方面，如果你只知道哪個 glob 在運行時測試過程中存在問題，修復這個缺陷則是一個挑戰。正如在物理學中，白盒實驗總是優於黑盒實驗。

由於開發者最終要負責建立盡可能少缺陷的軟件，任何能夠直接地幫助開發者的工具都是最有用的。在開發領域上，只有少數簡單漏洞可以完全自動化處理。而其他的仍需要開發人員的參與才有望解決問題。

總之，在你設計巧妙的新方法來檢測漏洞時，確保你考慮了實際軟件修復的過程。如果你的工具供應商沒有談論此問題及修復建議，這便代表了「可能有鬼」，小心被騙。

擴展到企業產品組合

說了這麼多，對於軟件安全，各種類型的工具都是必不可少的。在這裡，擴展很重要。為了涵蓋大多數公司的整個產品組合（即所有軟件應用），自動化是真正唯一的出路。從其價值來看，設計分析和漏洞查找工具都是這樣。

不過多年來，風險管理均被濫用為僅關注少數「高風險」應用，而最終減去和忽略了其餘的絕大多數應用。雖然從效率來看這似乎是個好主意，但事實證明，攻擊者通常會瞄準一切。在現在的攻擊情況中，你產品組合中的每個軟件都應該進行一定水平的測試。攻擊者會瞄准任何薄弱環節，所以現在是時候利用整個產品組合中的工具和服務來尋找基本的漏洞。

當然，這些類型的解決方案仍然可以是基於風險進行採購的。你有高風險的互聯網應用？請進行一次徹底的架構風險分析；使用強大的靜態分析工具來審查其代碼；培訓開發人員來確保其安全性；執行滲透測試以及進行完整的 she-bang，但不要忽略低風險應用。使用自動化測試來尋找和解決簡單漏洞。