建站
咨詢
售后
建站咨詢
新聞中心
敏捷開發(fā)大幅提高了開發(fā)團(tuán)隊(duì)的工作效率和版本更新的速度，但卻不利于運(yùn)維工作的進(jìn)行。為了讓開發(fā)人員與運(yùn)維人員更好地溝通合作，縮短系統(tǒng)開發(fā)生命周期，實(shí)現(xiàn)高質(zhì)量的持續(xù)交付，開發(fā)團(tuán)隊(duì)逐步轉(zhuǎn)向DevOps模式。
成都創(chuàng)新互聯(lián)從2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站制作、成都網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元銅山做網(wǎng)站,已為上家服務(wù),為銅山各地企業(yè)和個人服務(wù),聯(lián)系電話:028-86922220
DevOps可以有效推進(jìn)快速頻繁的開發(fā)周期，但是過時的安全措施則可能會拖累整個流程，因此催生出了DevSecOps概念。DevSecOps強(qiáng)調(diào)在軟件開發(fā)生命周期(SDLC)的早期引入安全防護(hù)，在軟件研發(fā)開始階段就要考慮應(yīng)用和基礎(chǔ)架構(gòu)的安全性，為DevOps打下扎實(shí)的安全基礎(chǔ)。
在DevSecOps的建設(shè)中，想要大幅度降低安全風(fēng)險(xiǎn)，核心是構(gòu)建和利用好應(yīng)用安全工具(AST)進(jìn)行自動化漏洞發(fā)掘，確保執(zhí)行缺陷檢測的時機(jī)準(zhǔn)確、及時，并且不會影響研發(fā)效率。
目前市場上的應(yīng)用安全工具主要有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ā)人員鍵入代碼時保存時，進(jìn)行檢測
- 目的：在代碼被提交到代碼倉庫之前發(fā)現(xiàn)修補(bǔ)并最常見的的安全問題，幫助代碼研發(fā)人員在研發(fā)階段發(fā)現(xiàn)缺陷
- 檢測耗時：秒級
- 規(guī)則集：低誤報(bào)的檢測項(xiàng)，偏規(guī)則類，主要采用函數(shù)內(nèi)分析技術(shù)
在前期階段的檢測中，為了最大程度降低安全工作對生產(chǎn)效率的影響，開發(fā)人員對于檢測工具的要求是響應(yīng)速度快，并且盡可能的低誤報(bào)。故在此階段，檢測引擎在研發(fā)者本地，檢測器通常只檢測編碼風(fēng)格、API使用錯誤等低級錯誤。對于部分檢測器無法確定的問題，SAST工具在預(yù)提交檢測時會選擇暫時不報(bào)出漏洞，避免給開發(fā)人員增加額外的負(fù)擔(dān)。
場景2. 提交時檢測
- 使用場景：代碼提交至代碼倉庫后自動觸發(fā)
- 目的：每次提交的結(jié)果快速返回給提交代碼的開發(fā)人員
- 檢測耗時：分鐘級
- 規(guī)則集：可選有限檢測項(xiàng)
此階段檢測由開發(fā)人員向版本管理工具提交代碼時自動觸發(fā)，每次提交都會觸發(fā)一次。開發(fā)人員提交代碼后，檢測器對于單次提交的代碼以及其影響的數(shù)個文件進(jìn)行檢測，收集本次提交中需要關(guān)注的重要缺陷和漏洞。與IDE檢測不同的是，在該階段會關(guān)注跨函數(shù)，跨文件的缺陷類型。對代碼質(zhì)量要求比較高，或接近發(fā)版的團(tuán)隊(duì)，往往選擇該方式進(jìn)行代碼檢測。
場景3. 構(gòu)建時檢測
- 使用場景：代碼提交成功并編譯后，定時進(jìn)行檢測
- 目的：每天定時反饋問題
- 檢測耗時：小時級
- 規(guī)則集：允許配置更全面的檢測項(xiàng)，例如OWASP Top 10
此階段檢測由開發(fā)人員向版本管理工具提交代碼時自動觸發(fā)，每次提交都會觸發(fā)一次。開發(fā)人員提交代碼后，檢測器對于單次提交的代碼以及其影響的數(shù)個文件進(jìn)行檢測，收集本次提交中需要關(guān)注的重要缺陷和漏洞。與IDE檢測不同的是，在該階段會關(guān)注跨函數(shù)，跨文件的缺陷類型。對代碼質(zhì)量要求比較高，或接近發(fā)版的團(tuán)隊(duì)，往往選擇該方式進(jìn)行代碼檢測。
場景4. 測試時檢測
- 使用場景：成功構(gòu)建后在環(huán)境中進(jìn)行全量檢測
- 目的：將構(gòu)建好的軟件部署到模擬環(huán)境中，進(jìn)行全量測試
- 檢測耗時：數(shù)小時級
- 規(guī)則集：全部檢測項(xiàng)
SAST檢測結(jié)果將由QA進(jìn)行分析和評估。QA期望發(fā)現(xiàn)盡可能多軟件可能存在的問題，因此，與前三個場景要求低誤報(bào)有所不同，此階段需要SAST工具報(bào)告所有可能的漏洞或缺陷，保證低漏報(bào)，達(dá)到較高覆蓋率。在這一階段，使用工具的往往是測試部門，利用SAST工具對所有文件進(jìn)行全量檢測。
應(yīng)用現(xiàn)狀及發(fā)展
實(shí)際使用中，由于部分技術(shù)尚未成熟，代碼分析工具出現(xiàn)的一些問題讓開發(fā)人員抱怨頻頻，這使得在DevOps中融入SAST工具，阻力依然較大。一些企業(yè)用戶的測試人員花費(fèi)大量時間去除了誤報(bào)，但在第二次檢測后仍然報(bào)出類似問題，飽受開發(fā)團(tuán)隊(duì)詬病。
此外，漏報(bào)率高也不容忽視。研究人員曾使用三種國外主流的代碼分析工具對CVE中100個緩沖區(qū)溢出錯誤進(jìn)行檢測，其中表現(xiàn)最好的工具也只檢測出了其中的32個，漏報(bào)率接近70%。
但了解以上SAST工具的使用場景后，我們看到SAST工具已經(jīng)在盡力適應(yīng)開發(fā)人員的工作習(xí)慣。為滿足各階段開發(fā)人員對于代碼分析工具的要求，SAST工具的規(guī)則集、檢測時長在不同時期做出調(diào)整。例如，開發(fā)人員認(rèn)為在編寫代碼時進(jìn)行安全檢測影響其生產(chǎn)效率，故SAST在初期只允許配置有限規(guī)則集，就是為了能夠進(jìn)行快速掃描、及時反饋，盡力降低開發(fā)與安全檢測脫節(jié)的影響。
即使對于同一檢測項(xiàng)，SAST工具在不同階段的檢測范圍也有所不同。拿SQL注入舉例，SAST工具在預(yù)提交時可能只檢測單函數(shù)內(nèi)部的問題，提交時檢測單文件內(nèi)的問題，最后階段再進(jìn)行跨文件檢測。通過這種方式進(jìn)行誤報(bào)、漏報(bào)、檢測時間的調(diào)節(jié)，最大程度提高開發(fā)人員對SAST工具的接受度。
我們認(rèn)為，SAST工具的能力未來將不斷增強(qiáng)，同時開發(fā)團(tuán)隊(duì)也應(yīng)根據(jù)自身需要，在工作流程中選擇適當(dāng)?shù)墓?jié)點(diǎn)使用合適的SAST工具進(jìn)行代碼安全審查，向?qū)崿F(xiàn)真正安全防護(hù)一體化的DevSecOps更進(jìn)一步。
新聞標(biāo)題：如何將SAST融入DevSecOps流程中？
網(wǎng)站路徑：http://www.dlmjj.cn/article/djogode.html
