前言

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自動化用例不是太豐富的情況效果比較有限，不過還是可以作為一個安全滲透的冒煙測試，在專業滲透測試工程師資源有限的情況下提供一個安全基線的檢查。

結語

安全測試是個非常復雜的過程，依靠自動化掃描器並不能發現所有的安全問題，但是它可以在較小投入的情況下持續發現大部分系統的基礎安全問題。如果需要更高級別的安全保障，人工滲透性測試和威脅建模等必不可少，成本也是相對較高的。
但安全測試絕不應該是測試工程師的禁區，不管是在測試思想還是工程實踐上，安全測試都脫離不了持續交付和敏捷的軟件工程體系。相信未來安全測試，也肯定會和軟件研發測試的過程結合的越來越緊密，而不再是現在這樣只限於白帽子這個小眾的圈子。
所以這裏致所有測試同仁們，讓我們也開始做安全測試吧。

[持續交付實踐] 安全掃描自動化測試平臺實現