安全工具箱必備技術之靜態分析安全測試(SAST)

有幾種技術能夠識別軟件和系統的漏洞，聰明的組織把它們放在他們的「安全工具箱」中，並使用各類測試工具的組合，包括：

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

經過自動化工具提升安全性的動機是將軟件開發生命週期(SDLC)中儘早識別和修復漏洞的工做左移。當應用程序接近發佈時，修復和補救變得更加複雜。圖1顯示了隨着SDLC的進展，修復漏洞的成本如何急劇增長。

圖1：隨着SDLC的進展，修復漏洞的成本增長。

要深刻了解軟件安全的經濟性，請查看《安全軟件的商業價值》白皮書。本篇文章主要介紹將靜態分析安全測試做爲組織安全實踐的一部分。

靜態分析安全測試

SAST工具不須要運行中的應用程序，所以能夠在開發生命週期的早期使用，由於修復成本很低。在最基本的層面上，SAST的工做原理是分析源代碼，並根據一套規則進行檢查。SAST工具一般與識別漏洞相關，它爲開發人員提供早期警報，提醒他們注意不良的編碼模式，這些模式會致使漏洞、違反安全編碼策略，或缺少與工程標準的一致性，從而致使不穩定或不可靠的功能。

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

• 流分析
• 模式分析

流分析

在流分析中，工具對源代碼進行分析，瞭解代碼的底層控制流和數據流。

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

其結果是應用程序的中間表示或模型。這些工具對該模型運行規則或檢查器，以識別致使安全漏洞的編碼錯誤。例如，在 C 或 C++ 應用程序中，規則可能會識別字符串副本，而後遍歷該模型，以肯定源緩衝區是否可能大於目標緩衝區。若是是這樣，就會致使緩衝區溢出漏洞。

模式分析

在安全關鍵的代碼中避免某些構造是現代軟件工程標準的基礎，如AUTOSAR C++14、MISRA C 2012和聯合攻擊戰鬥機（JSF）。這些標準防止了誤讀、誤解或錯誤地實現不可靠代碼的可能性。

模式分析能夠幫助開發人員在安全或保障的背景下使用更安全的開發語言子集，禁止使用首先容許漏洞發生的代碼構造。一些規則能夠經過檢查語法來識別錯誤，就像文字處理器中的拼寫檢查器同樣。一些現代工具能夠檢測與不良編碼結構相關的微妙模式。

SAST的優點

每種測試方法都有其優點。許多組織過分關注DAST和滲透測試。但使用SAST比其餘測試技術有幾個優點。

代碼覆蓋率

測試的代碼量是軟件安全的一個關鍵指標。漏洞可能存在於代碼庫的任何部分，未經測試的部分可能使應用程序暴露在攻擊之下。

SAST工具，特別是那些使用模式分析規則的工具，能夠提供比動態技術或手動流程高得多的代碼覆蓋率。它們能夠訪問應用程序的源代碼和應用程序的輸入，包括在用戶界面中沒有暴露的隱藏輸入。

根源分析

SAST工具促進了漏洞的高效補救。靜態分析安全測試能夠輕鬆識別引入錯誤的精確代碼行。與開發人員的集成開發環境的集成能夠加速補救SAST工具發現的錯誤。

提升技能

開發人員在IDE中使用SAST工具時，會收到關於其代碼的即時反饋。這些數據能夠強化和教育他們的安全編碼實踐。

操做效率

開發人員在開發生命週期的早期使用靜態分析，包括直接從IDE中對單個文件進行分析。在SDLC的早期發現錯誤，大大下降了補救的成本。它首先防止了錯誤的發生，所以開發人員沒必要在之後再去尋找和修復它們。

如何從SAST中得到最大收益

SAST是一種全面的測試方法，確實須要一些最初的努力和動機來成功地採用它。

儘早部署SAST

雖然團隊能夠在SDLC早期使用SAST工具，但有些組織選擇將分析工做推遲到測試階段。即便分析一個更完整的應用程序能夠進行程序間的數據流分析，但使用SAST「左移」，直接從IDE中分析代碼，能夠發現漏洞，如輸入驗證錯誤。還可讓開發人員在提交代碼進行構建以前進行簡單的修正。這有助於避免後期週期性的安全變動。

在敏捷和CI/CD管道中使用SAST

SAST分析是被誤解的。許多團隊認爲它很耗時，由於它要對整個項目的源代碼進行深刻分析。這可能致使組織認爲SAST與快速開發方法論不兼容，這是沒有根據的。靜態分析安全測試的結果幾乎是即時的，能夠在開發人員的IDE中得到，提供即時反饋，並確保避免漏洞。現代SAST工具執行增量分析，只查看兩次不一樣構建之間變化的代碼的結果。

處理嘈雜的結果

傳統的靜態分析安全測試工具一般包括許多「信息」結果和圍繞正確編碼標準的低嚴重性問題。現代工具，如Parasoft提供的工具，容許用戶選擇使用哪些規則/檢查器，並根據錯誤的嚴重程度過濾結果，隱藏那些不值得調查的結果。許多來自 OWASP、CWE、CERT 等的安全標準都有風險模型，有助於識別最重要的漏洞。你的SAST工具應該使用這些信息來幫助你關注最重要的東西。用戶能夠更多的根據其餘背景信息來過濾發現，好比項目的元數據，代碼的年齡，以及負責代碼的開發人員或團隊。像Parasoft這樣的工具提供了使用這些信息與人工智能（AI）和機器學習（ML）來幫助進一步肯定最關鍵的問題。

關注開發者

成功的部署一般以開發人員爲中心。它們提供了開發人員在軟件中構建安全所需的工具和指導。這在敏捷和DevOps/DevSecOps環境中很是重要，由於在這種環境中，快速反饋對於保持速度相當重要。IDE集成容許直接從開發人員的工做環境中進行安全測試——在文件級、項目級，或者僅僅是評估已更改的代碼。

使用智能規則配置

在分析軟件的安全問題時，一個尺寸不適合全部組織。重要的是，規則/檢查程序要解決對特定應用程序相當重要的特定問題。剛開始測試安全的組織可能但願將規則限制在最多見的安全問題上，如跨站點腳本和SQL注入。其餘組織根據PCI DSS等法規有特定的安全要求。尋找容許符合你的特定需求的受控規則/檢查器配置的解決方案，而不是通用配置。

預防勝於發現

將安全性構建到你的應用程序中。這比在SDLC結束時，經過在已完成的應用程序上栓上安全螺栓來確保應用程序的安全要有效得多。就像你不能在應用程序中測試質量同樣，安全也是如此。SAST是早期檢測的關鍵，經過從一開始就編寫安全代碼來防止安全漏洞。

SAST工具使組織可以從開發的早期階段開始就接受軟件安全，併爲他們的軟件工程師提供構建安全軟件所需的工具和指導。