摘要：根據Forrester的 The State Of Application Security, 2022一文的預測，應用安全性的缺失將仍然是最常見的外部攻擊方式，因此SAST將會在可預見的未來一直被重視，
本文分享自華為云社區《SAST-靜態應用安全測驗》，作者： gentle_zhou ，
SAST，Static Application Security Testing，即靜態應用安全測驗，也叫靜態分析，是一種測驗方法，一直是應用程式安全性作業的核心部分，根據Forrester的 The State Of Application Security, 2022一文的預測，應用安全性的缺失將仍然是最常見的外部攻擊方式，因此SAST將會在可預見的未來一直被重視，
什么是SAST
Static Application Security Testing，靜態應用安全測驗，是一種白盒測驗，也是當前正在使用中的最成熟的應用程式安全測驗方法之一，不用運行組件，在編譯代碼階段之前，SAST可以通過分析源代碼來發現一些容易讓應用受到攻擊的安全漏洞，
而Gartner對SAST的定義則是：“一組用來指示安全漏洞情況，設計用來分析應用程式在編碼和設計階段下源代碼，位元組碼，二進制的技術”，
“a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities.”
為什么需要SAST
根據Forrester一項針對安全專業人士的調查報告顯示，在2022年，近三分之二的外部攻擊是通過web應用程式(32%)或利用軟體漏洞(35%)進行的，
而SAST可以讓開發人員檢測到源代碼中的安全漏洞或弱點，幫助研發團隊遵守某要求或規定（比如PCI/DSS），更好地理解軟體里存在的風險；可以說，SAST成為了降低軟體風險第一步的工具，已經成為應用程式安全測驗工具的代名詞，也因為如此，如果我們真的想確保軟體的安全，了解SAST是如何運作的就至關重要，
需要注意的是，為了更好的達到上述的效果，定期在應用上（比如每月/每天）、每次有新增代碼或合入代碼的時候運行我們的SAST工具就非常有必要，
SAST如何運作？
正如SAST 靜態應用安全測驗這名字明面上代表的意思一樣，它可以在不運行代碼（靜止狀態）的情況下，在軟體開發生命周期 (SDLC) 的早期階段進行靜態代碼的掃描；通常SAST是在開發的編碼和測驗階段被使用，會被集成在CI階段甚至IDE編輯器中，
SAST的掃描是基于一組預先確定的規則（這些規則定義了原始碼中需要評估和處理的編碼錯誤）的，SAST掃描可以被設計用來識別一些常見的安全漏洞，比如SQL注入，輸入驗證，堆疊緩沖區溢位等，
SAST的優勢與不足
SAST作為一種優秀的應用程式安全工具，如果操作得當，它對組織的應用安全策略就會至關重要，將SAST集成到SDLC中提供了以下好處:
優勢
- 做到安全左移，將安全測驗集成到軟體開發的早期階段是一項重要的實踐，SAST可以幫助安全性測驗提前進行，在設計階段發現代碼中的漏洞，修復相關安全問題；這么做的好處的是，為企業組織大大減少在臨近發布日期階段或則更遲的階段才去解決安全問題的代價，
- 確保編碼安全，SAST可以輕松檢測出一些簡單的編碼錯誤而導致的缺陷，從而幫助開發團隊可以遵守安全編碼標準和最佳實踐，
- 檢測常見漏洞，自動化的SAST工具可以輕松并高效地檢測出常見的安全漏洞比如換粗去溢位，SQL注入，跨站點腳本撰寫等問題，
- 更加易于使用，現代應用程式開發環境下，SAST與DevOps環境和CI/CD管道集成在了一起，更加高效、方便、易于使用；這樣開發團隊不需要再單獨配置或額外進行觸發掃描，也就是說團隊不用離開開發環境就可以掃描、查看、修復安全問題，
- CWE全面覆寫，業界SAST工具提供的檢測覆寫了多種CWE缺陷，包括各種平臺和框架上開發的桌面、web和移動應用程式，并支持多種不同的編程語言和編程框架，
- 掃描高效，研發團隊在實際研發程序中，會更注重效率，一款高效的SAST工具可以讓團隊更快獲得需要的結果，
不足
- 覆寫不了所有的漏洞，因為是在代碼未運行的情況下去測驗，無法覆寫運行時問題或則配置問題；對于訪問控制，身份驗證或則加密之類的場景也測不出，
- 誤報率高，SAST的掃描結果會包含大量誤報，需要研發團隊手動去排查和屏蔽，會耗費團隊大量時間，更嚴重的是，有時候團隊會要求強制清零漏洞，誤報得不到重視，就會一直存在，
- 耗時，對于一些大型的專案，因為代碼倉過大一次掃描可能要花費好幾個小時；而SAST的掃描結果因為只是指出潛在的漏洞，還需要研發團隊驗證是否確實是隱患
選取SAST工具的衡量因素
實際研發專案中，不同的專案、大型的專案會或多或少涉及到不同的開發語言，技術框架，承載平臺，而市場上又充斥著大量的SAST產品，很多又會與額外的解決方案捆綁在一起，那么如何選取最有效的SAST工具來達到高效執行的目的呢，有如下幾個因素可以考慮：
- 支持語言：確保選擇的SAST工具覆寫了我們當前專案所使用的編程語言
- 漏洞覆寫：確保選擇的SAST工具覆寫了全面的主流的應用程式安全漏洞
- 準確性：確保選擇的SAST工具誤報率低
- 兼容性：確保選擇的SAST工具兼容當前專案所使用的技術框架，也支持集成到SDLC中
- IDE集成：確保選擇的SAST工具可以集成到IDE中，支持實時檢查
- 擴展性：確保選擇的SAST工具易于擴展，支持自定義規則
如何實施、部署SAST到專案中呢
如何將選擇的SAST解決方案部署、實施進來呢，需要以下這些步驟：
- 選擇部署方式：我們需要根據專案實際性質決定將SAST部署在本地還是云端環境里；這一決定取決于我們希望對SAST工具有多大的控制權，工具運行和擴展的速度、容易程度，
- 配置并集成到SDLC中：我們需要根據專案何時以及如何掃描分析代碼來決定；我們可以選擇如下4種方式中的一種：編譯代碼時分析；將新增代碼合并到代碼庫時掃描；在CI/CD管道中添加；在IDE中運行SAST可以實時進行檢查，
- 決定掃描分析的范圍，我們可以選擇如下幾種：
完整：對應用程式及其全量代碼的掃描是最全面也是最耗時的程序
增量：僅掃描新增或更改的代碼
桌面：代碼撰寫階段進行掃描分析，實時解決問題
不用構建：對于不熟悉構建程序或IDE的人員，在原始碼中進行分析 - 自定義來滿足需求：團隊肯定希望可以減少誤報，自定義新規則，修改現有規則，以滿足可以更全面地識別安全缺陷的需求，也許還希望可以自定義用于分析掃描的儀表盤或則構建自定義的報告，
- 優先應用和結果：根據團隊考慮因素的重要級來對應用和結果進行優先級排序，考慮因素包括遵從性問題、威脅嚴重程度、CWE漏洞、漏洞狀態、風險級別和責任，
- 分析結果，跟蹤進展，評估緊迫性：評估檢查掃描結果以排除誤報；建立一個系統，可以自動將問題發送、分配給負責的開發人員，讓他們去解決，
- 報告和治理：研發團隊要利用好工具內置的報告工具，或則做到可以將資料推送到我們已有的報告工具里，做好資料的分析與治理，
參考鏈接
- https://www.mend.io/resources/blog/sast-static-application-security-testing/
- https://www.synopsys.com/zh-cn/glossary/what-is-sast.html
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/540015.html
標籤：其他