有幾種技術可以識別軟件和系統中的漏洞。聰明的組織將它們保存在“安全工具箱”中，并使用多種測試工具，其中包括：

• 靜態分析安全性測試（SAST）
• 動態分析安全測試（DAST）
• 源成分分析（SCA）
• 漏洞掃描器
• 滲透測試

通過自動化工具提高安全性的動機是在軟件開發生命周期（SDLC）中盡早轉移對漏洞的識別和補救。隨著應用程序即將發布，修復和修復變得更加復雜。圖1顯示了隨著SDLC的進行，補救漏洞的成本如何急劇增加。

圖1：隨著SDLC的進行，修復漏洞的成本增加。

要深入了解軟件安全性經濟學，請查看安全軟件的商業價值白皮書。這篇文章重點介紹將靜態分析安全性測試用作組織安全性實踐的一部分。

靜態分析安全測試

SAST工具不需要運行的應用程序，因此可以在補救成本較低的開發生命周期的早期使用。在最基本的級別上，SAST的工作原理是分析源代碼并根據一組規則對其進行檢查。通常與識別漏洞相關聯，SAST工具會向開發人員提供早期警報，告知他們不良的編碼模式會導致漏洞利用，違反安全編碼策略或缺乏與工程標準的一致性，從而導致功能不穩定或不可靠。

有兩種主要類型的分析可用于識別安全問題。

• 流分析
• 模式分析

流分析

在流分析中，這些工具分析源代碼以了解代碼的基本控制流和數據流。

圖2：靜態分析安全性測試——流分析

結果是應用程序的中間表示或模型。這些工具針對該模型運行規則（或檢查程序），以識別導致安全漏洞的編碼錯誤。例如，在C或C++應用程序中，規則可以標識字符串副本，然后遍歷模型以確定源緩沖區是否可能大于目標緩沖區。如果是這樣，則可能導致緩沖區溢出漏洞。

模式分析

避免使用某些對安全性至關重要的代碼構造是現代軟件工程標準（例如AUTOSAR C++14，MISRA C 2012和Joint Strike Fighter（JSF））的基礎。這些標準可防止誤解，誤解或錯誤實施不可靠代碼的可能性。

模式分析可在給定安全性或安全性的上下文的情況下幫助開發人員使用開發語言的更安全子集，從而禁止使用允許漏洞首先發生的代碼構造。有些規則可以通過檢查語法來識別錯誤，例如文字處理器中的拼寫檢查器。一些現代工具可以檢測與不良編碼構造相關的細微模式。

SAST的優勢

每種測試方法都有其優勢。許多組織過分關注DAST和滲透測試。但是與其他測試技術相比，使用SAST有許多優勢。

代碼覆蓋率

經過測試的代碼量是確保軟件安全的關鍵指標。在代碼庫的任何部分中都可能存在漏洞，未經測試的部分可能會使應用程序容易受到攻擊。

SAST工具（尤其是那些使用模式分析規則的工具）可以提供比動態技術或手動過程更高的代碼覆蓋率。他們可以訪問應用程序源代碼和應用程序輸入，包括未在用戶界面中公開的隱藏代碼。

根本原因分析

SAST工具可促進對漏洞的有效補救。靜態分析安全性測試可以輕松識別出引入錯誤的精確代碼行。與開發人員的IDE集成可以加速補救SAST工具發現的錯誤。

技能提升

當開發人員使用IDE中的SAST工具時，他們會立即收到有關其代碼的反饋。數據加強了對安全編碼實踐的教育。

運營效率

開發人員在開發生命周期的早期就使用靜態分析，包括直接從其IDE中對單個文件進行分析。在SDLC中盡早發現錯誤可以大大減少補救成本。它從一開始就防止了錯誤，因此開發人員不必在以后找到并修復它們。

如何充分利用SAST

SAST是一種全面的測試方法，它需要一定的初步努力和動力才能成功采用。

盡早部署SAST

盡管團隊可以在SDLC的早期使用SAST工具，但一些組織選擇將分析推遲到測試階段。即使分析更完整的應用程序可以進行跨過程的數據流分析，使用SAST進行“向左移”并直接從IDE中分析代碼仍可以識別諸如輸入驗證錯誤之類的漏洞。它還使開發人員可以在提交構建代碼之前進行簡單的更正。這有助于避免安全性的后期更改。

將SAST與敏捷和CI/CD管道一起使用

SAST分析被誤解了。許多團隊認為這很耗時，因為它對整個項目源代碼進行了深入的分析。這可能會使組織認為SAST與快速開發方法不兼容，這是沒有根據的。靜態分析安全性測試的近乎即時的結果可在開發人員的IDE中獲得，可提供即時反饋并確保避免漏洞。現代的SAST工具執行增量分析，以僅查看來自兩個不同版本之間更改的代碼的結果。

處理嘈雜的結果

傳統的靜態分析安全測試工具通常包含許多“信息”結果以及圍繞正確編碼標準的低嚴重性問題。像Parasoft提供的工具一樣，現代工具使用戶可以選擇要使用的規則/檢查器，并根據錯誤的嚴重程度來過濾結果，隱藏那些不值得調查的工具。OWASP，CWE，CERT等的許多安全標準都具有有助于識別最重要漏洞的風險模型。您的SAST工具應使用此信息來幫助您專注于最重要的事情。用戶可以根據其他上下文信息（例如項目中的元數據，代碼的年齡以及負責代碼的開發人員或團隊）進一步過濾結果。諸如Parasoft之類的工具可通過人工智能（AI）和機器學習（ML）來使用此信息，以幫助進一步確定最關鍵的問題。

關注開發者

成功的部署通常以開發人員為中心。它們為開發人員提供了在軟件中構建安全性所需的工具和指南。這對于敏捷和DevOps/DevSecOps環境非常重要，在這些環境中，快速反饋對于保持速度至關重要。IDE集成允許直接從開發人員的工作環境進行安全測試——在文件級別，項目級別或僅評估更改的代碼。

使用智能規則配置

在分析軟件中的安全性問題時，一個規模并不適合所有組織。規則/檢查者必須解決對特定應用程序至關重要的特定問題，這一點至關重要。剛開始進行安全性測試的組織可能希望將規則限制為最常見的安全性問題，例如跨站點腳本和SQL注入。其他組織有基于法規的特定安全要求，例如PCI DSS。尋找可允許您滿足特定需求的受控規則/檢查程序配置而不是常規配置的解決方案。

預防勝于檢測

在您的應用程序中構建安全性。與在SDLC末尾通過在完成的應用程序之上附加安全性來嘗試保護應用程序安全性相比，它更加有效和高效。正如您無法測試應用程序的質量一樣，安全性也是如此。SAST是早期發現的關鍵，它通過從一開始就編寫安全代碼來防止安全漏洞。

SAST工具使組織能夠從開發的早期開始就接受軟件安全性，并向其軟件工程師提供構建安全軟件所需的工具和指南。