作者簡介

Living，攜程高級基礎(chǔ)安全工程師，關(guān)注應(yīng)用安全、滲透測試方面的技術(shù)。

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

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

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

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

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

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

?

二、攜程DevSecOps實(shí)踐

2.1 安全團(tuán)隊(duì)建設(shè)&安全意識培養(yǎng)

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

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

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

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

?

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

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

?????? 場景——標(biāo)簽（多對多）

?????? 標(biāo)簽——威脅（一對多）

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

場景和標(biāo)簽的對應(yīng)關(guān)系如下：

???????

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

在標(biāo)簽與威脅的對應(yīng)關(guān)系上，“爆破”標(biāo)簽對應(yīng)的威脅有“驗(yàn)證碼爆破”和“萬能驗(yàn)證碼”，具體的威脅模型如下：

???????

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

?

2.3 SCA???????

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

為了解決漏洞修復(fù)問題，我們進(jìn)行了一些維度的劃分，包括：

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

• 對應(yīng)CVE是否有POC

• 應(yīng)用內(nèi)外網(wǎng)屬性

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

?

2.4 SAST???????

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

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

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

???????

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

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

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

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

?

2.5 IAST/DAST

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

1）IAST agent

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

2）IAST服務(wù)端

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

3）流量kafka隊(duì)列

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

4）分布式掃描器

消費(fèi)kafka里的流量并且按照url去重，調(diào)用掃描器進(jìn)行漏洞掃描。

??

這樣一套架構(gòu)的好處在于：

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

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

• 誤報(bào)率低：IAST的特性決定的低誤報(bào)

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

?

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

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

1）漏洞跟蹤

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

2）漏洞統(tǒng)計(jì)

按漏洞類型、時(shí)間、嚴(yán)重等級、來源各個(gè)維度進(jìn)行統(tǒng)計(jì)和分析。

3）漏洞復(fù)盤

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。