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