如何將SAST融入DevSecOps流程中？
敏捷開發大幅提高了開發團隊的工作效率和版本更新的速度，但卻不利于運維工作的進行。為了讓開發人員與運維人員更好地溝通合作，縮短系統開發生命周期，實現高質量的持續交付，開發團隊逐步轉向DevOps模式。
DevOps可以有效推進快速頻繁的開發周期，但是過時的安全措施則可能會拖累整個流程，因此催生出了DevSecOps概念。DevSecOps強調在軟件開發生命周期(SDLC)的早期引入安全防護，在軟件研發開始階段就要考慮應用和基礎架構的安全性，為DevOps打下扎實的安全基礎。
在DevSecOps的建設中，想要大幅度降低安全風險，核心是構建和利用好應用安全工具(AST)進行自動化漏洞發掘，確保執行缺陷檢測的時機準確、及時，并且不會影響研發效率。
目前市場上的應用安全工具主要有Static AST (SAST)、Dynamic AST (DAST)、Interactive AST (IAST)以及Mobile AST，其中靜態代碼分析工具SAST采用白盒測試的方式，從直接從代碼中發現查找問題，是目前較為廣泛使用的工具。本文將介紹SAST在DevSecOps中常見的使用場景。
SAST融入Devsecops的不同場景
場景1. IDE研發階段檢測
- 使用場景：將SAST集成到開發人員的IDE中，在開發人員鍵入代碼時保存時，進行檢測
- 目的：在代碼被提交到代碼倉庫之前發現修補并最常見的的安全問題，幫助代碼研發人員在研發階段發現缺陷
- 檢測耗時：秒級
- 規則集：低誤報的檢測項，偏規則類，主要采用函數內分析技術
在前期階段的檢測中，為了最大程度降低安全工作對生產效率的影響，開發人員對于檢測工具的要求是響應速度快，并且盡可能的低誤報。故在此階段，檢測引擎在研發者本地，檢測器通常只檢測編碼風格、API使用錯誤等低級錯誤。對于部分檢測器無法確定的問題，SAST工具在預提交檢測時會選擇暫時不報出漏洞，避免給開發人員增加額外的負擔。
場景2. 提交時檢測
- 使用場景：代碼提交至代碼倉庫后自動觸發
- 目的：每次提交的結果快速返回給提交代碼的開發人員
- 檢測耗時：分鐘級
- 規則集：可選有限檢測項
此階段檢測由開發人員向版本管理工具提交代碼時自動觸發，每次提交都會觸發一次。開發人員提交代碼后，檢測器對于單次提交的代碼以及其影響的數個文件進行檢測，收集本次提交中需要關注的重要缺陷和漏洞。與IDE檢測不同的是，在該階段會關注跨函數，跨文件的缺陷類型。對代碼質量要求比較高，或接近發版的團隊，往往選擇該方式進行代碼檢測。
場景3. 構建時檢測
- 使用場景：代碼提交成功并編譯后，定時進行檢測
- 目的：每天定時反饋問題
- 檢測耗時：小時級
- 規則集：允許配置更全面的檢測項，例如OWASP Top 10
此階段檢測由開發人員向版本管理工具提交代碼時自動觸發，每次提交都會觸發一次。開發人員提交代碼后，檢測器對于單次提交的代碼以及其影響的數個文件進行檢測，收集本次提交中需要關注的重要缺陷和漏洞。與IDE檢測不同的是，在該階段會關注跨函數，跨文件的缺陷類型。對代碼質量要求比較高，或接近發版的團隊，往往選擇該方式進行代碼檢測。
場景4. 測試時檢測
- 使用場景：成功構建后在環境中進行全量檢測
- 目的：將構建好的軟件部署到模擬環境中，進行全量測試
- 檢測耗時：數小時級
- 規則集：全部檢測項
SAST檢測結果將由QA進行分析和評估。QA期望發現盡可能多軟件可能存在的問題，因此，與前三個場景要求低誤報有所不同，此階段需要SAST工具報告所有可能的漏洞或缺陷，保證低漏報，達到較高覆蓋率。在這一階段，使用工具的往往是測試部門，利用SAST工具對所有文件進行全量檢測。
應用現狀及發展
實際使用中，由于部分技術尚未成熟，代碼分析工具出現的一些問題讓開發人員抱怨頻頻，這使得在DevOps中融入SAST工具，阻力依然較大。一些企業用戶的測試人員花費大量時間去除了誤報，但在第二次檢測后仍然報出類似問題，飽受開發團隊詬病。
此外，漏報率高也不容忽視。研究人員曾使用三種國外主流的代碼分析工具對CVE中100個緩沖區溢出錯誤進行檢測，其中表現最好的工具也只檢測出了其中的32個，漏報率接近70%。
但了解以上SAST工具的使用場景后，我們看到SAST工具已經在盡力適應開發人員的工作習慣。為滿足各階段開發人員對于代碼分析工具的要求，SAST工具的規則集、檢測時長在不同時期做出調整。例如，開發人員認為在編寫代碼時進行安全檢測影響其生產效率，故SAST在初期只允許配置有限規則集，就是為了能夠進行快速掃描、及時反饋，盡力降低開發與安全檢測脫節的影響。
即使對于同一檢測項，SAST工具在不同階段的檢測范圍也有所不同。拿SQL注入舉例，SAST工具在預提交時可能只檢測單函數內部的問題，提交時檢測單文件內的問題，最后階段再進行跨文件檢測。通過這種方式進行誤報、漏報、檢測時間的調節，最大程度提高開發人員對SAST工具的接受度。
我們認為，SAST工具的能力未來將不斷增強，同時開發團隊也應根據自身需要，在工作流程中選擇適當的節點使用合適的SAST工具進行代碼安全審查，向實現真正安全防護一體化的DevSecOps更進一步。
【本文是51CTO專欄作者“安全牛”的原創文章，轉載請通過安全牛（微信公眾號id:gooann-sectv）獲取授權】
