[持續交付實踐] 交付流水線設計：安全專項測試

前言

TesterHome有人專門加了我QQ問安全測試這個話題，因此這篇準備先聊聊持續交付中的安全測試。
如今信息安全已經上升到了國家戰略的高度，特別是今年《中華人民共和國網絡安全法》頒佈後，用戶隱私經過國家立法的方式被嚴格要求保護，另一方面安全灰產行業風起雲涌，造成了一個巨大的地下產業鏈條和破壞能力。在此背景下，愈來愈多的互聯網公司也開始組建本身的安全職能部門，但也會發現不少公司的軟件並無通過專門的安全測試便運行在互聯網上，它們攜帶着各種安全漏洞直接暴露在公衆面前，其中一些漏洞甚至直指軟件所承載的核心敏感信息或業務邏輯。這裏既有企業安全意識的問題，也有安全人才缺少的緣由，目前軟件測試團隊大多數人的視野仍還停留在功能驗收，或性能自動化等傳統領域，對於安全測試，則每每會感受水太深了不知從何下手。

互聯網公司的安全團隊

在軟件測試的這些領域裏，安全測試確實是一個比較特別的科目。在幾年前，企業招聘安全人員通常都是放在運維部門，主要工做仍是掃描和服務器加固等，搭建IDS/IPS/WAF等安全設備進行對抗，這些安全設備提及來很唬人，市場也賣的很好，可是若是脫離業務光依靠安全設備堆疊，真正擋住了多少黑客攻擊？估計抓的最多的仍是漫無目的的蠕蟲。
本人幾年前有幸從無到有進行了安全團隊的組建，從本身作滲透測試到如今逐漸組建了10人左右的專業安全團隊，慢慢也接觸和熟悉了這個方向，覆蓋領域從應用安全逐漸擴展到運維安全、安全風控、安全合規等各個方面，並自主進行了WAF和IDS等系統的研發。
這個方向確實有很多其獨特的地方，但放下其餘幾個不表，至少在應用安全這個方向，「神祕的安全測試人員」（通常咱們也喜歡招聘有滲透經驗的白帽子們）不光是名字跟軟件測試人員同樣都有「測試」二字，所作的事情在本質上也是跟軟件測試人員有不少相通。

持續交付中的安全測試

回到持續交付這個話題，在過往的軟件研發過程當中，安全測試（相似的也包括性能、APP專項等測試）因爲其專業性，通常是做爲軟件開發的較末環節開始手工執行和驗收。但持續交付/devops的大潮提升了速度並擴張了規模，讓安全和性能等專項團隊也面臨着新的挑戰。爲確保快速開發和新功能部署，安全團隊必須確保安全評估的頻率，既要保證安全風險最小化，同時也要考慮安全團隊有限資源的可持續性，權衡DevOps速度與現有安全要求的需求也在安全行業內催生了一個名爲DevSecOps的模型（相似的還有DevTestOps的概念,不詳細展述）。
即便在持續集成（CI）和持續交付（CD）過程當中還不能實現完整的自動化軟件安全評估（人工的滲透測試依然不可缺乏），但這個方向仍然有很多能夠自動化實施的實踐。其中自動化的靜態代碼掃描，依賴組件掃描以及初級的滲透測試均可以比較容易的在交付流水線中實現，參見下面截圖。

 

 

代碼安全檢查

利用靜態代碼掃描工具對代碼在編譯以前進行掃描，並在靜態代碼層面上發現各類問題，其中包括安全問題。部分工具列表：

 

爲了方便與sonarQube集成，咱們使用的是FindbugSecurity,根據企業實際狀況精簡了規則，在持續構建的過程當中，會進行代碼靜態安全檢查。

 

經過檢查能夠很快代碼中sql注入，XSS、密碼硬編碼存儲、不安全配置等問題。

 

 

pipeline中只須要集成sonarqube的代碼檢查便可，經過sonar的質量閾判斷pipeline是否經過。

stage('靜態檢查') { when { expression {return isCA} } steps { echo "starting codeAnalyze with SonarQube......" //sonar:sonar.QualityGate should pass withSonarQubeEnv('SonarQube') { //固定使用項目根目錄${basedir}下的pom.xml進行代碼檢查 sh "mvn -f pom.xml clean compile sonar:sonar" } script { timeout(10) { def qg = waitForQualityGate() if (qg.status != 'OK') { error "未經過Sonarqube的代碼質量閾檢查，請及時修改！failure: ${qg.status}" } } } } } 

依賴組件安全檢查

因爲當前服務器應用依賴的第三方的庫和框架愈來愈多、愈來愈複雜，好比SSL、Spring、Rails、Hibernate、.Net，以及各類第三方認證系統等。並且系統開發的時候通常選定某個版本後在很長一段時間內都不會更新，由於更新的成本通常都比較高。可是每每這些依賴爲了添加新的功能和修復各類當前的問題——固然包括安全問題，卻會常常更新。開源項目的安全問題只要被發現之後，一般都會被公佈到網上去，好比CVE、CWE等，致使不少人均可能利用它去攻擊使用這些依賴的系統。好比說這兩年出盡風頭的萬年漏洞王 Struts2每次在0DAY漏洞爆發後，都形成了大量的網站淪陷，對整個互聯網行業都形成了嚴重恐慌。
依賴組件檢查就是經過掃描當前系統使用到的全部第三方依賴，並和網上公佈的安全漏洞庫進行比較，若是當前某個第三方依賴存在某種危險級別（須要本身定義）的漏洞，就當即發出警告（好比經過pipeline阻止發佈等）來通知開發人員或者系統管理員，從而在最短的時間內修復這個問題，防止攻擊，避免或者減小損失。
部分工具列表：

 

 

咱們使用Dependency-Check來作組件檢查，先在Jenkins中安裝OWASP Dependency-Check Plugin插件，並在pipiline中增長對應stage

stage('依賴安全檢查') { when { expression {return isDC} } steps{ //指定檢測**/lib/*.jar的組件 dependencyCheckAnalyzer datadir: '', hintsFile: '', includeCsvReports: false, includeHtmlReports: false, includeJsonReports: false, isAutoupdateDisabled: false, outdir: '', scanpath: '**/lib/*.jar', skipOnScmChange: false, skipOnUpstreamChange: false, suppressionFile: '', zipExtensions: '' //有高級別組件漏洞時，fail掉pipeline dependencyCheckPublisher canComputeNew: false, defaultEncoding: '', failedTotalHigh: '0', healthy: '', pattern: '', unHealthy: '' } } 

組件檢查結果以下

 

重點關注存在高危漏洞的組件

 

安全漏洞詳情

 

 

安全滲透掃描

此類方法通常適用在web安全測試領域，針對Web應用的安全掃描工具很是多，其中OWASP ZAP是免費軟件裏面最爲經常使用的。部分工具列表：

 

web安全掃描通常分爲兩種類型：主動掃描和被動掃描。
主動掃描
主動掃描是首先給定須要掃描的系統地址，掃描工具經過某種方式訪問這個地址，如使用各類已知漏洞模型進行訪問，並根據系統返回的結果斷定系統存在哪些漏洞；或者在訪問請求中嵌入各類隨機數據（模糊測試）進行一些簡單的滲透性測試和弱口令測試等。主動掃描覆蓋測試面會比較大，但缺點是完成一次全面掃描很是耗時(通常都須要幾個小時)，因此咱們沒有選用這種方式在pipeline中進行集成，更合適的方式可能仍是搞個job在半夜的時候作定時掃描而後次日來查看掃描報告。
被動掃描
被動掃描的基本原理就是設置掃描工具爲一個Proxy Server，功能測試經過這個代理服務訪問系統，掃描工具能夠截獲全部的交互數據並進行分析，經過與已知安全問題進行模式匹配，從而發現系統中可能的安全缺陷。在實踐中，爲了更容易地集成到CI，若是有比較完善的Web自動化測試用例，通常會在運行自動化功能測試的時候使用被動掃描方法，從而實現持續安全掃描。

 

被動掃描的具體實現也很是簡單，在下載安裝好ZAP後，後續的過程均可以在pipeline上進行組織。
1.配置WebDriver,爲其設置代理到ZAP的地址
2.啓動ZAP並運行web自動化測試：zapStart build -Dzap.proxy=localhost:7070，執行web自動化測試腳本
3.生成安全測試報告：zapReport
4.關閉ZAP：zapStop
備註：若是要執行主動掃描可使用命令「zapStart zapScan」，在執行過程當中使用「zapScanStatus」查看狀態，當掃描完成後，生成安全掃描報告並關閉ZAP「zapReport zapStop」。

 

安全測試報告：

 

 

相對於代碼安全檢查和依賴組件檢查，安全滲透掃描適用的場景較少，在web自動化用例不是太豐富的狀況效果比較有限，不過仍是能夠做爲一個安全滲透的冒煙測試，在專業滲透測試工程師資源有限的狀況下提供一個安全基線的檢查。

結語

安全測試是個很是複雜的過程，依靠自動化掃描器並不能發現全部的安全問題，可是它能夠在較小投入的狀況下持續發現大部分系統的基礎安全問題。若是須要更高級別的安全保障，人工滲透性測試和威脅建模等必不可少，成本也是相對較高的。但安全測試毫不應該是測試工程師的禁區，不論是在測試思想仍是工程實踐上，安全測試都脫離不了持續交付和敏捷的軟件工程體系。相信將來安全測試，也確定會和軟件研發測試的過程結合的愈來愈緊密，而再也不是如今這樣只限於白帽子這個小衆的圈子。因此這裏致全部測試同仁們，讓咱們也開始作安全測試吧。