作者簡介

Living，攜程高級基礎安全工程師，關注應用安全、滲透測試方面的技術。

一、DevSecOps面臨的挑戰(zhàn)

作為業(yè)務覆蓋機票、酒店、度假、汽車票、火車票、支付等各個方面，為全球用戶提供服務的在線旅游網站，攜程每周都會有數以萬計的應用發(fā)布次數，如何保證每一次發(fā)布代碼的安全性成為了DevSecOps實踐中最大的挑戰(zhàn)。

不同于軟件行業(yè)的SDL，DevOps和微服務在互聯網行業(yè)的興起使得安全不再是安全團隊可以獨立完成的任務，如何把安全嵌入DevSecOps的每一個流程，保證代碼的安全，首先面臨的問題是人力。

在軟件行業(yè)，一個版本的發(fā)布從涉及到開發(fā)、測試、發(fā)布動輒數月，每個版本的發(fā)布都可以按照SDL流程完整地做一次安全評估，包括需求評審、威脅建模、安全開發(fā)、安全掃描。而在CI／CD模型下，每天都有幾千次的發(fā)布，持續(xù)集成、持續(xù)部署，如何避免持續(xù)引入漏洞，僅僅靠人力是無法解決的。

另一個很重要的問題是如何培養(yǎng)安全意識——避免兩次踩進同一個坑。相信做安全的同學都會遇到這樣的問題：昨天剛找開發(fā)修了一個SQL注入，今天又寫了另一處有注入的接口；昨天剛補了一處撞庫接口，今天又來了一個驗證碼繞過。安全淪為救火隊長，疲于奔命。其實本質還是需要提高業(yè)務團隊的整體安全意識，避免安全變成被動的修補角色。

第三個問題是安全項目的推動難，對于安全工程師來說最差的體驗是，“在甲方提工單和在乙方貼發(fā)票”。為什么推動這么困難，原因在于對業(yè)務團隊來說這似乎是增加了額外的工作量，僅僅是修復一個漏洞就需要開發(fā)、測試甚至產品一起溝通拉齊，確定修復方案、排期，更不要說大規(guī)模的推動底層的框架、中間件的升級，一輪一輪的推動更是難上加難。而解決這些需要與公司框架、與CI／CD流程更緊密的結合，提供溫和嵌入流程的默認安全方案。

?

二、攜程DevSecOps實踐

2.1 安全團隊建設&安全意識培養(yǎng)

今年年初我們在攜程內部組建了安全BP制，即每個事業(yè)部指定一名安全負責人，負責BU內部的安全事項，協助安全部推動研發(fā)團隊的安全建設。擔任安全BP的通常是研發(fā)團隊的開發(fā)leader或者測試leader。指定安全BP的好處在于：安全BP作為BU研發(fā)團隊成員，更了解BU內部開發(fā)測試流程，相比安全部門能夠更方便推動BU內部的安全項目落地。安全BP也是DevSecOps流程里面安全左移的重要角色，讓安全更早介入DevOps流程。???????

在攜程內部安全BP的運作方式是每月有一次各BU安全BP的交流會，安全部會在BP會上提出需要BP協助推動的工作，同時BP也會反饋安全建設遇到的各種問題，以及提出安全訴求。???????

目前在攜程內部通過BP推動落地的項目有IAST、fastjson升級等。以IAST項目的落地為例，如果沒有安全BP，推動接入IAST的流程就是安全部->應用負責人。對于應用負責人來說，大多數不了解也不理解安全項目的需求，推動難度可想而知。

而在有安全BP的場景下，對接流程變?yōu)榱税踩?>安全BP->應用負責人，安全BP以提升自身業(yè)務安全的角度去推進，解決了安全與研發(fā)之間的矛盾，從而更加高效地推動安全項目的落地。安全BP作為安全部門與業(yè)務研發(fā)部門之間溝通的橋梁，也向安全部反饋了項目落地中遇到的問題以及BU的訴求。比如說安全部的Web黑盒掃描，對于BU來說，需要解決掃描過程中產生臟數據的問題，這樣的訴求都是通過BP來反饋到安全部的。

?

2.2 安全評審&威脅建模??????

作為DevSecOps計劃階段重要的一環(huán)，威脅建模在攜程的實踐方式是對接公司內部的看板團隊協作平臺，面對各業(yè)務產品經理（即用戶）。用戶在看板平臺上提交需求的時候，可以按照業(yè)務場景選擇威脅建模的場景，系統(tǒng)根據內置模型中每種（業(yè)務）場景對應的威脅給出緩解措施。其對應關系是：

?????? 場景——標簽（多對多）

?????? 標簽——威脅（一對多）

?????? 威脅——緩解措施（一對一）???????

場景和標簽的對應關系如下：

???????

以“爆破”這個標簽為例，“爆破”對應的（業(yè)務）場景有“登錄”、“注冊”、“忘記密碼”、“驗證碼”、“支付”，而“登錄”、“注冊”、“忘記密碼”、“驗證碼”這幾個場景又同時對應了“用戶名猜解”的標簽，這就形成了多對多的關系。???????

在標簽與威脅的對應關系上，“爆破”標簽對應的威脅有“驗證碼爆破”和“萬能驗證碼”，具體的威脅模型如下：

???????

威脅建模里的標簽和場景都是可以復用的模型，以這樣的方式，我們可以建立幾十種常見業(yè)務場景的威脅模型，從而實現威脅建模的自動化。產品經理在創(chuàng)建需求的時候，只要勾選對應場景即可自動完成建模并給出風險提示和對應的緩解措施。

?

2.3 SCA???????

SCA（Software Composition Analysis），第三方組件的安全檢查。作為攜程落地比較早的項目，在應用CI的過程中進行掃描分析，對于掃描發(fā)現中高危級別漏洞的應用就會進行發(fā)布的攔截。在項目的初期，最大的問題是動輒上萬的漏洞告警，哪些漏洞需要修復，哪些漏洞不需要修復，哪些需要優(yōu)先修復。

為了解決漏洞修復問題，我們進行了一些維度的劃分，包括：

• 漏洞等級（高、中、低）

• 對應CVE是否有POC

• 應用內外網屬性

對于外網應用中有POC的漏洞會優(yōu)先修復，而內網應用和沒有POC的漏洞緊急性會比較低。除此之外，還按照漏洞歸屬進行了劃分，區(qū)分框架漏洞和應用漏洞。對于框架引入的第三方組件漏洞，會協調公司內部框架修復。通過這樣的方式減少了大量的漏洞告警，使得SCA嵌入CI/CD流程對發(fā)布流程的影響降到最低。

?

2.4 SAST???????

SAST（Static Application Security Testing）靜態(tài)應用測試，對應的是研發(fā)階段的代碼掃描。在攜程，SAST有兩套不同的代碼掃描引擎，一個是基于文本掃描的正則規(guī)則掃描，一個是基于構建的數據流、控制流掃描。???????

正則掃描用于在CI/CD流程中的快速檢測，每個項目的掃描時間平均在10秒左右，可以完全串入CI/CD流程，對于開發(fā)流程幾乎不會增加額外的時間。正則掃描代碼的好處在于快速，這也就意味著可以用于應急響應中的全量代碼掃描，比如說對于一些代碼中配置的掃描或者特殊函數的調用檢測。

同時其缺點也很明顯，對于一些需要理解代碼上下文的漏洞誤報率高，比如SQL注入。對于這樣的漏洞，使用正則掃描器掃到不會直接推給開發(fā)，而是會先經過安全運營的確認。在漏洞確認前，CI/CD流程不會被阻攔，漏洞確認后如果下一次掃描仍然掃到同樣漏洞才會攔截。

???????

基于數據流、控制流的代碼掃描與CI/CD流程的關系可以說是“旁路”。在CI/CD的過程中，代碼同步進行掃描，但CI/CD不會等待掃描結束。因為掃描時間通常較久，根據項目的代碼量從幾分鐘到幾十分鐘不等。這種掃描對于SQL注入、命令執(zhí)行這樣的漏洞檢測準確率是比較高的，在我們優(yōu)化過規(guī)則之后準確率可以到95%以上。對于這部分掃描到的漏洞，會通過內部的漏洞管理平臺提交給代碼owner進行修復。

關于白盒掃描的規(guī)則優(yōu)化???????

誤報：在內部SAST平臺上，我們會統(tǒng)計每個類型規(guī)則的準確率，并且定一個閾值（比如90%），對于準確率超過閾值的規(guī)則，后續(xù)掃出來的漏洞都會直接推送給代碼owner進行修復。而準確率低于閾值的規(guī)則，則會先經過安全內部運營審核，確認之后再推送，以確保推送給開發(fā)的安全漏洞不會有太多誤報。此外，在運營的過程中不斷地提煉規(guī)則，提高準確率，當準確率達到直接推送的準確率后就會完全自動化運行，降低安全運營的人力成本。???????

漏報：對于通過其他渠道檢測到而白盒掃描未檢測到的漏洞，如果是通用代碼漏洞規(guī)則未能覆蓋的，通常是因為應用代碼使用了內部框架提供的api，對應數據流的source和sink未能被通用規(guī)則覆蓋。這部分漏洞我們會針對內部框架增加對應的source和sink規(guī)則，以提高白盒掃描的漏洞覆蓋率，通過外部白帽子、src、iast、dast、dbaudit等sdl縱深防御體系來完善規(guī)則的漏報問題。

?

2.5 IAST/DAST

IAST/DAST在攜程的實踐是IAST agent被動檢測+分布式掃描器主動掃描的方式。可以分為這么幾個部分：

1）IAST agent

集成到測試環(huán)境應用docker容器的agent，hook tomcat底層調用，用來檢測應用中的漏洞，同時會把所有訪問到應用docker的http流量復制回傳到用于收集流量的kafka隊列。

2）IAST服務端

管理IAST agent和漏洞的控制臺。

3）流量kafka隊列

用于收集待掃描的流量，除了從IASTagent回傳的流量，還有來自主動爬蟲、chrome插件以及提測平臺調用api發(fā)送過來的流量。

4）分布式掃描器

消費kafka里的流量并且按照url去重，調用掃描器進行漏洞掃描。

??

這樣一套架構的好處在于：

• 掃描覆蓋率高：只要正常功能測試能覆蓋的流量都能被掃到

• 漏洞檢出率高：IAST+DAST雙重檢測

• 誤報率低：IAST的特性決定的低誤報

這套掃描系統(tǒng)在少量應用灰度期間就發(fā)現了內部存在已久未被發(fā)現的通用型漏洞，對于內部安全檢測能力的補齊提供了很好的幫助。

?

2.6 漏洞管理???????

作為DevSecOps流程中重要的一環(huán)，漏洞管理平臺是不可或缺的一部分，攜程內部使用的自研漏洞平臺實現了從漏洞發(fā)現、修復，到復盤的整個流程跟蹤。漏洞管理流程包括：

1）漏洞跟蹤

從漏洞發(fā)現生成工單到修復完成關閉工單。

2）漏洞統(tǒng)計

按漏洞類型、時間、嚴重等級、來源各個維度進行統(tǒng)計和分析。

3）漏洞復盤

攜程內部對于內外部發(fā)現的漏洞都會進行復盤。對于外部漏洞，會復盤內部工具、流程是否能發(fā)現，記錄未能發(fā)現的原因和改進措施。對于內部發(fā)現的漏洞，比如黑盒掃到的漏洞，會考慮白盒是否也能發(fā)現。如果不能，是否可以通過改進規(guī)則發(fā)現，通過這樣的方式提高內部工具的漏洞檢出率。

目前在攜程SAST、SCA每周的掃描量約3萬任務數，安全評審數量每周約100，內部發(fā)現的漏洞數占全部漏洞數的95%以上，其中99%以上為工具自動發(fā)現，漏洞閉環(huán)率100%。

總的來說，DevSecOps的關鍵在于嵌入CI/CD流程，更少地對開發(fā)流程的阻礙、自動化的測試工具以及與業(yè)務研發(fā)更緊密的合作。

總結

以上是生活随笔為你收集整理的干货 | DevSecOps在携程的最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。