目前仍然處于早期發展階段的軟件安全面臨著兩個挑戰。首先是確保從業人員修復他們發現的安全缺陷，無論缺陷屬于什么類別。第二是擴展到涵蓋整個企業范圍的產品組合(全部，當然，也許是以基于風險的方式)。幸運的是，在這兩方面，我們一直在取得進展。

[[122603]]

修復你所發現的問題

應用安全技術專家和行業分析師一直不斷地探討用于檢測軟件安全缺陷的方法。SAST、DAST、IAST和RASP都是Gartner公司認可的漏洞檢查方法，它們都被扔到這場戰斗中?？杀氖牵瑥募夹g上來講，并沒有最終的勝利者。這是因為每種方法都有自己的優缺點，并且這些方法往往相得益彰。

自Cigital公司在1999年推出其ITS4以來，SAST(即靜態應用安全測試)已經走過了漫長的發展道路。擴展SAST是一個挑戰，在兩種情況下會遇到這個挑戰。第一種是通過圍繞一種工業級強度工具(例如Coverity、IBM Appscan Source或者HP/Fortify)建立一個工廠。第二種是部署基于IDE的桌面工具，例如Cigital SecureAssist。Aetna首席信息安全官Jim Routh和筆者在其他文章中也討論了SAST以及可擴展性。(順便說一句，SAST和技術轉移是很好的議題)。

從局外人來看，DAST(即動態應用安全測試)是關于動態黑盒測試。一般來說，DAST工具只適用于使用簡單通信協議(例如HTTP)的軟件。它對Web應用的動態測試很有意義，但DAST在其設計中只有有限的目標。這意味著DAST很適合Web應用，但并不適用于大多數其他類型的軟件。

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

RAST(即運行時應用自我保護)是一種新方法，它主要是重寫軟件讓軟件可以在運行時被監控。這是有著悠久歷史的想法，同時它有著一個很大的缺陷：如果你在最后一刻重寫軟件，當你因為軟件故障而受到指責時不要感到驚訝，即使你的重寫與故障沒有關系。筆者總是會說，“不要成為最后一個摸山芋的人”，這個建議也適用于RASP。從記錄來看，RASP還會帶來效率影響，1%到10%的范圍，這也需要考慮在內。最后，如果你允許RASP來阻止代碼在主動攻擊期間在生產環境運行，你等于創建了一個很好的拒絕服務引擎。總之，這是很新的方法。

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

人的因素

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

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

由于開發者最終要負責創建盡可能少缺陷的軟件，任何能夠盡可能直接地幫助開發者的工具都是最有用的。在開發領域的這一點上，只有少數簡單漏洞可以完全自動化處理掉。這個測試仍將需要開發人員的參與來解決問題。

總之，在你設計巧妙的新方法來檢測漏洞時，確保你考慮了實際軟件修復。如果你的工具供應商沒有談論問題如何得到修復，這里可能有原因。

擴展到企業產品組合

說了這么多，對于軟件安全，各種類型的工具都是必不可少的。在這里，擴展很重要。為了涵蓋大多數公司的整個產品組合(即所有軟件應用)，自動化是真正唯一的出路。從其價值來看，設計分析和漏洞查找工具都是這樣，雖然在設計中我們有些工作會消除。

很長時間以來，風險管理被濫用為僅關注少數“高風險”應用，而最終減去和忽略了其余的絕大多數應用。雖然從效率來看這似乎是個好主意，但事實證明，攻擊者通常會瞄準一切的事情。在現在的攻擊情況中，你產品組合中的每個軟件都應該進行一定水平的測試。攻擊者會瞄準任何薄弱環節(包括暖通空調供應商和其他小型供應商)。目前新的薄弱環節是被忽略的應用安全。

現在是時候利用整個產品組合中的工具和服務來不遺余力地尋找基本的漏洞了。

當然，這些類型的解決方案仍然可以是基于風險的。你有高風險面向互聯網的應用?請進行一次徹底的架構風險分析;使用強大的靜態分析工具來審查其代碼;培訓開發人員來保持其安全性;執行滲透測試以及進行完整的she-bang，但不要將低風險應用轉盤轉動至零。使用自動化測試來尋找和解決簡單漏洞。為開發人員配備基于IDE的靜態工具，并對他們進行培訓。

在你規劃和執行你的軟件安全舉措(以及使用BSIMM進行衡量)時，請確保這種可擴展性發揮重要作用。