《百家講壇》征稿啟事

CONTRIBUTIONS WANTED

百家講壇 | 原創(chuàng)稿件征集活動(dòng)開啟！

《網(wǎng)安加 · 百家講壇》立足于網(wǎng)絡(luò)安全發(fā)展時(shí)勢，面向網(wǎng)絡(luò)安全、軟件研發(fā)與測試、軟件質(zhì)量領(lǐng)域的專家，廣納遠(yuǎn)見

卓識，以展現(xiàn)不同角度不同專業(yè)意見，為行業(yè)人員提供最新資訊。

現(xiàn)有獎(jiǎng)?wù)魑那勒介_啟，歡迎各路專家打包投遞。

投稿須知 :

1、字?jǐn)?shù)：1500 字及以上；

2、稿費(fèi)：200 元 / 千字，上限 800 元；

3、投稿作品需為原創(chuàng)作品，杜絕硬廣，要求主題鮮明，

圖文并茂最佳；

4、投稿形式：以 Word 文字版發(fā)送；

5、投遞稿件需經(jīng)過審核，審核通過即錄用稿件。

獎(jiǎng)項(xiàng)設(shè)置 :

1、入選稿件，按稿件字?jǐn)?shù)，作者可獲得相應(yīng)稿費(fèi)；

2、以季度為期，每期稿件閱讀量 PK，當(dāng)月文章閱讀

量首位文章的作者額外獲得 1000 元獎(jiǎng)金，具體以每月

最后一個(gè)工作日公布消息為準(zhǔn)。

關(guān)于百家講壇 :

《網(wǎng)安加·百家講壇》是由 100+ 資深軟件開發(fā)專家、

安全領(lǐng)域 KOL、甲方企業(yè) CSO 等直播分享的“理論 +

實(shí)踐 + 案例”專業(yè)內(nèi)容，目前定期為 2000+ 政企、大

型互聯(lián)網(wǎng)、金融、高校等提供內(nèi)部資料參考。

選題范圍：

聚焦于軟件研發(fā)效能、軟件安全開發(fā)、DevSecOps、

SDL、軟件供應(yīng)鏈安全、云原生安全、數(shù)據(jù)安全等領(lǐng)域

的各種新銳觀點(diǎn)、技術(shù)分享。

投稿渠道：

添加微信：xiaoankt02 進(jìn)行投稿，請備注“姓名 + 主

題”，并發(fā)送個(gè)人簡介。

投稿形式：以 Word 文字版發(fā)送，入選稿件不返稿底，

請自留稿底。

免責(zé)聲明：

本資料由網(wǎng)安加社區(qū)整理，內(nèi)部所有文章均與作者確

認(rèn)核對，且資料僅供內(nèi)部學(xué)習(xí)交流使用，未經(jīng)網(wǎng)安加

社區(qū)允許，其他人員不得復(fù)制。

* 最終解釋權(quán)由網(wǎng)安加社區(qū)所有

GPT-4 等人工智能大模型橫空出世，成為近段時(shí)間科技圈長時(shí)間持續(xù)的熱門

話題。我們觀察到網(wǎng)絡(luò)空間的攻防雙方，實(shí)際在很長一段時(shí)間處于相對平衡的狀

態(tài)，但隨著 AI 大模型技術(shù)的出現(xiàn)及在安全行業(yè)的廣泛應(yīng)用，必將再次動(dòng)態(tài)重構(gòu)這

個(gè)平衡，各方迭代進(jìn)化的速度，將決高低、也決生死。

網(wǎng)安加社區(qū)軟件開發(fā)及安全領(lǐng)域的眾多專家緊跟前沿，對于 AI 大模型技術(shù)

給網(wǎng)絡(luò)安全及軟件開發(fā)領(lǐng)域帶來的深遠(yuǎn)影響，做了非常有價(jià)值的工程實(shí)踐探索，

相信這些成果對安全行業(yè)的發(fā)展會(huì)起到促進(jìn)作用。

同期另一件事件同樣引起我的關(guān)注，由于引用的開源組件里的一個(gè) bug，導(dǎo)

致 ChatGPT 出現(xiàn)嚴(yán)重的個(gè)人信息泄露事件。拋去光芒，ChatGPT 依然是一款軟件，

幾乎所有軟件都引用了開源組件，因此，開源組件的安全治理在軟件定義一切的

時(shí)代也是一道必答題。

行業(yè)的問題，就是我們網(wǎng)安加社區(qū)的工作方向，我們將持續(xù)開展相關(guān)最佳實(shí)

踐的交流探討，希望各位有志之士也一同加入進(jìn)來，見證成長。

網(wǎng)絡(luò)安全的奇點(diǎn)將至

網(wǎng)安加社區(qū)創(chuàng)始人：

卷首語/PROLOGUE FOREWORD

從兩個(gè)舊案談軟件安全的重要性

ChatGPT 在互聯(lián)網(wǎng)安全研發(fā)領(lǐng)域的變革作用

淺談 ChatGPT 和網(wǎng)絡(luò)安全行業(yè)的愛恨情仇

開源安全治理解決方案分享

淺談開源治理

DevSecOps 實(shí)踐：如何在研發(fā)過程中做好供應(yīng)鏈安全

DevSecOps 度量和正確的使用方式

OWASP 中國 S-SDLC CMM 項(xiàng)目介紹

軟件安全研發(fā)建設(shè)之路

安全與業(yè)務(wù)戰(zhàn)略一致性的理想與現(xiàn)實(shí)

漫談安全的兩三事

OCBC 框架下企業(yè)云化 CSPM 落地思考和實(shí)踐探索

多場景下的安全運(yùn)營集約化

API 安全與實(shí)踐

甲方的個(gè)人信息保護(hù)實(shí)踐

護(hù)網(wǎng)行動(dòng)和企業(yè)信息安全體系治理邏輯

網(wǎng)安大咖說第一期 | 拐點(diǎn)已至——2023安全新風(fēng)口

網(wǎng)安大咖說第二期 | AI狂飆——ChatGPT會(huì)顛覆網(wǎng)絡(luò)安全行業(yè)嗎？

線下活動(dòng)| “ChatGPT對研發(fā)管理的沖擊與契機(jī)”線下沙龍成功舉辦圓滿

線下活動(dòng)| 開源安全治理行業(yè)最佳落地實(shí)踐私享會(huì)成功舉辦

線下活動(dòng)| 2023 CI/CD安全技術(shù)研討會(huì)成功舉辦

專家招募

專家入駐

02 百花齊放

01 百家論道 04

06

12

15

20

24

27

32

35

39

42

46

51

56

65

68

71

71

72

72

74

75

76

CONTENTS/目錄

4

百家論道 LECTURE ROOM

從兩個(gè)舊案

談軟件安全的重要性

國內(nèi)知名網(wǎng)絡(luò)安全專家，

研究方向?yàn)樾畔踩燃壉Ｗo(hù)、

工業(yè)控制網(wǎng)絡(luò)安全、智慧城市網(wǎng)

絡(luò)安全體系框架等。曾任工業(yè)控

制系統(tǒng)信息安全技術(shù)國家工程實(shí)

驗(yàn)室專家委員；貴陽市攻防演練

技術(shù)總策劃，攻防演練風(fēng)險(xiǎn)管控

平臺總設(shè)計(jì)師；貴陽大數(shù)據(jù)安全

靶場顧問；福州市政府特聘網(wǎng)絡(luò)

安全專家；第一屆、第二屆和第

四屆數(shù)字中國建設(shè)峰會(huì)網(wǎng)絡(luò)安全

保障專家組組長；雄安新區(qū)網(wǎng)絡(luò)

安全首席顧問。編寫著作三部，

發(fā)表各類文章百余篇，授權(quán)發(fā)明

專利三項(xiàng)。

陸寶華

二十多年前，筆者親自辦過兩個(gè)案件。

第一個(gè)，當(dāng)時(shí)某計(jì)劃單列市的政府某部門的服務(wù)器，向國外的邪教網(wǎng)站發(fā)

送邪教的材料和文章，被上級部門監(jiān)控到了，案件不需要太多的偵查，很快就

破案了。是為這個(gè)政府部門開發(fā)軟件的企業(yè)的技術(shù)總監(jiān)干的，他利用遠(yuǎn)程登錄

到系統(tǒng)后臺，使用政府服務(wù)器，發(fā)送了相關(guān)反動(dòng)數(shù)據(jù)。后經(jīng)查實(shí)他本人是邪教

組織的重要成員。

第二個(gè)，還是這個(gè)城市的交警的違章罰款系統(tǒng)，被人非法使用，刪除了大

量的違章人員的數(shù)據(jù)。偵查也不困難，是為交警開發(fā)軟件系統(tǒng)的企業(yè)的技術(shù)核

心人員，與檢車線上的檢車員相互勾結(jié)，由檢車員向違章司機(jī)收取罰款，然后

電話告訴這個(gè)技術(shù)人員，他遠(yuǎn)程后臺刪除。

這兩個(gè)案件，都是由軟件企業(yè)為政府系統(tǒng)開發(fā)的軟件上預(yù)留了相應(yīng)的后門

而導(dǎo)致的。雖然案件過去二十多年，但是，對于今天來說仍有警示作用。

首先，這兩個(gè)軟件上線時(shí)，只做了功能檢測，而沒有相應(yīng)的安全檢測，實(shí)

際上這倆當(dāng)事人，都考慮了可能會(huì)有安全檢測這個(gè)環(huán)節(jié)，他們提供的用于測試

的軟件（僅為功能測試）與安裝運(yùn)行的軟件并不是一個(gè)版本。

這就出現(xiàn)了兩個(gè)問題，一是沒有進(jìn)行安全檢測，二是即使是進(jìn)行了安全檢

測，由于安裝的版本與被檢測的版本并不一致，給了作案人員可乘之機(jī)。

同時(shí)也說明了兩個(gè)問題，一是上線的軟件一定要進(jìn)行安全檢測，二是一定

要保證軟件的檢測版本與安裝運(yùn)行版本必須保持一致。

實(shí)際上，這兩起案件都是預(yù)留了遠(yuǎn)程登錄的接口，算是后門，技術(shù)上不高

明，更不復(fù)雜，并且作案人沒有專業(yè)黑客的本領(lǐng)，否則作案人把作案活動(dòng)的痕

跡都打掃干凈，那案件偵破難度將大幅提升。

對于第二個(gè)方面，國際標(biāo)準(zhǔn) ISO15408 中的第三部分，“分發(fā)與操作”中，

就有明確的規(guī)定，說心里話，沒經(jīng)過這兩起案件時(shí)，雖然記住了相關(guān)的要求，

但是對相關(guān)的意義的理解還不是那么深，正是革命導(dǎo)師所說“感知了的東西，

我們并一定理解它，而理解了的東西，我們一定會(huì)更深刻地感知它?！?/p>

實(shí)際上，除了這兩個(gè)案件之外，在筆者的工作中，還發(fā)現(xiàn)過某企業(yè)為政府

開發(fā)的網(wǎng)站，普遍存在同樣的漏洞，實(shí)際上這個(gè)企業(yè)就是想降低成本，把一個(gè)

帶有明顯漏洞的軟件模塊直接拿來用，為多家單位開發(fā)了網(wǎng)站。

應(yīng)該說，近年來由于各種管理機(jī)制的不斷健全，軟件開發(fā)企業(yè)的行為也得

到了規(guī)范，故意預(yù)留后門和不經(jīng)安全檢測就將一些模塊拿來用的現(xiàn)象已少有發(fā)

生，但是并沒有杜絕。

2019 年底，為確保雄安新區(qū)某局的重要業(yè)務(wù)系統(tǒng)軟件的安全，我通知開發(fā)

商（國內(nèi)一個(gè)相當(dāng)著名的企業(yè)），要對他們的軟件進(jìn)行安全檢測。該企業(yè)得到通

知后，高度重視，充分準(zhǔn)備，自行做了軟件的黑盒安全檢測和白盒代碼審計(jì)工

5

LECTURE ROOM 百家論道

作。但在 2020 年 4 月份檢測工作實(shí)際開展過程中，通過

使用一個(gè)國內(nèi)廠家的灰盒安全測試工具進(jìn)行檢測，軟件

中一個(gè)不算大的模塊，查出四個(gè)高危和七個(gè)中危漏洞，

吃驚之余，軟件開發(fā)商與工具提供商就檢出漏洞進(jìn)行了

充分溝通，最終對檢測結(jié)果非常認(rèn)可。

黑盒檢測，很難照顧到全面，往往是一條線打進(jìn)去

了，也就認(rèn)為檢測到了問題，沒打進(jìn)去也就認(rèn)為相對是

安全了。白盒看上去很全面，但是代碼審計(jì)不是那么容

易做的。并不是說這兩個(gè)檢測不重要，而是說這樣的檢

測是不夠的。灰盒檢測，通過“插樁”技術(shù)實(shí)現(xiàn)交互式

的檢測，發(fā)現(xiàn)的確定性問題更多、定位也更精準(zhǔn)。建議

是這三種檢測都應(yīng)該做，特別是對安全性要求較高的應(yīng)

用程序，灰盒一定要做。

軟件的安全，是網(wǎng)絡(luò)空間安全的生命線，一個(gè)系

統(tǒng)，沒有軟件，也就沒什么用處，當(dāng)然也就沒有數(shù)據(jù)，

更談不是系統(tǒng)的服務(wù)功能。也就不用談安全了。那么，

我們建系統(tǒng)干嘛呢？

十多年以來，軟件定義一切的口號叫得很響，并且

也確實(shí)在穩(wěn)步地推進(jìn)，軟件定義一切是必要的，可如果

軟件本身不安全，那所定義的一切，還有安全可言嗎 ?

軟件安全，應(yīng)該分為系統(tǒng)軟件安全、中間件安全和

應(yīng)用程序的安全。系統(tǒng)軟件，就那么幾家，中間件的開

發(fā)商也不算多，這種檢測的機(jī)制和能力，不是我們各個(gè)

單位所具有的。

系統(tǒng)軟件和通用中間件的開發(fā)商，往往有很龐大的

檢測隊(duì)伍和機(jī)制，相對來說檢測的能力很強(qiáng)大，但仍然

會(huì)時(shí)不時(shí)曝出一些漏洞，有些漏洞甚至已經(jīng)成為了一些

網(wǎng)絡(luò)戰(zhàn)的工具。而應(yīng)用程序的開發(fā)商，缺少這種檢測能

力，軟件本身的安全性實(shí)際上更差。用軟件定義一切，

恰恰不是由系統(tǒng)軟件決定的，應(yīng)用軟件是定義這一切的

決定因素。

應(yīng)用軟件的安全檢測，是我們保障安全的關(guān)鍵所

在。筆者一直認(rèn)為，對于由他人的侵害所導(dǎo)致的安全問

題（我們就叫它“人禍”吧），解決的根本方法是“保證

正確的授權(quán)操作”。這里包含了三層意思，一是操作需要

授權(quán)；二是授權(quán)必須正確；三是正確的授權(quán)操作機(jī)制必

須有保證。

對應(yīng)用程序來說，這三個(gè)方面往往都需要考慮：

授權(quán)機(jī)制，可以通過操作系統(tǒng)等系統(tǒng)軟件來實(shí)現(xiàn)，

但是，這些系統(tǒng)軟件很難將訪問控制的顆粒度做得很

細(xì)，建立一個(gè)主體，對應(yīng)一個(gè)客體的訪問授權(quán)機(jī)制。一

個(gè)應(yīng)用，對于操作系統(tǒng)來說，就是一個(gè)客體，而所有有

權(quán)訪問這個(gè)客體的人，操作系統(tǒng)都得放行。這就需要在

應(yīng)用程序中建立更細(xì)顆粒度的訪問控制機(jī)制（授權(quán)操作

機(jī)制）。所以說，軟件安全并不僅僅是查漏洞，如果安全

機(jī)制沒有真正的建立，那么就等于把前面打開，隨便進(jìn)

入了，那么就不需要什么黑客技術(shù)了。

應(yīng)用程序要不要建立安全機(jī)制，實(shí)際上要結(jié)合系

統(tǒng)來分析，當(dāng)操作系統(tǒng)等系統(tǒng)軟件能夠完全解決授權(quán)操

作的問題時(shí)，當(dāng)然不必在應(yīng)用程序中再畫蛇添足，并且

操作系統(tǒng)等系統(tǒng)軟件更底層，解決安全問題會(huì)更可靠一

些。當(dāng)操作系統(tǒng)不能細(xì)粒度地建立這種訪問控制機(jī)制時(shí)，

就需要在應(yīng)用程序中來建立，與操作系統(tǒng)一起把“正確

的授權(quán)操作”機(jī)制建立起來。

軟件安全的另一個(gè)方面，當(dāng)然就是保障問題了，要

解決好“正確的授權(quán)操作”機(jī)制，不會(huì)被破壞，不會(huì)被

繞過，不會(huì)因各種因素而失效的問題。漏洞顯然是第一

大問題，這也是人們一提安全，就關(guān)注漏洞的原因。

前面說，漏洞的檢測可以是黑盒，也可以是白盒，

更可以是灰盒，如果進(jìn)行聯(lián)合檢測，就會(huì)使漏洞水平大

大降低。

除了漏洞之外，還有一個(gè)需要解決的保證因素：隱

蔽信道檢測問題。隱蔽信道，在計(jì)算環(huán)境中有存儲隱蔽信

道和同步隱蔽信道。在網(wǎng)絡(luò)環(huán)境中，隱蔽信道會(huì)更復(fù)雜。

對于應(yīng)用程序來說，主要面向的計(jì)算環(huán)境，所以要從同

步隱蔽信道和存儲隱蔽信道入手進(jìn)行檢測。當(dāng)然檢測還

是要考慮面向更高的安全等級的系統(tǒng)，GB 17859 中規(guī)定對

于安全第四級（結(jié)構(gòu)化保護(hù)級）以上級別才考慮隱蔽信

道問題。所以，更多的軟件保障問題，還是針對漏洞。

對于漏洞的檢測，實(shí)際上，我們還有很長的路要

走，這是因?yàn)槁┒礇]有辦法窮盡，并且一個(gè)漏洞修補(bǔ)之

后，很可能會(huì)產(chǎn)生新的漏洞。狀態(tài)機(jī)轉(zhuǎn)換的原理，對于

軟件的漏洞檢測是非常重要的，可惜開發(fā)是有很大難度

的。人工智能的出現(xiàn)，或許對軟件的漏洞檢測會(huì)提供更

好的幫助。

除了安全檢測工作，還要考慮所檢測的軟件與安裝

的軟件版本號必須一致，也就是說安裝的應(yīng)用程序，必

須是經(jīng)過檢測并且是合格的軟件。要保證這一點(diǎn)，實(shí)際

上并不難，一是可以將檢測過的程序進(jìn)行哈希，并將哈

希值和算法交給使用單位，使用單位可以對安裝的程序

進(jìn)行哈希后，進(jìn)行比對。還可以由檢測部門直接將檢測

合格的程序交由用戶單位。

最后，建議讀者認(rèn)真地讀一讀 ISO15408，盡管難

懂，但是管用。

6

百家論道 LECTURE ROOM

ChatGPT 在互聯(lián)網(wǎng)安全研發(fā)領(lǐng)

域的變革作用

華為土耳其研究所外聘高

級項(xiàng)目顧問，網(wǎng)安加社區(qū)特聘專

家，負(fù)責(zé)華為云應(yīng)用生態(tài)圈產(chǎn)品

線研發(fā)管理。曾為華為全球技術(shù)

服務(wù)中心、華為制造 IT 以及華為

流程 IT 解決方案提供等多個(gè)部

門提供長達(dá) 8 年的顧問服務(wù)。曾

任職環(huán)信科技華南區(qū)項(xiàng)目總監(jiān)，

金蝶國際軟件研發(fā)工程師。獲得

PMI-PMP、PMI-ACP、PRINCE2、

NPDP、MSP、P3O 等認(rèn)證。擁有 1

項(xiàng)國家專利，4 項(xiàng)軟件著作，具

有豐富的項(xiàng)目管理實(shí)戰(zhàn)經(jīng)驗(yàn)。

潘繼平

本文將會(huì)探討 ChatGPT 在互聯(lián)網(wǎng)安全研發(fā)領(lǐng)域的變革作用，以下是文章的

結(jié)構(gòu)圖：

一、引言與背景

（一）網(wǎng)絡(luò)安全挑戰(zhàn)

隨著互聯(lián)網(wǎng)的普及和技術(shù)的迅速發(fā)展，網(wǎng)絡(luò)安全面臨越來越多的挑戰(zhàn)。黑

客攻擊、數(shù)據(jù)泄露、惡意軟件和各種網(wǎng)絡(luò)犯罪活動(dòng)不斷威脅著個(gè)人和企業(yè)的數(shù)

據(jù)安全。軟件開發(fā)領(lǐng)域尤其容易受到網(wǎng)絡(luò)安全問題的影響，因?yàn)檐浖到y(tǒng)中的

漏洞往往是攻擊者利用的入口。

（二）軟件安全重要性

網(wǎng)絡(luò)軟件安全對于保護(hù)數(shù)據(jù)、確保用戶隱私和維護(hù)企業(yè)聲譽(yù)至關(guān)重要。一

個(gè)安全的軟件系統(tǒng)可以防止未經(jīng)授權(quán)的訪問和操作，保護(hù)敏感信息不被泄露。

而一個(gè)有安全漏洞的軟件系統(tǒng)可能會(huì)導(dǎo)致嚴(yán)重的后果，包括財(cái)產(chǎn)損失、法律責(zé)

任和品牌聲譽(yù)受損。因此，在軟件開發(fā)過程中關(guān)注安全問題并采取相應(yīng)的措施

至關(guān)重要。

（三）ChatGPT 與代碼分析

ChatGPT 是基于 OpenAI 的 GPT-X 架構(gòu)的人工智能語言模型，具有強(qiáng)大的自

然語言處理和理解能力。在許多應(yīng)用場景中，ChatGPT 表現(xiàn)出了優(yōu)異的性能，包

括文本生成、翻譯、問答和對話等。此外，ChatGPT還可以應(yīng)用于代碼分析領(lǐng)域，

7

LECTURE ROOM 百家論道

幫助識別潛在的安全漏洞、分析代碼風(fēng)險(xiǎn)、提供代碼優(yōu)

化建議和修復(fù)方案。

作為一種先進(jìn)的人工智能技術(shù)，ChatGPT 具有以下

潛在價(jià)值：

1、提高代碼審查效率：傳統(tǒng)的代碼審查過程通常需

要耗費(fèi)大量人力和時(shí)間。借助 ChatGPT，我們可以自動(dòng)

化地對代碼進(jìn)行分析，從而顯著提高審查效率和準(zhǔn)確性。

2、發(fā)現(xiàn)難以察覺的安全漏洞：由于 ChatGPT 具有強(qiáng)

大的模式識別能力，它可以在代碼中發(fā)現(xiàn)那些人類審查

員容易忽略的安全漏洞，提高軟件系統(tǒng)的整體安全性。

3、教育和培訓(xùn)：ChatGPT 可以作為一個(gè)教育工具，

幫助開發(fā)人員了解最佳實(shí)踐和安全編碼原則，提高他們

在編寫安全代碼方面的技能。

4、支持多語言和框架：ChatGPT 不僅支持 Java，還

可以處理其他編程語言和框架，這使其成為一種通用的

代碼分析工具，可廣泛應(yīng)用于各種軟件開發(fā)項(xiàng)目。

5、集成到現(xiàn)有的開發(fā)流程：ChatGPT 可以輕松地與

現(xiàn)有的開發(fā)工具和流程集成，例如持續(xù)集成 / 持續(xù)部署

（CI/CD）流程，從而在整個(gè)軟件開發(fā)周期中提供實(shí)時(shí)的

安全分析。

6、與現(xiàn)有安全工具協(xié)同作用：ChatGPT 可以與靜態(tài)

代碼分析（SAST）、動(dòng)態(tài)代碼分析（DAST）等現(xiàn)有安全工

具配合使用，共同提高代碼的安全性和質(zhì)量。

7、自動(dòng)化修復(fù)建議：ChatGPT 可以根據(jù)分析結(jié)果自

動(dòng)生成修復(fù)建議，從而幫助開發(fā)人員快速解決潛在的安

全問題。

8、安全審計(jì)和合規(guī)檢查：ChatGPT 可以用于自動(dòng)化

的安全審計(jì)和合規(guī)檢查，幫助企業(yè)及時(shí)發(fā)現(xiàn)潛在的安全

風(fēng)險(xiǎn)。它可以分析企業(yè)的網(wǎng)絡(luò)結(jié)構(gòu)、系統(tǒng)配置、數(shù)據(jù)存

儲等方面，確保符合行業(yè)標(biāo)準(zhǔn)和法規(guī)要求。

9、隱私保護(hù)：隨著用戶對隱私保護(hù)的關(guān)注日益增

強(qiáng)，ChatGPT 可以為互聯(lián)網(wǎng)企業(yè)提供隱私保護(hù)方案。它

可以幫助企業(yè)識別數(shù)據(jù)處理中的隱私風(fēng)險(xiǎn)，并提出相應(yīng)

的保護(hù)措施，以確保用戶數(shù)據(jù)的安全。

10、惡意行為識別和預(yù)防：ChatGPT 可以通過分析

用戶行為、網(wǎng)絡(luò)流量等數(shù)據(jù)，實(shí)時(shí)識別并預(yù)防惡意行

為，如網(wǎng)絡(luò)欺詐、黑客攻擊等。這有助于提高網(wǎng)絡(luò)安全

水平，降低企業(yè)和用戶的潛在損失。

11、安全趨勢預(yù)測：借助大數(shù)據(jù)和機(jī)器學(xué)習(xí)技術(shù)，

ChatGPT 可以分析網(wǎng)絡(luò)安全領(lǐng)域的歷史數(shù)據(jù)，預(yù)測未來

的安全趨勢。這對于制定有效的安全戰(zhàn)略和應(yīng)對措施具

有重要意義。

12、跨領(lǐng)域合作：ChatGPT 可以作為一個(gè)橋梁，促進(jìn)

不同領(lǐng)域的安全研究人員進(jìn)行合作和交流。通過共享知

識和資源，各方可以共同應(yīng)對日益嚴(yán)峻的網(wǎng)絡(luò)安全挑戰(zhàn)。

13、開源項(xiàng)目支持：ChatGPT 可以參與到開源項(xiàng)目

中，協(xié)助開發(fā)者修復(fù)安全漏洞、優(yōu)化代碼結(jié)構(gòu)、提高軟

件質(zhì)量。這有助于提升整個(gè)開源社區(qū)的安全水平。

經(jīng)過對 ChatGPT 在互聯(lián)網(wǎng)安全研發(fā)領(lǐng)域的應(yīng)用價(jià)值

的探討，我們了解到了其廣泛的潛力。然而，我們也應(yīng)

當(dāng)警惕 AI 技術(shù)可能被惡意利用的風(fēng)險(xiǎn)。因此，在使用

ChatGPT 時(shí)，企業(yè)和研究人員應(yīng)確保遵循道德和法律規(guī)

定，以確保人工智能為互聯(lián)網(wǎng)安全作出積極貢獻(xiàn)。接下

來，我們將比較 ChatGPT 與其他常見的代碼分析工具和

方法的優(yōu)勢和劣勢。

二、ChatGPT 分析代碼的能力與對比

在對比 ChatGPT 與其他常見的代碼分析工具和方法

時(shí)，我們可以從以下幾個(gè)方面進(jìn)行分析。以下是靜態(tài)代

碼分析工具、動(dòng)態(tài)代碼分析工具和 ChatGPT 的各自優(yōu)劣

分析：

（一）靜態(tài)代碼分析

靜態(tài)代碼分析工具在不執(zhí)行代碼的情況下對源代

碼進(jìn)行分析，以識別潛在的安全漏洞、代碼質(zhì)量問題

和不符合編碼規(guī)范的地方。常見的靜態(tài)代碼分析工具有

SonarQube、FindBugs、Pylint 等。

1、優(yōu)勢：

（1）無需執(zhí)行代碼，減少了測試環(huán)境的搭建成本。

（2）可以集成到持續(xù)集成（CI）系統(tǒng)中，便于自動(dòng)

化檢查。

8

百家論道 LECTURE ROOM

（3）提供了詳細(xì)的報(bào)告，有助于開發(fā)者理解和修復(fù)

問題。

2、劣勢：

（1）可能會(huì)產(chǎn)生誤報(bào)和漏報(bào)，需要人工確認(rèn)。

（2）難以識別復(fù)雜的漏洞和邏輯錯(cuò)誤。

（二）動(dòng)態(tài)代碼分析

動(dòng)態(tài)代碼分析工具在代碼執(zhí)行時(shí)分析程序行為，以

檢測潛在的安全風(fēng)險(xiǎn)和性能問題。常見的動(dòng)態(tài)代碼分析

工具有 OWASP ZAP、Burp Suite、Fuzzing 工具等。

1、優(yōu)勢：

（1）能夠發(fā)現(xiàn)實(shí)際運(yùn)行中的問題，準(zhǔn)確性較高。

（2）可以識別一些靜態(tài)分析工具難以發(fā)現(xiàn)的問題。

2、劣勢：

（1）需要運(yùn)行代碼，可能會(huì)帶來較高的測試成本。

（2） 需要專業(yè)知識進(jìn)行有效的測試，操作難度較高。

（三）ChatGPT 優(yōu)勢

ChatGPT 作為一種基于人工智能的代碼分析方法，

可以通過自然語言處理技術(shù)分析代碼，并為開發(fā)者提供

安全建議。

1、優(yōu)勢：

（1）可以理解自然語言，更易于與開發(fā)者交流。

（2）能夠?qū)W習(xí)大量的編程知識，提供全面的分析。

（3） 可以自動(dòng)發(fā)現(xiàn)潛在的安全風(fēng)險(xiǎn)，并提供修復(fù)建議。

2、劣勢：

（1）對于一些特定領(lǐng)域的安全漏洞，可能不如專業(yè)

的安全工具準(zhǔn)確。

（2）可能受限于訓(xùn)練數(shù)據(jù)的質(zhì)量和數(shù)量，存在一定

的誤報(bào)和漏報(bào)風(fēng)險(xiǎn)。

（四）提升安全質(zhì)量

每種代碼分析方法都有其優(yōu)勢和劣勢，選擇合適的

工具取決于具體的項(xiàng)目需求和場景。靜態(tài)和動(dòng)態(tài)代碼分

析工具專注于代碼的安全性和質(zhì)量問題，適合用于專業(yè)

的安全審計(jì)和性能調(diào)優(yōu)。而 ChatGPT 作為一種基于 AI 的

代碼分析方法，可以提供更廣泛的支持，包括安全策略

制定、漏洞挖掘分析和安全培訓(xùn)等。它具有較強(qiáng)的自然

語言理解能力，與開發(fā)者交流更為便捷。然而，ChatGPT

可能在特定領(lǐng)域的安全漏洞識別方面不如專業(yè)的安全工

具準(zhǔn)確，并且受訓(xùn)練數(shù)據(jù)的質(zhì)量和數(shù)量限制，存在一定

的誤報(bào)和漏報(bào)風(fēng)險(xiǎn)。

為了充分發(fā)揮各種工具的優(yōu)勢，開發(fā)團(tuán)隊(duì)可以考慮

將 ChatGPT 與靜態(tài)和動(dòng)態(tài)代碼分析工具結(jié)合使用。這樣

可以確保項(xiàng)目在不同方面得到全面的檢查，從而更好地

提高代碼的安全性和質(zhì)量。

例如，團(tuán)隊(duì)可以首先使用靜態(tài)代碼分析工具對源代

碼進(jìn)行自動(dòng)化檢查，發(fā)現(xiàn)潛在的安全漏洞和編碼問題；

然后使用動(dòng)態(tài)代碼分析工具對程序在運(yùn)行時(shí)的行為進(jìn)行

檢測，以識別實(shí)際運(yùn)行中可能出現(xiàn)的問題。最后，可以

利用 ChatGPT 的自然語言理解能力和編程知識庫為開發(fā)

者提供安全建議、修復(fù)漏洞的指導(dǎo)以及其他與安全相關(guān)

的支持。

三、ChatGPT 安全漏洞識別

為了更具體地了解 ChatGPT 的性能，我們將分析幾

個(gè) Java 案例，了解其在識別安全漏洞方面的表現(xiàn)。

（一）SQL 注入識別

首先，我們將探討 ChatGPT 如何識別和處理 SQL 注

入漏洞。不安全的 Java 代碼示例：

1、ChatGPT 分析：

此代碼存在 SQL 注入風(fēng)險(xiǎn)，因?yàn)橹苯訉⒂脩糨斎氲?/p>

username 和 password 拼接到 SQL 查詢語句中。攻擊者

可以通過構(gòu)造惡意輸入來執(zhí)行任意 SQL 語句。

2、修復(fù)建議：

使用預(yù)編譯語句（PreparedStatement）來防止 SQL

注入攻擊：

（二）XSS 攻擊識別

接下來，我們將分析 ChatGPT 在識別跨站腳本 XSS

攻擊方面的表現(xiàn)。不安全的代碼示例：

9

LECTURE ROOM 百家論道

1、ChatGPT 分析：

此代碼存在跨站腳本攻擊（XSS）風(fēng)險(xiǎn)，因?yàn)橹苯?/p>

將用戶輸入的 username 和 comment 輸出到 HTML 頁面。

攻擊者可以通過提交包含惡意腳本的輸入來執(zhí)行任意

JavaScript 代碼。

2、修復(fù)建議：

使用輸出編碼來防止 XSS 攻擊：

（三）繞過權(quán)限識別

最后，我們將討論 ChatGPT 在識別權(quán)限繞過漏洞方

面的能力。不安全的代碼示例：

1、ChatGPT 分析：

此代碼存在權(quán)限繞過風(fēng)險(xiǎn)，因?yàn)閮H依賴于用戶會(huì)話中

的 role 屬性來檢查用戶是否具有管理員權(quán)限。攻擊者可

能通過偽造會(huì)話數(shù)據(jù)來繞過權(quán)限檢查，執(zhí)行管理員操作。

2、修復(fù)建議：

使用更安全的身份驗(yàn)證和授權(quán)機(jī)制，例如 Java

EE 的內(nèi)置身份驗(yàn)證和授權(quán)或使用第三方庫如 Spring

Security 來確保權(quán)限驗(yàn)證的安全性：

通過以上示例，我們可以看到 ChatGPT 在分析不同

類型的安全漏洞（如 SQL 注入、跨站腳本攻擊和權(quán)限繞

過）方面的表現(xiàn)。它能夠識別出存在的安全風(fēng)險(xiǎn)，并提

供修復(fù)建議。然而，需要注意的是，ChatGPT 可能受限

于訓(xùn)練數(shù)據(jù)的質(zhì)量和數(shù)量，因此在實(shí)際應(yīng)用中，開發(fā)者

應(yīng)結(jié)合專業(yè)的安全工具和人工審查來確保代碼的安全性。

四、融合安全策略與實(shí)踐

在此部分，我們將探討如何將 ChatGPT 與其他安全

策略和實(shí)踐相結(jié)合，提高整體安全性。以下是一些建議，

以說明如何將 ChatGPT 與安全開發(fā)生命周期（SDL）、安

全編碼準(zhǔn)則和敏捷開發(fā)相結(jié)合。

（一）安全開發(fā)生命周期（SDL）

安全開發(fā)生命周期是一個(gè)將安全性納入整個(gè)軟件開

發(fā)過程的框架，包括需求分析、設(shè)計(jì)、實(shí)現(xiàn)、測試和維

護(hù)等階段。ChatGPT 可以在以下方面與 SDL 相結(jié)合：

1、需求分析：在確定項(xiàng)目需求時(shí)，ChatGPT 可以協(xié)

助開發(fā)者識別潛在的安全需求和風(fēng)險(xiǎn)，并提出相應(yīng)的安

全措施。

2、設(shè)計(jì)：在設(shè)計(jì)階段，ChatGPT 可以評估架構(gòu)和設(shè)

計(jì)文檔，指出可能存在的安全缺陷并提供改進(jìn)建議。

3、實(shí)現(xiàn)：ChatGPT 可以在代碼編寫過程中自動(dòng)發(fā)現(xiàn)

潛在的安全漏洞，并為開發(fā)者提供修復(fù)建議。

4、測試：ChatGPT 可以輔助生成安全測試用例，確

保軟件在各種攻擊場景下的安全性。

5、維護(hù)：在軟件維護(hù)階段，ChatGPT 可以持續(xù)監(jiān)測

新的安全威脅，并幫助開發(fā)者更新安全策略。

（二）安全編碼準(zhǔn)則

安全編碼準(zhǔn)則是一套編寫安全代碼的規(guī)范和最佳實(shí)

踐。將 ChatGPT 與安全編碼準(zhǔn)則相結(jié)合可以幫助開發(fā)者

在編碼過程中遵循安全性原則。例如：

1、ChatGPT 可以自動(dòng)檢查代碼是否符合安全編碼準(zhǔn)

則，如輸入驗(yàn)證、輸出編碼和錯(cuò)誤處理等方面的規(guī)范。

2、 ChatGPT 可以作為一個(gè)實(shí)時(shí)的安全編碼指導(dǎo)工

具，提供安全編碼示例和解釋，幫助開發(fā)者養(yǎng)成良好的

編碼習(xí)慣。

（三）敏捷安全開發(fā)

敏捷開發(fā)是一種迭代和增量的軟件開發(fā)方法，強(qiáng)調(diào)

團(tuán)隊(duì)協(xié)作、客戶反饋和適應(yīng)性。將 ChatGPT 與敏捷開發(fā)

相結(jié)合可以實(shí)現(xiàn)安全性與敏捷性的平衡。例如：

1、在敏捷開發(fā)過程中，ChatGPT 可以作為一個(gè)安全

顧問，為團(tuán)隊(duì)提供實(shí)時(shí)的安全建議和風(fēng)險(xiǎn)評估。

2、ChatGPT 可以幫助團(tuán)隊(duì)優(yōu)先處理安全需求和漏洞

修復(fù)，確保在敏捷迭代過程中安全性得到充分關(guān)注。

3、在敏捷團(tuán)隊(duì)的代碼審查和知識分享環(huán)節(jié)中，

ChatGPT 可以提供安全相關(guān)的反饋，幫助團(tuán)隊(duì)成員更好

地理解和遵循安全編碼準(zhǔn)則。

4、ChatGPT 可以作為敏捷團(tuán)隊(duì)的安全培訓(xùn)工具，通

過與開發(fā)者的自然語言交互，提高團(tuán)隊(duì)成員在安全領(lǐng)域

的認(rèn)識和技能。

10

百家論道 LECTURE ROOM

ChatGPT 與安全開發(fā)生命周期（SDL）、安全編碼準(zhǔn)

則和敏捷開發(fā)相結(jié)合，可以在整個(gè)軟件開發(fā)過程中實(shí)現(xiàn)

更全面、持續(xù)和自動(dòng)化的安全保障。通過 ChatGPT 的自

然語言理解能力和編程知識庫，開發(fā)團(tuán)隊(duì)可以在各個(gè)開

發(fā)階段獲得實(shí)時(shí)的安全建議，提高軟件的安全性和質(zhì)

量。然而，需要注意的是，ChatGPT 并不能替代專業(yè)的

安全工具和人工審查，開發(fā)者應(yīng)結(jié)合多種安全策略和實(shí)

踐來確保軟件的安全性。

五、應(yīng)對 ChatGPT 局限性

雖然 ChatGPT 具有顯著的優(yōu)勢，但它也存在一定的

局限性。在本部分，我們將探討如何克服這些局限性，

以更好地應(yīng)對新興的技術(shù)和安全威脅。ChatGPT 在安全領(lǐng)

域的應(yīng)用具有局限性，需要充分認(rèn)識并采取相應(yīng)措施克

服這些限制。以下是一些主要的局限性及相應(yīng)的解決方法：

1、訓(xùn)練數(shù)據(jù)限制：ChatGPT 的知識和能力受訓(xùn)練數(shù)

據(jù)的質(zhì)量和數(shù)量限制。這意味著它可能無法識別一些新

興的技術(shù)和安全威脅。

解決方法：定期更新和擴(kuò)充 ChatGPT 的訓(xùn)練數(shù)據(jù)，

包括最新的安全漏洞、攻擊手法和修復(fù)策略。這可以通

過與安全社區(qū)合作、收集安全報(bào)告和研究等途徑實(shí)現(xiàn)。

2、缺乏專業(yè)領(lǐng)域深度：雖然 ChatGPT 具有較強(qiáng)的自

然語言理解能力和編程知識庫，但在特定領(lǐng)域的安全漏

洞識別方面可能不如專業(yè)的安全工具準(zhǔn)確。

解決方法：將 ChatGPT 與專業(yè)的安全工具（如靜態(tài)

代碼分析、動(dòng)態(tài)代碼分析和漏洞掃描工具）結(jié)合使用，

確保項(xiàng)目在不同方面得到全面的檢查。

3、誤報(bào)和漏報(bào)風(fēng)險(xiǎn)：由于訓(xùn)練數(shù)據(jù)和模型本身的局

限，ChatGPT 可能存在誤報(bào)和漏報(bào)的風(fēng)險(xiǎn)，可能會(huì)誤導(dǎo)

開發(fā)者。

解決方法：在使用 ChatGPT 的輸出時(shí)，開發(fā)者應(yīng)保持

謹(jǐn)慎，并結(jié)合人工審查和其他安全策略進(jìn)行驗(yàn)證。此外，

通過持續(xù)改進(jìn)模型和算法，可以降低誤報(bào)和漏報(bào)的風(fēng)險(xiǎn)。

4、泛化能力限制：ChatGPT 可能在特定的場景和

上下文中表現(xiàn)不佳，因?yàn)樗枰鶕?jù)給定的輸入進(jìn)行推

理，而不是依賴于具體的背景知識。

解決方法：優(yōu)化模型訓(xùn)練，使其更具泛化能力。通

過引入領(lǐng)域?qū)＜业闹R、特定場景的訓(xùn)練數(shù)據(jù)和具有更

強(qiáng)上下文敏感性的算法，提高模型的泛化性能。

5、可解釋性和透明度：ChatGPT作為一個(gè)黑盒模型，

其決策過程和推理邏輯可能難以理解和解釋。

解決方法：研究可解釋性和透明度方法，例如通過

注意力機(jī)制、局部可解釋性模型（LIME）等技術(shù)，提供

關(guān)于模型輸出的更多信息和解釋。

克服這些限制需要開發(fā)者、研究人員和安全專家共

同努力。通過定期更新訓(xùn)練數(shù)據(jù)、結(jié)合專業(yè)安全工具、

人工審查、優(yōu)化模型泛化能力和提高可解釋性，我們可

以使ChatGPT在應(yīng)對新興技術(shù)和安全威脅方面更加有效。

同時(shí)，通過與安全社區(qū)的緊密合作，確保最新的安全知

識和實(shí)踐得到分享和傳播。

六、ChatGPT 實(shí)踐案例分析

在這一部分，我們將通過案例，展示實(shí)際企業(yè)如何

成功地將 ChatGPT 應(yīng)用于網(wǎng)絡(luò)軟件安全領(lǐng)域，以及他們

在實(shí)踐中遇到的挑戰(zhàn)和經(jīng)驗(yàn)教訓(xùn)。

（一）案例背景

某創(chuàng)新型互聯(lián)網(wǎng)公司（以下簡稱為“公司 A”）開發(fā)

了一款在線教育平臺。公司 A 決定將 ChatGPT 應(yīng)用于其

軟件開發(fā)流程，以提高產(chǎn)品的安全性。

（二）應(yīng)用過程

1、需求分析與設(shè)計(jì)：公司 A 在項(xiàng)目初期就引入了

ChatGPT，協(xié)助團(tuán)隊(duì)分析安全需求并在系統(tǒng)設(shè)計(jì)階段提出

相應(yīng)的安全措施。

2、代碼實(shí)現(xiàn)：在編碼過程中，公司 A 的開發(fā)人員使

11

LECTURE ROOM 百家論道

用 ChatGPT 自動(dòng)識別潛在的安全漏洞，并根據(jù)其提供的

修復(fù)建議進(jìn)行修改。

3、代碼審查與測試：公司 A 在代碼審查階段將

ChatGPT 作為一個(gè)輔助工具，以發(fā)現(xiàn)可能被人眼遺漏的

安全問題。在測試階段，ChatGPT 協(xié)助生成安全測試用

例，確保產(chǎn)品在各種攻擊場景下的安全性。

（三）挑戰(zhàn)和經(jīng)驗(yàn)教訓(xùn)

1、誤報(bào)與漏報(bào)：公司 A 在實(shí)踐中發(fā)現(xiàn)，ChatGPT 有

時(shí)會(huì)產(chǎn)生誤報(bào)或漏報(bào)。為了解決這個(gè)問題，公司 A 結(jié)合

專業(yè)的安全工具和人工審查來確保代碼的安全性。

2、局限性：由于 ChatGPT 的訓(xùn)練數(shù)據(jù)和領(lǐng)域?qū)I(yè)知

識的局限，公司 A 發(fā)現(xiàn)它在某些特定場景的安全分析中

表現(xiàn)不佳。因此，公司 A 加強(qiáng)了與安全社區(qū)的合作，持

續(xù)更新訓(xùn)練數(shù)據(jù)，并引入領(lǐng)域?qū)＜业闹R。

3、審查過程的優(yōu)化：公司 A 在使用 ChatGPT 的過程

中，改進(jìn)了代碼審查流程，使其更加結(jié)構(gòu)化和高效。例

如，開發(fā)人員可以通過 ChatGPT 獲取實(shí)時(shí)的安全建議，

而不是等待定期的代碼審查。

4、持續(xù)改進(jìn)：公司 A 認(rèn)識到將 ChatGPT 引入軟件開

發(fā)過程并非一勞永逸。為了保持其在安全領(lǐng)域的有效性，

公司 A 定期對 ChatGPT 進(jìn)行更新和優(yōu)化。

通過這個(gè)案例，我們可以看到，雖然 ChatGPT 在

實(shí)際應(yīng)用中存在一定的挑戰(zhàn)，但通過結(jié)合專業(yè)安全工

具、人工審查和持續(xù)改進(jìn)等策略，企業(yè)可以充分利用

ChatGPT 在網(wǎng)絡(luò)軟件安全領(lǐng)域的潛力。以下是一些關(guān)鍵

的經(jīng)驗(yàn)教訓(xùn)：

（1）多層次防護(hù)：將 ChatGPT 與其他安全工具和實(shí)

踐相結(jié)合，形成多層次的防護(hù)體系，以確保軟件在各個(gè)

開發(fā)階段都得到全面的安全檢查。

（2）人工與自動(dòng)化相結(jié)合：雖然 ChatGPT 可以自動(dòng)

識別潛在的安全漏洞并提供建議，但人工審查仍然是必

要的。結(jié)合人工審查和自動(dòng)化工具可以在提高效率的同

時(shí)，確保軟件的安全性。

（3）長期投入：將 ChatGPT 納入軟件開發(fā)過程需要

長期的投入和維護(hù)。定期更新模型、訓(xùn)練數(shù)據(jù)和算法是

確保其持續(xù)有效性的關(guān)鍵。

（4）安全文化推廣：成功地將 ChatGPT 應(yīng)用于網(wǎng)絡(luò)

軟件安全領(lǐng)域，需要在整個(gè)團(tuán)隊(duì)中推廣安全文化。通過

培訓(xùn)、分享會(huì)和內(nèi)部交流等方式，提高團(tuán)隊(duì)成員對安全

問題的認(rèn)識和技能。

（5）定期評估和反饋：對 ChatGPT 在實(shí)際應(yīng)用中的

表現(xiàn)進(jìn)行定期評估和反饋，以便發(fā)現(xiàn)潛在問題并及時(shí)進(jìn)

行改進(jìn)。與安全社區(qū)保持緊密合作，共享最新的安全知

識和實(shí)踐。

通過將 ChatGPT 應(yīng)用于網(wǎng)絡(luò)軟件安全領(lǐng)域，我們

可以更有效地識別和解決潛在的安全問題，提高軟件質(zhì)

量，保障用戶數(shù)據(jù)安全。在未來，隨著人工智能技術(shù)的

不斷進(jìn)步，ChatGPT 在代碼分析和軟件安全方面的應(yīng)用將

更加廣泛，為網(wǎng)絡(luò)軟件安全領(lǐng)域帶來更多的價(jià)值和創(chuàng)新。

在未來我們能做的事情還有很多，包括：

1、開發(fā)領(lǐng)域?qū)Ｓ玫?ChatGPT 模型：針對特定行業(yè)或

安全領(lǐng)域，開發(fā)定制化的 ChatGPT 模型，以提供更加精

確和深入的安全建議。

2、采用多模態(tài)學(xué)習(xí)：結(jié)合多種數(shù)據(jù)源（如代碼、文

本和圖像等）進(jìn)行訓(xùn)練，以提高 ChatGPT 在安全分析和

推理方面的能力。

3、實(shí)時(shí)安全監(jiān)控和響應(yīng)：研究將 ChatGPT 與實(shí)時(shí)安

全監(jiān)控和響應(yīng)系統(tǒng)相結(jié)合的方法，以便在面臨安全威脅

時(shí)快速作出反應(yīng)并提供相應(yīng)的解決方案。

4、模型安全性：確保 ChatGPT 模型本身的安全性，

防止?jié)撛诘膶构艉蛿?shù)據(jù)泄露等風(fēng)險(xiǎn)。

ChatGPT 將在確保軟件安全方面發(fā)揮更加重要的作

用，為開發(fā)者應(yīng)對不斷變化的技術(shù)和安全威脅提供支

持。新時(shí)代的革命已經(jīng)到來，我們應(yīng)積極擁抱這一變革，

以實(shí)現(xiàn)更低成本、更高質(zhì)量和更高安全性的發(fā)展目標(biāo)。

12

百家論道 LECTURE ROOM

淺談 ChatGPT 和網(wǎng)絡(luò)安全行

業(yè)的愛恨情仇

腦動(dòng)極光首席信息安全

官、OWASP 中 國 北 京 區(qū) 域 負(fù) 責(zé)

人、西班牙 UAB 大學(xué)碩士、北京

某高校網(wǎng)絡(luò)空間安全學(xué)院研究生

導(dǎo)師、網(wǎng)絡(luò)安全研究生實(shí)習(xí)基地

導(dǎo)師、中國衛(wèi)生信息與健康醫(yī)療

大數(shù)據(jù)學(xué)會(huì)首屆委員、網(wǎng)安加

社區(qū)特聘專家，參與編寫 GB/T

39725 健康醫(yī)療行業(yè)數(shù)據(jù)安全指

南、3 個(gè)健康醫(yī)療行業(yè)標(biāo)準(zhǔn)，榮

獲國家三級榮譽(yù)證書（技術(shù)貢獻(xiàn)

類）。網(wǎng)絡(luò)安全行業(yè)從業(yè)十余年，

曾于金融集團(tuán)、上市企業(yè)及互聯(lián)

網(wǎng)企業(yè)、Top 國企擔(dān)任安全負(fù)責(zé)

人角色，負(fù)責(zé)基礎(chǔ)安全、法務(wù)合

規(guī)、隱私合規(guī)、安全研發(fā)、風(fēng)控

及業(yè)務(wù)安全、SRC（安全應(yīng)急響

應(yīng)中心）、數(shù)據(jù)安全、內(nèi)審內(nèi)控

等工作。

OpenAI 在 2022 年 11 月推出了影響全球各行業(yè)的、革命性的人工智能語言

模型 ChatGPT。ChatGPT 與其他 AI 的區(qū)別在于 ChatGPT 忽略搜索引擎，通過從

機(jī)器學(xué)習(xí)數(shù)據(jù)中提取相關(guān)信息來形成原始響應(yīng)。

我的畢業(yè)論文是《Research on the development and application of

artificial intelligence》，幸好那時(shí)候還沒有 GPT，這種變革的進(jìn)步還未出

現(xiàn)，不然論文幾乎要重新開題，當(dāng)然正是這種變革，引起了億級用戶的好奇和

注意，也讓無數(shù)的科技用戶被其能力所震撼。但對安全從業(yè)者而言，不得不考

慮 ChatGPT 對惡意行為的促進(jìn)，畢竟 ChatGPT 為黑客開辟了新的途徑，所以，

對行業(yè)而言，隨著人工智能日益增長的影響并采取相應(yīng)行動(dòng)至關(guān)重要。

在 ChatGPT 發(fā)展之初安全問題一直被選擇性忽視，但在今年 3 月 23 日，

OpenAI 的 CEO（Sam Altman）公開承認(rèn)開源庫出現(xiàn)錯(cuò)誤，導(dǎo)致聊天記錄被泄露，

隨后韓國媒體報(bào)道三星在引入聊天機(jī)器人 ChatGPT 不到 20 天，便曝出機(jī)密資料

外泄等三起涉及 ChatGPT 誤用與濫用案例，相關(guān)資料內(nèi)容已被 ChatGPT 學(xué)習(xí)（代

表會(huì)被用于回答使用者的問題）：

1、A 職員，把有問題的源代碼輸入 ChatGPT，并詢問了解決方法；

2、B 職員，把源代碼輸入到 ChatGPT，并尋求優(yōu)化方法；

3、C 職員，將手機(jī)錄制的會(huì)議內(nèi)容轉(zhuǎn)換為文件后輸入到 ChatGPT，制作會(huì)

議記錄。

3 月 31 日，意大利禁止了 ChatGPT，意大利數(shù)據(jù)保護(hù)局（IDPA）在調(diào)查違

反歐洲隱私法規(guī)的情況時(shí)命令從即日起禁止使用聊天機(jī)器人 ChatGPT，并不允許

OpenAI 處理意大利用戶信息。IDPA 動(dòng)作起因是 3 月 20 日 ChatGPT 平臺出現(xiàn)了

用戶對話數(shù)據(jù)和付款服務(wù)支付信息丟失情況，平臺未應(yīng)盡義務(wù)提醒、告知，并

缺乏大量收集和存儲個(gè)人信息的法律依據(jù)，也說明了數(shù)據(jù)安全風(fēng)險(xiǎn)已經(jīng)引起有

些國家的警惕，隨后法國、愛爾蘭和德國的監(jiān)管機(jī)構(gòu)也在調(diào)查 ChatGPT 是否違

反了 GDPR 法律，美國 NIST 也頗有遠(yuǎn)見的提前發(fā)布了《人工智能風(fēng)險(xiǎn)管理框架》

（英國、德國等也在路上，我國更是一力降十會(huì)）。

一、ChatGPT 的價(jià)值

ChatGPT 是一個(gè)基于 OpenAI GPT 模型的聊天機(jī)器人，它可以進(jìn)行自然語言

對話，是大型語言模型，它可以進(jìn)行自然語言預(yù)測，在許多方面都表現(xiàn)出色：

1、自然語言處理、文本生成、語言理解、對話系統(tǒng)、知識圖譜、推薦系統(tǒng)等。

張 坤

13

LECTURE ROOM 百家論道

2、文本生成任務(wù)，如生成文章、段落、句子等，也

可以進(jìn)行文本分類、情感分析、實(shí)體識別等。

3、機(jī)器翻譯、語音識別、自然語言理解等問題，并

且可以與其他技術(shù)結(jié)合使用，例如深度學(xué)習(xí)、神經(jīng)網(wǎng)絡(luò)等。

ChatGPT 最大的價(jià)值在統(tǒng)計(jì)，如：

1、為 AI 提供了一種穩(wěn)定、可靠、安全的方式進(jìn)行

通信的方式，可以支持大規(guī)模語言模型的訓(xùn)練和部署，

為自然語言處理領(lǐng)域提供了強(qiáng)有力的支持。

2、ChatGPT 還可以用于智能客服、智能助手、智能

寫作等方面的應(yīng)用，幫助企業(yè)提高效率和用戶體驗(yàn)。

3、提供自然語言交互的服務(wù)，幫助用戶解決問題、

獲取信息、進(jìn)行對話等。

4、 ChatGPT 還可以為用戶提供個(gè)性化的問候、娛

樂、社交等服務(wù)，從而提升用戶的生活質(zhì)量。

ChatGPT 最大的價(jià)值在于提供了一個(gè)可靠的、可擴(kuò)

展的、高性能的分布式訓(xùn)練平臺，使得人工智能助手的

訓(xùn)練和優(yōu)化變得更加容易和高效。通過使用 ChatGPT，

可以方便地訓(xùn)練各種語言模型、問答模型、推薦模型

等，提高人工智能助手的性能和質(zhì)量，為用戶提供更好

的服務(wù)。

二、ChatGPT 的風(fēng)險(xiǎn)

如開頭所言，ChatGPT 的差異源于響應(yīng)的模式，許

多網(wǎng)絡(luò)安全人員也更關(guān)注這種細(xì)微差別對網(wǎng)絡(luò)安全的影

響，ChatGPT 來幫助識別網(wǎng)絡(luò)威脅，但黑客也可以利用

其實(shí)現(xiàn)惡意目的。各種開源的版本已經(jīng)有了多年的歷史，

但毫無疑問 ChatGPT 是迄今為止最先進(jìn)的存在。特別是

ChatGPT 帶給用戶的真實(shí)人的感受，而從黑客的角度來

看，ChatGPT 是一個(gè)游戲規(guī)則的改變者。

例如：網(wǎng)絡(luò)釣魚是最常見但不可怕的 IT 威脅，大多

數(shù)網(wǎng)絡(luò)釣魚騙局都很容易辨認(rèn)，包括拼寫錯(cuò)誤、語法錯(cuò)

誤、標(biāo)準(zhǔn)模板、亂七八糟的措辭、翻譯導(dǎo)致的語意偏差

等，但 ChatGPT 提供的無偏差交互可以有效地加強(qiáng)網(wǎng)絡(luò)

釣魚活動(dòng)的成功率，而且，ChatGPT 的編碼能力、龐大

的數(shù)據(jù)集、無限的算力、成熟的模型，為其在任何場景

下的作用提供了無限的潛力。

技術(shù)不分黑白，但使用群體和使用目的有差異，

ChatGPT 也不例外，它可以幫助惡意攻擊者自動(dòng)化、加

速和優(yōu)化現(xiàn)有的能力：

1、ChatGPT 的濫用：雖然 ChatGPT 通過內(nèi)容過濾器

來避免濫用，但可以通過其 Web GUI 或編程 API 繞過內(nèi)

容過濾器以獲得惡意代碼（例如獲取源代碼以創(chuàng)建多態(tài)

惡意軟件，這更難被反惡意軟件發(fā)現(xiàn)）。另外還可以用于

查找并利用最新的漏洞。

2、ChatGPT 自動(dòng)化應(yīng)用：ChatGPT 可以無視相關(guān)隱

私策略和倫理?xiàng)l款為代碼或電子郵件編寫腳本，黑客可

以要求 ChatGPT 編寫網(wǎng)絡(luò)釣魚電子郵件，也可以用公眾

人物的角度編寫電子郵件，并包含指向惡意頁面的特定

鏈接，甚至還可以通過自動(dòng)文本生成來執(zhí)行勒索軟件攻

擊以討論談判。

ChatGPT 不需要人工干預(yù)來生成其響應(yīng)，可以為惡

意攻擊行為降低攻擊成本和人工干預(yù)，如果使用傳統(tǒng)

方式進(jìn)行網(wǎng)絡(luò)釣魚攻擊或更有針對性的魚叉式網(wǎng)絡(luò)釣

魚，需要更多的投入和人工干預(yù)，而且成功率更低，

但 ChatGPT 的自動(dòng)化能力、語言能力、自動(dòng)編碼能力和

場景建設(shè)能力將更容易創(chuàng)建大規(guī)模、更復(fù)雜且非?？尚?/p>

的網(wǎng)絡(luò)釣魚活動(dòng)。另外據(jù)相關(guān)情報(bào)，已經(jīng)有黑客團(tuán)隊(duì)把

ChatGPT 用于基于文本的電子郵件模擬的魚叉式網(wǎng)絡(luò)釣

魚活動(dòng)之外的活動(dòng)，例如：大規(guī)模的“Deep Fake”活動(dòng)。

ChatGPT被用于聊天機(jī)器人展示、生成音頻和視頻輸出，

可以被用于欺詐、誤導(dǎo)、冒充、誹謗、品牌攻擊等。

3、大范圍錯(cuò)誤信息發(fā)布：盡管 ChatGPT 本身很智

能，但在某些情況下，它們可能會(huì)產(chǎn)生錯(cuò)誤信息，導(dǎo)

致用戶受到誤導(dǎo)，而且如果機(jī)器人沒有足夠的知識庫

建立，其回答將不準(zhǔn)確。ChatGPT 通過惡意引導(dǎo)或修改

ChatGPT 使用的內(nèi)容以影響它學(xué)習(xí)上下文的方式，可以

讓大規(guī)模的錯(cuò)誤信息發(fā)布成為可能，這可能會(huì)導(dǎo)致社交

媒體的大風(fēng)暴。

4、ChaGPT 未來會(huì)嵌入到更多的技術(shù)、產(chǎn)品中，從

供應(yīng)鏈風(fēng)險(xiǎn)來看，可能帶來全局的災(zāi)難性影響，無論是

偶然錯(cuò)誤還是惡意利用。對于依賴 ChatGPT的組織來說，

如果遭受攻擊，則可能會(huì)導(dǎo)致整個(gè)系統(tǒng)被破壞。ChatGPT

也有可能成為黑客入侵的目標(biāo)。如果黑客成功地進(jìn)入，

則它們將獲取訪問所有相關(guān)數(shù)據(jù)的權(quán)限，并有可能利用

其進(jìn)行其他形式的攻擊。

5、 信 息 泄 漏： 敏 感、 涉 密 的 信 息 如 果 被 輸 入

ChatGPT，之后就會(huì)成為聊天機(jī)器人數(shù)據(jù)模型的一部分，

并可以與其他人共享，從而導(dǎo)致數(shù)據(jù)泄露。對企業(yè)而言，

任何未經(jīng)授權(quán)向 ChatGPT 披露機(jī)密信息都可能違反所在

企業(yè)的保密要求。

6、版權(quán)問題：簡單來說就是通過 ChatGPT 生成的代

碼、圖片、音視頻、文本等所有權(quán)的問題，例如 ChatGPT

在開源庫上接受訓(xùn)練并在回答問題時(shí)“重放”該代碼，

14

百家論道 LECTURE ROOM

然后開發(fā)人員將該代碼放入公司發(fā)布的產(chǎn)品中，這可能

會(huì)使公司違反開源軟件（OSS）許可證。雖然，服務(wù)條款

表明 ChatGPT 不能用于任何其他 AI 的開發(fā)。

7、隱私和安全問題：雖然 ChatGPT 提示用戶不要輸

入敏感信息或個(gè)人信息，例如姓名或電子郵件地址。但

是未知的風(fēng)險(xiǎn)仍然存在，例如是否遵守所在國家、地區(qū)

隱私法、是否采取了適當(dāng)?shù)目刂拼胧﹣肀Ｗo(hù)個(gè)人數(shù)據(jù)、

如何保障用戶的數(shù)據(jù)權(quán)益以及其他會(huì)導(dǎo)致濫用和聲譽(yù)損

害的風(fēng)險(xiǎn)。

三、ChatGPT 對網(wǎng)絡(luò)安全的正向促進(jìn)

如果黑客比從業(yè)者更懂得利用 ChatGPT，可見的網(wǎng)

絡(luò)攻擊比歷史上任何時(shí)候都要多，ChatGPT 帶來的便利

性可能會(huì)讓黑客的攻擊行為增加，也可以減少黑客的工

作量，讓他們在更短的時(shí)間內(nèi)造成更大的破壞。它的通

信能力還可以提高僵尸網(wǎng)絡(luò)的連通性。

從趨勢來看，ChatGPT 就像幾十年前的計(jì)算機(jī)和互

聯(lián)網(wǎng)，全球人民的好奇心讓 ChatGPT 變得越來越流行，

一些公司也已經(jīng)建立了相對應(yīng)的產(chǎn)品能力，無可厚非它

提供了競爭優(yōu)勢，而在網(wǎng)絡(luò)安全行業(yè)，我們面對使用

ChatGPT 的惡意使用者，可以做得更多，更好地去發(fā)掘

ChatGPT 的未來及其在網(wǎng)絡(luò)安全中的作用，無論是積極

的還是消極的：

1、師夷長技以制夷：讓 ChatGPT 成為防御武器庫的

一部分。攻擊者的邪惡用途成為我們的演練腳本，經(jīng)過

訓(xùn)練成為我們的防護(hù)能力，可以使用 ChatGPT 發(fā)現(xiàn)并修

復(fù)軟件中的漏洞。攻擊者生成攻擊腳本，我們可以利用

ChatGPT 生成自動(dòng)化的安全測試腳本，協(xié)助進(jìn)行安全測

試和漏洞掃描。這些自動(dòng)化測試腳本可以更快速、更準(zhǔn)

確地測試網(wǎng)絡(luò)和系統(tǒng)，發(fā)現(xiàn)潛在的安全漏洞，從而提高

網(wǎng)絡(luò)安全水平。

2、威脅情報(bào)：ChatGPT 可以快速準(zhǔn)確地分析大量威

脅情報(bào)并提取有用的信息，可以幫助安全工作人員防止

潛在的網(wǎng)絡(luò)攻擊和識別新的威脅。ChatGPT 也可以更好

地協(xié)助分析和報(bào)告安全威脅，有助于我們更快地發(fā)現(xiàn)、

確認(rèn)威脅情報(bào)，更快地修復(fù)這些威脅。另外基于歷史數(shù)

據(jù)和機(jī)器學(xué)習(xí)算法，ChatGPT 可以預(yù)測潛在的網(wǎng)絡(luò)威脅。

它可以幫助我們預(yù)測和計(jì)劃未來的網(wǎng)絡(luò)攻擊。

3、安全研發(fā)：ChatGPT 技術(shù)在軟件開發(fā)領(lǐng)域的深

入，通過更安全的內(nèi)容（常見漏洞、編碼錯(cuò)誤、設(shè)計(jì)風(fēng)

險(xiǎn)等）進(jìn)行訓(xùn)練。有助于軟件開發(fā)人員復(fù)用安全代碼能

力，構(gòu)建漏洞更少、更安全穩(wěn)健的軟件。

4、安全測試：在網(wǎng)絡(luò)安全滲透測試、漏洞掃描、漏

洞賞金計(jì)劃、風(fēng)險(xiǎn)分析等方面，通過對 ChatGPT 部分或完

全自動(dòng)化的使用，可以彌補(bǔ)人員、技術(shù)、工具的差異化。

5、情報(bào)收集：一直以來 Google、Baidu 等都是攻

擊者和防護(hù)者的重要情報(bào)來源，通過對 AI 定向搜索的使

用，可以更精準(zhǔn)地獲取所需情報(bào)，例如域名信息、IP 信

息、端口信息、軟件供應(yīng)鏈構(gòu)成等。

6、惡意代碼分析：ChatGPT 可以識別和分類范圍廣

泛的惡意軟件，包括勒索軟件、木馬和病毒。經(jīng)過測試，

ChatGPT 已經(jīng)具有了快速理解和定位混淆的惡意軟件代

碼的能力。經(jīng)過深度訓(xùn)練和策略完善，有助于安全研究

人員對 APT 等深度惡意行為的分析和發(fā)現(xiàn)。

通過分析網(wǎng)絡(luò)流量、日志和其他數(shù)據(jù)源，ChatGPT

可以執(zhí)行主動(dòng)威脅搜尋的角色，也就是我們常說的態(tài)勢

感知。

7、網(wǎng)絡(luò)安全培訓(xùn)：可以通過訓(xùn)練 ChatGPT 構(gòu)建個(gè)性

化的網(wǎng)絡(luò)安全培訓(xùn)體系，通過與使用者交互，可以提醒

使用者注意網(wǎng)絡(luò)安全和隱私問題，教育他們?nèi)绾伪苊鈵?/p>

意軟件、釣魚網(wǎng)站、欺詐、垃圾信息識別等攻擊方式。

8、數(shù)據(jù)隱私：ChatGPT 可以檢查用戶協(xié)議和隱私政

策，以發(fā)現(xiàn)潛在風(fēng)險(xiǎn)和合規(guī)性問題。它可以幫助我們確

保遵守法規(guī)要求，保護(hù)客戶數(shù)據(jù)的安全性，降低人員成

本和合規(guī)風(fēng)險(xiǎn)。

9、應(yīng)急響應(yīng)：ChatGPT 可以通過提供實(shí)時(shí)信息和響

應(yīng)來幫助安全團(tuán)隊(duì)進(jìn)行事件響應(yīng)。它可以幫助組織快速

遏制和減少安全事件。

ChatGPT 可以用于識別和分類網(wǎng)絡(luò)安全威脅，幫助

網(wǎng)絡(luò)安全人員更好地了解和應(yīng)對不同類型的網(wǎng)絡(luò)攻擊。

可以更快速、準(zhǔn)確地檢測和識別潛在的入侵風(fēng)險(xiǎn)，制定

更加有效的安全策略?？偟膩碚f，ChatGPT 對網(wǎng)絡(luò)安全

行業(yè)具有很多正面的影響，但也存在一些負(fù)面影響。因

此，在使用 ChatGPT 時(shí)，需要謹(jǐn)慎處理，并確保其安全

性和合法性。至少目前風(fēng)險(xiǎn)大于收益。但相信，無論風(fēng)

險(xiǎn)還是收益，隨著 ChatGPT 等工具的發(fā)展，對網(wǎng)絡(luò)安全

的影響也越來越大，對某些企業(yè)、團(tuán)體或者機(jī)構(gòu)而言，

盡信書不如無書，應(yīng)該評估ChatGPT是否可以安全使用。

15

LECTURE ROOM 百家論道

開源安全治理解決方案分享

開源組件安全分析與合

規(guī)專家，系統(tǒng)架構(gòu)師、分析

師；擁有十余年的安全開發(fā)

經(jīng)驗(yàn)，對 SCA 相關(guān)產(chǎn)品和技

術(shù)實(shí)現(xiàn)原理均有深入研究，

現(xiàn) 任 開 源 網(wǎng) 安 SourceCheck

產(chǎn)品負(fù)責(zé)人。

汪 杰 一、開源背景

隨著社會(huì)數(shù)字化進(jìn)程的不斷推進(jìn)，開源技術(shù)被廣泛應(yīng)用于各個(gè)行業(yè)，推動(dòng)

產(chǎn)業(yè)的快速發(fā)展。毫無疑問，開源技術(shù)的應(yīng)用有諸多好處，企業(yè)可以免費(fèi)獲取

開源軟件，以更低成本加快項(xiàng)目進(jìn)度。而且開源軟件大多數(shù)由開源社區(qū)支持，

能一定程度上保證軟件質(zhì)量。同時(shí)，企業(yè)可以借助它快速占領(lǐng)市場，實(shí)現(xiàn)商業(yè)

目的。

技術(shù)是一把雙刃劍，不當(dāng)使用開源技術(shù)也會(huì)帶來大量風(fēng)險(xiǎn)。據(jù)統(tǒng)計(jì)，99%

的項(xiàng)目使用了開源軟件，其中有 77.5% 的項(xiàng)目存在開源軟件漏洞，每個(gè)項(xiàng)目平

均有 52.5 個(gè)漏洞。從許可合規(guī)的角度來看，65% 的代碼庫存在許可證沖突，85%

的代碼庫包含 4 年未更新的開源組件。

此外，近幾年開源應(yīng)用安全事件的頻發(fā)也造成重大影響。2020 年 12 月，

SolarWinds 遭遇國家級 APT 團(tuán)伙高度復(fù)雜的供應(yīng)鏈攻擊，超過 18000 家客戶

全部受到影響，可任由攻擊者完全操控；2021 年 11 月，代碼質(zhì)量管理平臺

SonarQube 被爆存在未授權(quán)訪問漏洞，國內(nèi)外數(shù)萬家企業(yè)的敏感數(shù)據(jù)泄露，重點(diǎn)

應(yīng)用代碼泄露；2021 年 11 月，廣泛應(yīng)用的開源組件 Log4j 被曝存在超危漏洞，

72 小時(shí)內(nèi)受到 84 萬次攻擊，國內(nèi)外知名企業(yè)均受到重大經(jīng)濟(jì)損失，相關(guān)網(wǎng)絡(luò)攻

擊至今仍在繼續(xù)。

針對開源技術(shù)的風(fēng)險(xiǎn)，業(yè)內(nèi)也越來越重視，相關(guān)的開源技術(shù)監(jiān)管工作已全

面鋪開。許多金融行業(yè)、通訊行業(yè)、科技制造業(yè)的企業(yè)已自發(fā)組成生態(tài)聯(lián)盟，

建立起相關(guān)開源治理的信息通道。中國信通院也在積極聯(lián)合安全廠商和標(biāo)桿企

業(yè)，共同發(fā)布開源治理白皮書、開源治理工具評估等一系列指導(dǎo)標(biāo)準(zhǔn)，以促進(jìn)

行業(yè)的可持續(xù)發(fā)展。

二、開源治理思考

（一）開源檢測技術(shù)思考

如何知道應(yīng)用中使用了哪些開源組件，可以從五個(gè)方面來考慮：

1、檢測技術(shù)多樣性：根據(jù)軟件形態(tài)可以將檢測技術(shù)分為源代碼檢測和二進(jìn)

制檢測兩種技術(shù)。其中源代碼檢測又可以細(xì)分兩類，一類是有包管理器管理的

軟件，能迅速能檢測到一些依賴關(guān)系；一類是無包管理器管理的檢測技術(shù)，如

C/C++ 語言，這類技術(shù)可以根據(jù)源碼目錄結(jié)構(gòu)、部分代碼特征指紋等來提取使用

16

百家論道 LECTURE ROOM

的開源組件信息，利用代碼片段指紋信息的提取與匹配

技術(shù)，能找出代碼中拷貝的第三方開源成分的代碼。

2、編程語言眾多：據(jù)不完全統(tǒng)計(jì)，全世界有 600 多

種編程語言，常用的語言大概有 20 多種，要想精準(zhǔn)檢測

每種語言，必須要有特定的檢測技術(shù)，針對每種語言的

包管理器的技術(shù)、語法、編譯原理等來提取代碼特征和

二進(jìn)制特征。

3、文件格式多：不同語言的自身特點(diǎn)，加上編譯環(huán)

境的差異，在不同應(yīng)用場景下就會(huì)有很多格式。如安裝

包格式、二進(jìn)制文件格式、移動(dòng)應(yīng)用格式等。

4、檢測場景多樣性：不同的機(jī)構(gòu)對開源的使用和檢

測場景不一樣，大致可以分為三類。第一類，一些第三

方檢測、評測等機(jī)構(gòu)一般都使用單個(gè)應(yīng)用包上傳檢測的

方式；第二類，有較完善的研發(fā)流程體系的企業(yè)，一般

傾向于自動(dòng)化，集成企業(yè)現(xiàn)有的平臺或者工具，比如像

源代碼管理工具、持續(xù)集成工具、缺陷管理工具等實(shí)現(xiàn)

研發(fā)過程的檢測；而第三類企業(yè)，不關(guān)注研發(fā)流程而更

加關(guān)注安全防護(hù)方面，更偏向于應(yīng)用運(yùn)行時(shí)的檢測等。

5、依賴傳遞復(fù)雜性：開源組件的依賴性是指在開發(fā)

過程中，一個(gè)開源組件需要依賴其他的開源組件才能夠

正常工作。這些依賴關(guān)系可能是直接依賴或間接依賴，

并形成一個(gè)依賴鏈。檢測依賴的技術(shù)，一種是通過包管

理器技術(shù)，可以實(shí)時(shí)檢測分析，更加精準(zhǔn)；針對無包

管理器管理的軟件可以編譯提前生成依賴關(guān)系數(shù)據(jù)并緩

存，這類也可以找出依賴關(guān)系，但同一份代碼在不同編

譯器、不同架構(gòu)下生成的依賴關(guān)系可能不同，所有針對

無包管理器的檢測，要想檢測的準(zhǔn)，不僅僅是需要軟件

包本身，還需要提供當(dāng)前軟件包所處的環(huán)境。

（二）開源應(yīng)用思考

對于開源應(yīng)用的思考，分為開源組件管控和開源組

件管理兩個(gè)方面。

1、開源組件管控，包括漏洞與許可風(fēng)險(xiǎn)管控、自研

組件管控、組件基線庫管控、引入和退出和其他管控措

施。漏洞與許可風(fēng)險(xiǎn)的管控，就是漏洞的發(fā)現(xiàn)、確認(rèn)、

修復(fù)計(jì)劃、發(fā)版計(jì)劃、預(yù)警計(jì)劃等等，簡而言之就是對

整個(gè)漏洞全生命周期的管控，許可也是如此，還包括

許可的兼容分析等。自研組件管控分為兩種，一種是全

功能型的自研組件，針對某個(gè)業(yè)務(wù)全自研開發(fā)；另一種

是中間件級的組件，即定制化修改的開源組件。做好這

兩類自研組件的管控，才能便于在后面的檢測過程中進(jìn)

行定位和篩選。組件基線庫管控，包含自研組件和開源

組件，在企業(yè)內(nèi)部必須要形成一個(gè)安全可信的基線版本

庫，不管是后面的引入或退出都是有必要的。其他管控

措施，如黑白名單、策略規(guī)則，來配合開源組件的管控。

2、開源組件管理，通過制定計(jì)劃、組織資源、分配

任務(wù)、協(xié)調(diào)溝通等方式來實(shí)現(xiàn)目標(biāo)，以便更加有效的使用

開源組件。這里主要分為組織管理和流程管理。組織管理，

通過設(shè)置相關(guān)的部門和機(jī)構(gòu)來統(tǒng)一協(xié)調(diào)管理，協(xié)調(diào)資源，

促進(jìn)溝通。流程管理，上面管控提到的所有需要制度和流

程的地方需要通過相關(guān)制度和流程管理，如組件的引入和

退出制度流程，黑白名單定期維護(hù)流程等等。

（三）開源安全的思考

開源組件的安全工作，包含漏洞修復(fù)、使用安全意

識、更新與維護(hù)、實(shí)施訪問控制和安全策略、審查和評

估開源組件、建立應(yīng)急響應(yīng)計(jì)劃等六個(gè)方面。

1、開源組件漏洞修復(fù)：當(dāng)發(fā)現(xiàn)一個(gè)漏洞時(shí)，要知道

它修復(fù)的必要性是什么，如果沒有修復(fù)經(jīng)驗(yàn)時(shí)應(yīng)該怎么

辦，這些問題都是需要考量的。

2、開源組件使用安全意識：安全意識并不僅僅是靠

制度流程或規(guī)范來創(chuàng)造的，它一定是在整個(gè)流程的使用

過程中，通過大量的培訓(xùn)和實(shí)踐去產(chǎn)生安全意識。有了

安全意識，所有的研發(fā)人員都會(huì)積極參與到整個(gè)研發(fā)的

開源安全治理工作中。

3、及時(shí)更新和維護(hù)組件：隨著時(shí)間的推移，組件

的風(fēng)險(xiǎn)和漏洞會(huì)越來越多，只有及時(shí)更新與維護(hù)這些組

件，才能實(shí)時(shí)應(yīng)對新的風(fēng)險(xiǎn)和漏洞。

4、實(shí)施訪問控制和安全策略：比如對開源組件的下

載、上傳和修改都要做一些限制，防止整個(gè)開源組件在

實(shí)施和使用過程中被不斷的篡改錯(cuò)誤，引發(fā)新的問題。

17

LECTURE ROOM 百家論道

5、審查和評估開源組件：在做組件引用時(shí)，要查看

開源組件的源代碼、所屬社區(qū)、風(fēng)險(xiǎn)報(bào)告等信息，來判

斷該組件是否適合企業(yè)引用。

6、建立應(yīng)急響應(yīng)計(jì)劃：在發(fā)生安全事件或漏洞利用

時(shí)，如 0day 漏洞、投毒組件，企業(yè)或組織應(yīng)該建立應(yīng)急

響應(yīng)計(jì)劃，以及時(shí)響應(yīng)并恢復(fù)正常運(yùn)營。這包括對組件

進(jìn)行漏洞修復(fù)和安全更新，并與組件開發(fā)者和社區(qū)保持

溝通。

三、開源治理解決方案

針對開源安全治理工作，總體能力方案主要從技

術(shù)、安全和管理制度三個(gè)方面來展開，如下圖所示：

( 一）管理制度

管理制度，包括組織架構(gòu)、流程制度和安全培訓(xùn)。

組織架構(gòu)，可以建立這樣一個(gè)架構(gòu)矩陣，最上層是

統(tǒng)一領(lǐng)導(dǎo)工作的開源治理辦公室，下面配備開源治理專

家組以及開源治理管理員，給整個(gè)開源治理工作提供建

議。再往下是安全部門和合規(guī)部門，對開源組件的漏洞

和許可風(fēng)險(xiǎn)進(jìn)行識別和規(guī)劃，主導(dǎo)開源治理安全工作，

最下層是產(chǎn)品研發(fā)部門，進(jìn)行實(shí)際的風(fēng)險(xiǎn)修復(fù)工作。

（二）安全

安全是最核心的部分，覆蓋整個(gè)軟件研發(fā)生命周期，

可以分為三個(gè)階段：源頭安全、過程安全和運(yùn)營安全。

1、源頭安全

源頭安全，也就是需求設(shè)計(jì)階段，在新項(xiàng)目啟動(dòng)時(shí)

要做兩件事。

一是建立開源軟件引入及選型評估模型。

整個(gè)模型可以從 4 個(gè)維度去考慮：第一是組件可

靠性，有些個(gè)人開發(fā)者因?yàn)榕d趣上傳之后不再維護(hù)，因

此需要從社區(qū)的活躍度與軟件活躍度來判斷組件是否可

靠。第二是安全漏洞，就是從漏洞利用難度和風(fēng)險(xiǎn)評估

的角度來考慮。第三是法律合規(guī)，包括許可合規(guī)、專利

使用要求、商標(biāo)及著作權(quán)。最后是技術(shù)應(yīng)用，就是性能

滿足度和業(yè)務(wù)滿足度。

同時(shí)，開源軟件的引入還需制定相關(guān)的引入和審批

流程。在引入開源軟件時(shí)，要經(jīng)過軟件成分分析、代碼

質(zhì)量分析、代碼安全分析和性能分析，只有開源軟件滿

足所有要求，才會(huì)將其納入到整個(gè)項(xiàng)目中。

二是做好組件管理，打造安全可信組件庫。

將可信的組件納入引入審批流程中，可加速開源組

件選型，配合組件的準(zhǔn)入流程和制度可以有效控制組件

的引入。通過掃描制品庫，得到企業(yè)或者組織內(nèi)所有的

制品信息，掃描的制品可以分為開源組件和自研組件，

自研組件通過自研率分析可以區(qū)分出完全自研組件和修

改的開源組件，這對后續(xù)的自研組件管理意義重大。當(dāng)

掃描完所有制品后，可以分為可修復(fù)和不可修復(fù)的組

件，可修復(fù)的組件在資產(chǎn)定位中找到對應(yīng)的項(xiàng)目進(jìn)行逐

步修復(fù)，修復(fù)完成后和無風(fēng)險(xiǎn)的組件共同納入可信組件

庫中。對于不可修復(fù)的組件進(jìn)行加白加黑或者其他操作

處理。同時(shí)需要對可信組件庫進(jìn)行實(shí)時(shí)監(jiān)控掃描，一旦

發(fā)現(xiàn)可信組件庫中的組件有風(fēng)險(xiǎn)，通過定位資產(chǎn)重新回

到之前的流程中進(jìn)行修復(fù)操作。

2、過程安全

過程安全可以細(xì)分為五種情況。

（1) 全生命周期安全，自動(dòng)化集成。在開發(fā)階段，

通過插件集成開發(fā)工具，幫助開發(fā)人員在編碼過程中實(shí)

時(shí)檢測發(fā)現(xiàn)漏洞；集成代碼倉庫可以對企業(yè)或組織內(nèi)所

有的代碼進(jìn)行批量掃描檢測，可以從管理視角全局審計(jì)

代碼使用的開源組件情況；通過集成 CI（持續(xù)集成）平

臺，可以有效對違反安全策略（由平臺設(shè)置的規(guī)則策略）

的構(gòu)建操作進(jìn)行阻塞操作，并將異常構(gòu)建發(fā)送到 SOC 中

心進(jìn)入提單流程。在發(fā)布前的安全測試環(huán)節(jié)，可以對物

料包進(jìn)行安全掃描，確定沒有問題就可以直接發(fā)布。

（2) 源碼安全，建立安全源碼倉庫。源碼安全有

四個(gè)階段：第一是代碼編寫階段，可以集成開發(fā)工具檢

測，遵循組件管理規(guī)范；第二是代碼提交階段，集成代

管理制度 安全

技術(shù)（工具）

組織架構(gòu)

流程制度

安全培訓(xùn)

需求設(shè)計(jì) 編寫代碼 代碼倉庫 構(gòu)建平臺 制品庫 生產(chǎn)環(huán)境

組件引入

安全制度

組件修改

安全制度

代碼提交

訪問控制制度

源頭安全 過程安全 運(yùn)營安全

管理能力 檢測能力 集成能力 知識庫能力

審核流程 組件管理

資產(chǎn)管理 風(fēng)險(xiǎn)策略規(guī)則

源碼掃描

二進(jìn)制掃描

插件集成

API集成

私服

防火墻 風(fēng)險(xiǎn)預(yù)警 漏洞修復(fù)

應(yīng)急響應(yīng)制度

漏洞修復(fù)制度

組件更新制度

根據(jù)策略規(guī)則

放行或者阻塞

建立可信

制品庫

明確治理目標(biāo)

開源治理辦公室

開源治理專家組 開源治理管理員

安全部門 合規(guī)部部門

產(chǎn)品研發(fā)部門（研發(fā)、測試）

制度保障

組織機(jī)制 管理制度 風(fēng)險(xiǎn)管理

選型 使用

運(yùn)維 退出

技術(shù)管理

制度與流程

培訓(xùn)制度

責(zé)任確定

18

百家論道 LECTURE ROOM

碼托管平臺檢測，集成策略規(guī)則，遵循代碼訪問控制；

第三是修改開源階段，進(jìn)行代碼同源檢測識別修改的開

源組件，以便在未來發(fā)生風(fēng)險(xiǎn)時(shí)可及時(shí)修復(fù)，同時(shí)要規(guī)

避許可合規(guī)和漏洞風(fēng)險(xiǎn)，遵循代碼修改控制策略；第四

是源碼倉庫，要進(jìn)行定時(shí)掃描和實(shí)時(shí)的風(fēng)險(xiǎn)預(yù)警。

（3) 制品安全，建立私服防火墻。前面在源頭安全

提到建立安全可信組件庫，建立后還需要對可信組件庫進(jìn)

行防護(hù)，要對外部和內(nèi)部進(jìn)入組件庫的流量進(jìn)行監(jiān)聽和審

計(jì)，發(fā)現(xiàn)違反策略規(guī)則的組件進(jìn)入時(shí)，要進(jìn)行阻斷；同時(shí)

也要對制品庫進(jìn)行實(shí)時(shí)掃描，一旦發(fā)現(xiàn)風(fēng)險(xiǎn)要及時(shí)預(yù)警。

（4) 管控安全，建立安全卡口。基于全生命周期安

全實(shí)施管控安全，在整個(gè)研發(fā)過程的關(guān)鍵節(jié)點(diǎn)，如代碼

倉庫、持續(xù)集成平臺、制品庫等，增加安全卡口，進(jìn)行

合規(guī)校驗(yàn)，如果不符合規(guī)則，則進(jìn)行預(yù)警。

（5) 安全預(yù)警，建立溝通渠道。當(dāng)應(yīng)用檢測到漏洞或

識別到未知風(fēng)險(xiǎn)時(shí)，可以通過郵件、短信等多種方式將檢

測結(jié)果通知給相關(guān)責(zé)任人，并且可以直接對接到第三方協(xié)

作平臺，如缺陷管理平臺等，方便多人協(xié)作處理漏洞。

3、運(yùn)營安全

運(yùn)營安全階段，有三項(xiàng)重要工作。

第一是建立應(yīng)急響應(yīng)制度，通過知識庫能力中風(fēng)險(xiǎn)

預(yù)警，可以在 24 小時(shí)內(nèi)同步新的威脅情報(bào)到 SOC 中心，

配合應(yīng)急響應(yīng)機(jī)制進(jìn)行響應(yīng)。

第二是建立漏洞修復(fù)制度，當(dāng)確認(rèn)漏洞有效以及有

對應(yīng)的解決方案時(shí)，要根據(jù)管理能力中的資產(chǎn)管理，盤

點(diǎn)出當(dāng)前影響的漏洞在哪些項(xiàng)目中存在，并根據(jù)項(xiàng)目的

屬性定好修復(fù)優(yōu)先級，統(tǒng)一進(jìn)行逐步修復(fù)或者加固。

第三是建立組件更新制度，對新出現(xiàn)漏洞的組件的

不同情況進(jìn)行區(qū)別處理，比如老舊組件，在社區(qū)沒有維

護(hù)的情況下可以進(jìn)行退出操作。對于要升級的組件，通

過知識庫中的組件兼容性分析和評估后，進(jìn)行有規(guī)劃的

升級和更新。

（圖一 開源組件安全及合規(guī)管理平臺（SourceCheck））

19

LECTURE ROOM 百家論道

（三）開源組件安全及合規(guī)管理平臺 SourceCheck

開源組件安全及合規(guī)管理平臺（SourceCheck）是開

源網(wǎng)安自主研發(fā)的軟件成分分析（SCA）產(chǎn)品，用于第三

方組件的安全分析與管控，包括企業(yè)組件使用管理、組

件使用合規(guī)審計(jì)、新漏洞感知預(yù)警、開源代碼知識產(chǎn)權(quán)

審計(jì)等，可實(shí)現(xiàn)對源碼與制品的精準(zhǔn)分析，是幫助企業(yè)

實(shí)現(xiàn)開源風(fēng)險(xiǎn)治理的最佳工具。( 本文圖一）

很多企業(yè)內(nèi)部不清楚使用了哪些組件、不清楚問

題如何修復(fù)、無法掌握安全風(fēng)險(xiǎn)、應(yīng)急分析響應(yīng)慢、漏

洞預(yù)警不及時(shí)、缺少響應(yīng)的管控手段，這些都可以通過

SourceCheck 來解決，它能精準(zhǔn)把控開源組件風(fēng)險(xiǎn)，透

明化管理軟件資產(chǎn)鏈條，最小化風(fēng)險(xiǎn)治理成本，最快實(shí)

現(xiàn)安全組件選型，零人工介入自動(dòng)化集成。

SourceCheck 的優(yōu)勢主要體現(xiàn)在六個(gè)方面：

1、 海 量 數(shù) 據(jù)， 專 業(yè) 可 靠： 支 持 Java、Python、

Go、C++ 等 15 種以上主流語言，支持 20 多種包管理器，

擁有 1.2 億組件版本庫，兼容 CNNVD、CNVD、NVD 等權(quán)威

漏洞庫。

2、多維檢測，全面分析：支持源碼包、二進(jìn)制包、

遠(yuǎn)程倉庫、容器、私服檢測，支持組件級、文件級、代

碼片段級檢測，支持組件依賴分析、溯源分析，支持源

碼自研率分析，支持組件漏洞、許可合規(guī)分析檢測庫。

3、自主研發(fā)安全可控：入選國家信創(chuàng)產(chǎn)品名錄，擁

有數(shù)十項(xiàng) SCA 領(lǐng)域發(fā)明專利，通過信通院開源可信工具

評估測試，響應(yīng)國家政策，優(yōu)先兼容國產(chǎn)操作系統(tǒng)、國

產(chǎn)數(shù)據(jù)庫。

4、24 小時(shí)預(yù)警與風(fēng)險(xiǎn)修復(fù)：支持新漏洞預(yù)警，支

持組件推薦版本，支持漏洞修復(fù)建議。

5、無縫集成：支持與主流開發(fā)工具 IDEA、Eclipse

等插件集成，支持與GitLab、Jenkins、Jira等工具集成，

有豐富的 Restful API 接口。

6、豐富的場景：私服安全，實(shí)現(xiàn)私服掃描及私服防

火墻保護(hù)；安全左移，研發(fā)階段早發(fā)現(xiàn)、早處理；持續(xù)

集成，實(shí)現(xiàn)流水線、自動(dòng)化；安全管控，黑白名單、阻

斷機(jī)制；安全審計(jì)，漏洞風(fēng)險(xiǎn)、合規(guī)風(fēng)險(xiǎn)。

四、開源治理總結(jié)

開源治理是一個(gè)體系建設(shè)的工作，涉及多個(gè)部門，

而不僅僅由安全部門獨(dú)立承擔(dān)。在治理環(huán)節(jié)中，組織者

對于企業(yè)內(nèi)部的員工進(jìn)行賦能培訓(xùn)非常重要，讓員工意

識到開源治理的重要性比制度流程強(qiáng)制監(jiān)管更加有效；

尤其在開源治理執(zhí)行環(huán)節(jié)中，階段性治理目標(biāo)的明確非

常重要。最后，工具大部分解決的是問題發(fā)現(xiàn)和處理的

效率，并不能完全杜絕問題。

20

百家論道 LECTURE ROOM

淺談開源治理

中興通訊開源合規(guī)和安全

治理總監(jiān)、ECPOC，在開源許可證

合規(guī)、EAR合規(guī)、開源安全管控和

風(fēng)險(xiǎn)應(yīng)對等領(lǐng)域具有豐富的實(shí)踐

經(jīng)驗(yàn)。資深產(chǎn)品經(jīng)理、研發(fā)過程

改進(jìn)專家、資深合規(guī)專家，長期

從事企業(yè)級產(chǎn)品經(jīng)營、研發(fā)過程、

規(guī)范及過程管控系統(tǒng)的研究與建

設(shè)，致力于企業(yè)級開源可信供應(yīng)

鏈管控機(jī)制的建設(shè)與落地運(yùn)營。

信通院可信開源供應(yīng)鏈資深咨詢

評估師、開源治理標(biāo)準(zhǔn)專家、信

通院 2022年度優(yōu)秀標(biāo)準(zhǔn)專家、可

信開源治理講師、金融開源治理

社區(qū)技術(shù)專家。開源社正式成員，

2022年中國開源先鋒 33人之心

尖上的開源人物。

項(xiàng)曙明

一、開源軟件生態(tài)演變及存在風(fēng)險(xiǎn)

所謂軟件，就是一系列按照特定順序組織的計(jì)算機(jī)數(shù)據(jù)和指令的集合，其

最終的存在價(jià)值在于實(shí)現(xiàn)計(jì)算機(jī)用戶和計(jì)算機(jī)本身之間的溝通橋梁，做到幫助

用戶實(shí)現(xiàn)對于計(jì)算機(jī)的良好控制。隨著信息時(shí)代的不斷發(fā)展，信息化水平的不

斷深入，人們對于計(jì)算機(jī)和網(wǎng)絡(luò)的依賴性也隨之增加，這也同樣推動(dòng)著軟件事

業(yè)的向前發(fā)展。而在這種發(fā)展潮流之下，開源軟件起到了推波助瀾的決定性作

用，也煥發(fā)出越來越強(qiáng)勁的生命力。

所謂開源軟件（OSS，Open Source Software），通常的定義為一種其源

碼可以被公眾使用的軟件，并且此軟件的使用、修改和分發(fā)也不受許可證的限

制。開源軟件最早出現(xiàn)于 20 世紀(jì) 70 年代，至今已經(jīng)經(jīng)歷了數(shù)十年的發(fā)展歷程，

其在操作系統(tǒng)、編譯工具鏈、數(shù)據(jù)庫、服務(wù)器以及移動(dòng)端等方面都有杰出的作

品產(chǎn)生，已經(jīng)成為了當(dāng)前一股不容忽視的力量，并滲透到了當(dāng)前社會(huì)生活和工

作的各個(gè)領(lǐng)域，特別是完全改變了軟件的生產(chǎn)模式，由傳統(tǒng)的閉源開發(fā)模式逐

步演變?yōu)榛煸吹能浖M裝式開發(fā)模式，開源軟件及其衍生組件在當(dāng)代軟件代碼

中的占比達(dá)到了 90% 左右，從不同的側(cè)面和角度影響著人們的日常生活。

開源軟件最早的思想起源于黑客文化，1984 年，美國國家工程院院士

Richard Stallman建立起操作系統(tǒng)GNU（GNU’s Not Unix）,標(biāo)志著基于“自由軟件”

思想的操作系統(tǒng)落成。GNU 的誕生，揭開了開源運(yùn)動(dòng)的序幕，并且通過 GPL 協(xié)議

來保障其能夠永久地實(shí)現(xiàn)免費(fèi)共享和自由的使用、修改與分發(fā)。1985 年 10 月，

Richard Stallman 成立了自由軟件基金會(huì) FSF（Free Software Foundation），

主要目的是為開發(fā) GNU 募集資金。1989 年，Stallman 帶頭起草了 GNU 通用公共

協(xié)議證書，明確提出了“反版權(quán)”思想。1991 年，芬蘭大學(xué)生 Linus Torvalds

基于 GNU GPL 框架了 GNU/Linux，標(biāo)志著 Linux 的誕生。至此，開源軟件的發(fā)展

得到了更多人的支持，并且逐步走向正軌。

隨后開源軟件的發(fā)展起起落落，從高潮到低谷，但是從 2005 年開始新一輪

的開源軟件研發(fā)又開始繼續(xù)發(fā)展，并且在這個(gè)階段由于網(wǎng)絡(luò)的發(fā)展呈現(xiàn)出又一個(gè)

峰值，移動(dòng)數(shù)據(jù)傳輸也在這個(gè)時(shí)間登上了歷史舞臺，各種新技術(shù)方面的開源軟件

不斷涌現(xiàn)，許多開源項(xiàng)目也逐步由個(gè)人發(fā)起的黑客文化逐步向有組織先期開發(fā)，

研發(fā)到一定程度再貢獻(xiàn)到開源社區(qū)，并期待該開源項(xiàng)目能夠成功、形成自己特有

經(jīng)常參加國內(nèi)各種開源社區(qū)的分享、標(biāo)準(zhǔn)和其它活動(dòng)時(shí)聽到，也在各種開

源社區(qū)群、微信群中看到這樣的一些聲音和觀點(diǎn)：“開源治理”治理的是什么？

我用開源軟件還沒有用好、我有項(xiàng)目要貢獻(xiàn)到開源社區(qū)、我只是進(jìn)行開源貢

獻(xiàn)，為什么要說治理呢？近期接到網(wǎng)安加社區(qū)的這篇約稿，我就從我對開源軟

件理解的角度來淺談一下我對開源治理的一些看法，希望能給產(chǎn)業(yè)界和開源界

的同仁們帶來一些思考與啟發(fā)。

21

LECTURE ROOM 百家論道

的商業(yè)生態(tài)的商業(yè)模式進(jìn)行演變，開源組織（公司）、開

源貢獻(xiàn)個(gè)人都期待在開源的商業(yè)模式下獲得成功。

開源軟件的成功又刺激了各行各業(yè)的軟件企業(yè)、創(chuàng)

業(yè)公司更廣泛的使用開源軟件，這可以有效地降低開發(fā)

成本、加快開發(fā)進(jìn)度、促使產(chǎn)品快速上市，幫助企業(yè)獲

得了一個(gè)又一個(gè)的成功。在廣泛被使用的過程中某些開

源軟件也逐漸演變成為各種各樣的事實(shí)標(biāo)準(zhǔn)，并成為某

些商業(yè)項(xiàng)目招標(biāo)的門檻，從而促進(jìn)其被更廣泛地使用。

隨著數(shù)字化轉(zhuǎn)型和云原生技術(shù)的蓬勃發(fā)展，開源軟件也

徹底改變了軟件行業(yè)生態(tài)和開發(fā)模式，并逐漸演變?yōu)橐?/p>

種實(shí)實(shí)在在的商業(yè)模式，也徹底改變了整個(gè)軟件生態(tài)和

競爭模式。

開源軟件在為人們帶來各種實(shí)實(shí)在在好處的同時(shí)，

其本身所固有的各種風(fēng)險(xiǎn)也暴露了出來，并嚴(yán)重影響企

業(yè)正常的經(jīng)營活動(dòng)，影響到廣大個(gè)人消費(fèi)者的正當(dāng)權(quán)益

和使用軟件產(chǎn)品的信心，危及到整個(gè)軟件行業(yè)的良性發(fā)

展。簡單來說，開源軟件存在的風(fēng)險(xiǎn)主要有以下幾種：

（一）許可證合規(guī)使用風(fēng)險(xiǎn)

我們知道，開源軟件雖然實(shí)現(xiàn)了免費(fèi)共享和自由使

用、修改與分發(fā)，但是其代碼版權(quán)從來沒有放棄，它永

遠(yuǎn)屬于開源代碼的貢獻(xiàn)者。而且每一個(gè)開源軟件在其分

發(fā)的過程中均會(huì)遵循一種或多種許可證，這些許可證的

法條在賦予使用者免費(fèi)自由使用開源軟件的同時(shí)也明確

規(guī)定了其必須遵循的義務(wù)；所以在不同的使用場景下，

如果違反了許可證義務(wù)將會(huì)導(dǎo)致許可證合規(guī)使用風(fēng)險(xiǎn)。

（二）產(chǎn)品安全風(fēng)險(xiǎn)

開源軟件數(shù)量眾多，但是大家有沒有發(fā)現(xiàn)，開源軟

件一般都規(guī)定了軟件使用者“責(zé)任自負(fù)”，也就是許可證

均不會(huì)強(qiáng)制自由軟件發(fā)布者給予使用者擔(dān)保，不承擔(dān)適

售性、滿足特定使用目的、知識產(chǎn)權(quán)等任何擔(dān)保。所以

開源軟件功能、性能和產(chǎn)品安全質(zhì)量也是不擔(dān)保的，而

開源軟件的代碼質(zhì)量、分發(fā)后出現(xiàn)的 CVE 漏洞，甚至開

源軟件依賴的其它開源軟件的漏洞、使用了開源軟件的

第三方軟件的安全這些均需要使用開源軟件的項(xiàng)目自己

來承擔(dān)。

（三）EAR 和可信供應(yīng)鏈風(fēng)險(xiǎn)

開源軟件作為公開可獲得軟件中的一種，在滿足一

定條件下是受 EAR 管轄的，如何消除 EAR 的風(fēng)險(xiǎn)，使企業(yè)

能夠 EAR 合規(guī)地使用相關(guān)開源軟件。另外，這些開源軟件

出現(xiàn)漏洞后能否及時(shí)獲得消除漏洞后的可用版本、不能

及時(shí)獲得消除漏洞版本的時(shí)候能否順利的獲取源碼進(jìn)行

自我修復(fù)漏洞、能否順利獲得最新的開源社區(qū)版本等供

應(yīng)鏈方面的風(fēng)險(xiǎn)也同樣存在。這些漏洞若不能及時(shí)消除，

可能會(huì)影響軟件版本的正常運(yùn)行，受到黑客攻擊導(dǎo)致各

種數(shù)據(jù)泄露，特別是個(gè)人數(shù)據(jù)泄露而引起違規(guī)而受到處

罰。還有如出現(xiàn)的某些開源社區(qū)針對某些國家受限的問

題、美國的開源漏洞不及時(shí)公開的問題等均屬于該范疇。

說到這里，我們就來說說開源治理問題，為什么有

開源治理、為什么要開源治理，我不治理又怎么了？

大家參與軟件項(xiàng)目都帶著一個(gè)目的，那就是希望項(xiàng)

目能成功！不論是開源項(xiàng)目還是商業(yè)項(xiàng)目其成功的定義

稍有差異，但是最終的結(jié)果是一樣的，希望自己的項(xiàng)目

能被廣泛使用、最終借助該項(xiàng)目組織和個(gè)人能夠獲得相

應(yīng)的商業(yè)回報(bào)。那么問題來了，什么樣的軟件項(xiàng)目才能

夠獲得成功呢？撇開項(xiàng)目本身，我認(rèn)為一個(gè)項(xiàng)目要成功

必須被廣泛使用，大家愿意用，并借助你這個(gè)軟件來增

加自己項(xiàng)目成功的概率，這時(shí)候你項(xiàng)目的用戶關(guān)注的是：

1、該軟件遵循什么許可證？是商業(yè)許可、OSI許可，

還是其它不太常用的許可證？其許可證風(fēng)險(xiǎn)怎樣？我是

否可以有效地、低成本地合規(guī)使用？

2、該軟件產(chǎn)品質(zhì)量如何，研發(fā)過程中有沒有有效地

合規(guī)和安全管控機(jī)制，產(chǎn)品分發(fā)后能否及時(shí)通報(bào)漏洞信

息，快速分發(fā)補(bǔ)丁版本，有效降低或消除我們使用的安

全風(fēng)險(xiǎn)？

3、該軟件的可獲得性如何？版本有沒有連續(xù)性，是

否會(huì)出現(xiàn)后續(xù)版本無人守護(hù)或者難以獲得的窘境？

4、開源社區(qū)項(xiàng)目非常多，我該如何找到這樣的項(xiàng)

目？它的合規(guī)性、安全性有所保障或者能夠非常容易的

進(jìn)行治理。

5、我知道我想要尋找怎樣的軟件組件了，那么我們

自己項(xiàng)目分發(fā)的軟件能獲得廣大客戶的認(rèn)同嗎？我該怎

么做？

所以這時(shí)候就出現(xiàn)了軟件治理的問題，它涉及開源

選型、合規(guī)使用、安全治理、合規(guī)分發(fā)和運(yùn)維時(shí)的安全

應(yīng)對，只有把這些風(fēng)險(xiǎn)有效的降低和消除，才能提升自

己項(xiàng)目被選擇的機(jī)會(huì)，最終取得成功。所以我認(rèn)為開源

治理是現(xiàn)代軟件項(xiàng)目與生俱來的一門功課，無論怎樣的

項(xiàng)目、無論你如何參與項(xiàng)目、不同的只是治理的目標(biāo)、

內(nèi)容和范圍有所不同而已。當(dāng)然，個(gè)人自己學(xué)習(xí)研究或

企業(yè)內(nèi)部自用而不求廣泛分發(fā)的項(xiàng)目也就不存在上述項(xiàng)

目成功的糾結(jié)，不在討論范圍之內(nèi)。

22

百家論道 LECTURE ROOM

二、軟件開發(fā)及分發(fā)模式演變

軟件開發(fā)及分發(fā)模式的演變豐富了開源治理的內(nèi)

涵，也逐步增加了開源治理的難度和廣度，所以在談?wù)?/p>

開源治理之前有必要簡單陳述一下，以便于后面更好理

解開源治理。

云原生時(shí)代軟件供應(yīng)鏈技術(shù)躍遷式演變，對軟件研

發(fā)模式和分發(fā)內(nèi)容產(chǎn)生了巨大變更，主要變現(xiàn)體現(xiàn)在：

（一）軟件成分的變化，也即新制品

以前的軟件開發(fā)是一個(gè)團(tuán)隊(duì)、一個(gè)項(xiàng)目組進(jìn)行閉源

開發(fā)，代碼基本全是項(xiàng)目組自己寫的，所以其制品只有

一個(gè)版本號就能完整地標(biāo)識出其版權(quán)歸屬，項(xiàng)目團(tuán)隊(duì)對

該項(xiàng)目制品全權(quán)負(fù)責(zé)。

全球開源應(yīng)用契合自動(dòng)化開發(fā)模式，開源因?yàn)槠浔?/p>

利性成為了當(dāng)前軟件開發(fā)中不可或缺的組成部分，混源

的組裝式開發(fā)已成為主流。代碼中除了有項(xiàng)目組自研的

代碼以外，還會(huì)有本公司其它團(tuán)隊(duì)開發(fā)的代碼——如平

臺或組件，以及其它商業(yè)軟件、技術(shù)協(xié)作軟件、外包軟

件、ODM/OEM 軟件、SDK 驅(qū)動(dòng)等第三方軟件；當(dāng)然還會(huì)有

項(xiàng)目組主動(dòng)引入的開源軟件，這時(shí)候的軟件成分就開始

變得復(fù)雜了，也不是項(xiàng)目組能夠全部掌握和守護(hù)的了，

這時(shí)候 SBOM 就顯得尤為重要，它關(guān)乎著新制品的組成、

合規(guī)和安全，如下圖所示：

再后來，我們發(fā)現(xiàn)上述混源開發(fā)中使用到的軟件組

件，其在開發(fā)過程中基本上全部都使用到了開源軟件，

也就是上述 SBOM 若從版本樹的角度出發(fā)一直追蹤到“葉

子”節(jié)點(diǎn)，我們就會(huì)發(fā)現(xiàn)，絕大多數(shù)“葉子”均是開源，

據(jù)可靠數(shù)據(jù)統(tǒng)計(jì)，目前軟件項(xiàng)目平均使用到開源軟件在

整個(gè)項(xiàng)目代碼中的占比達(dá) 90% 左右，所以說開源軟件逐

漸主導(dǎo)了當(dāng)代軟件。

（二）開發(fā)過程的演變，導(dǎo)致版本發(fā)布方式出現(xiàn)新變化，

也即新發(fā)布

軟件研發(fā)過程也從需求、設(shè)計(jì)、開發(fā)、測試到分發(fā)

的瀑布模型，逐步演變至互聯(lián)網(wǎng)時(shí)代的敏捷開發(fā)，強(qiáng)調(diào)

的是快速迭代的價(jià)值交付，再逐步演進(jìn)到云原生時(shí)代的

DevOps，要求進(jìn)行快速的研發(fā)到運(yùn)維，在這樣快速演變

的過程中，分發(fā)的對象也逐步從單一的可執(zhí)行制品到運(yùn)

維環(huán)境的統(tǒng)一發(fā)布，在此過程中，如何確保分發(fā)物的合

規(guī)和安全性。

（三）數(shù)字化應(yīng)用架構(gòu)演變，導(dǎo)致軟件新技術(shù)層出不窮

數(shù)字化應(yīng)用架構(gòu)的演變，新技術(shù)的引入，應(yīng)用架構(gòu)

從單體應(yīng)用逐步到 SOA，并逐步演進(jìn)到微服務(wù)，軟件分

發(fā)物就是一組微服務(wù)，如何確保這些微服務(wù)能夠有效地

進(jìn)行合規(guī)和安全治理給我們提出了新的課題。

（四）數(shù)字化基礎(chǔ)設(shè)施的演進(jìn)，為軟件開發(fā)提供了新環(huán)境

云原生技術(shù)的發(fā)展，夯實(shí)了數(shù)字底座，簡化了部

署環(huán)境，基礎(chǔ)設(shè)施逐步從 IDC 物理機(jī)向虛擬化、容器化

方向演變，與此相對應(yīng)的基礎(chǔ)設(shè)施，項(xiàng)目組相應(yīng)的分發(fā)

物、分發(fā)方式也隨之改變，如容器分發(fā)除了原來傳統(tǒng)的

軟件版本以外，還需要一起分發(fā)的基礎(chǔ)鏡像和一組運(yùn)行

依賴，這些基礎(chǔ)鏡像和運(yùn)行依賴的合規(guī)安全性問題也就

成為新的開源治理對象之一了。

三、為何需要開源治理

前面說了，若軟件項(xiàng)目沒有商業(yè)分發(fā)、商業(yè)成功這

方面的訴求，完全是可以不需要做任何的開源治理的。

但偏偏絕大多數(shù)的軟件項(xiàng)目都有商業(yè)成功方面的壓力，

既然需要成功，就要求我們的軟件項(xiàng)目遵從外部法律法

規(guī)、客戶要求等約束，并能低成本、高效地完成項(xiàng)目的

合規(guī)和安全治理，而項(xiàng)目使用到的開源軟件的治理也就

顯得尤為重要。

（一）軟件商業(yè)分發(fā)

既然一般軟件使用到的開源軟件占比達(dá)到整個(gè)項(xiàng)

23

LECTURE ROOM 百家論道

目代碼量的 90% 左右，而企業(yè)進(jìn)行商業(yè)分發(fā)的目的是要

滿足客戶的商業(yè)要求，并使客戶在使用該商業(yè)軟件過程

中不會(huì)出現(xiàn)由于合規(guī)和安全問題而導(dǎo)致客戶商業(yè)利益受

損。為客戶創(chuàng)造價(jià)值，從而也為自己獲得更多成功的機(jī)

會(huì)。所以商業(yè)軟件的開源治理，可以使客戶放心使用你

的產(chǎn)品，以防出現(xiàn)：

1、由于沒有有效開源治理，導(dǎo)致商業(yè)訴訟，而使客

戶購買的商業(yè)軟件停服或不能獲得版本更新的風(fēng)險(xiǎn)。

2、由于沒有有效開源治理，導(dǎo)致不能及時(shí)發(fā)現(xiàn)漏

洞、及時(shí)修復(fù)漏洞發(fā)布修復(fù)版本，而使客戶面臨被攻

擊、系統(tǒng)癱瘓不能正常運(yùn)行、漏洞導(dǎo)致個(gè)人信息數(shù)據(jù)泄

露面臨巨額罰款的風(fēng)險(xiǎn)。

（二）開源生態(tài)建設(shè)和開源貢獻(xiàn)

商業(yè)軟件的分發(fā)是傳統(tǒng)軟件商業(yè)模式，由于使用到

了開源軟件，其商業(yè)模式也需要做相應(yīng)調(diào)整。除此以外，

現(xiàn)在還有很多企業(yè)和個(gè)人熱衷于項(xiàng)目開源和貢獻(xiàn)，構(gòu)建

開源生態(tài)建設(shè)。前面說到，開源是一種商業(yè)模式，所以

開源生態(tài)建設(shè)和開源貢獻(xiàn)最終也需要其開源項(xiàng)目獲得成

功，其商業(yè)模式才能夠得以變現(xiàn)。

那么如何使開源項(xiàng)目獲得成功的概率增加呢？如果

不進(jìn)行開源治理會(huì)有哪些影響？

1、若不進(jìn)行開源治理，開源項(xiàng)目可能會(huì)導(dǎo)致許可證

沖突、許可證合規(guī)治理困難、導(dǎo)致在最終用戶的開源選

型中落選，不能被廣泛使用也就難以獲得成功。

2、若不進(jìn)行開源治理，開源項(xiàng)目可能都不知道使用

了哪些開源軟件、這些開源軟件是如何使用的，從而增

加最終用戶開源合規(guī)治理的難度。

3、若不進(jìn)行開源治理，開源項(xiàng)目就不能及時(shí)了解和

發(fā)現(xiàn)所使用到的開源軟件的漏洞信息，不能及時(shí)更新安

全版本，也會(huì)影響到開源選型的成功率而影響項(xiàng)目成功。

（三）提升研發(fā)效能

企業(yè)一般會(huì)有很多商業(yè)分發(fā)的項(xiàng)目，也會(huì)有一些項(xiàng)

目開源，既然已經(jīng)知道這些項(xiàng)目若想成功就必須進(jìn)行開

源治理。那么如何進(jìn)行開源治理，才能提升開源治理研

發(fā)效能？進(jìn)而提升企業(yè)的投入產(chǎn)出，更好地實(shí)現(xiàn)商業(yè)目

標(biāo)？從這一點(diǎn)來講，主動(dòng)構(gòu)建適合企業(yè)有效的開源合規(guī)

和安全管控機(jī)制，提升組織開源治理能力，也是企業(yè)在

開源生態(tài)環(huán)境下的最佳選擇之一。

四、開源治理的類別

前面講了開源軟件生態(tài)的演變及存在的風(fēng)險(xiǎn)，也了

解了在新制品、新發(fā)布、新技術(shù)和新環(huán)境下開源治理所

要關(guān)注內(nèi)容的變化、以及在當(dāng)前開源生態(tài)已無法繞開的

場景下，企業(yè)進(jìn)行軟件商業(yè)經(jīng)營的過程中必須進(jìn)行開源

治理才有可能取得成功。那么一般來說，開源治理會(huì)涉

及到哪些類別和內(nèi)容呢？

通過分析，我們知道，企業(yè)與開源有關(guān)的活動(dòng)主要

有以下三條主線：

（一）軟件的可信開發(fā)與運(yùn)維

它是支撐企業(yè)進(jìn)行軟件商業(yè)化合規(guī)和安全治理生產(chǎn)

的主流程。主要是構(gòu)建企業(yè)的開源治理框架，主要內(nèi)容

包括：

1、選擇可信開源：SCA 工具、組件廣場、開源選型、

官網(wǎng)同源、供應(yīng)商認(rèn)證、第三方選型。

2、可信使用開源：同源構(gòu)建、版本同源、合規(guī)和

安全治理、安全左移。

3、可信產(chǎn)品分發(fā)：合規(guī)分發(fā)、安全分發(fā)。

4、可信產(chǎn)品運(yùn)維：可信追溯、安全應(yīng)對。

（二）可信開源開發(fā)

企業(yè)進(jìn)行項(xiàng)目開源和貢獻(xiàn)時(shí)，為了提升開源項(xiàng)目的

成功率而進(jìn)行的可信開源社區(qū)、可信開源項(xiàng)目開發(fā)。其

開源治理主要包括：以可信開源項(xiàng)目、社區(qū)標(biāo)準(zhǔn)為要求

貢獻(xiàn)可信開源項(xiàng)目和開源社區(qū)。提供可信開源項(xiàng)目和組

件，提升開源項(xiàng)目的成功率。

（三）可信內(nèi)源開發(fā)

它是企業(yè)進(jìn)行開源治理過程中的必要補(bǔ)充，指的是

為了支撐“可信開發(fā)與運(yùn)維”和“可信開源開發(fā)”的開

源治理而進(jìn)行的可信內(nèi)源開源治理，它主要包括開源項(xiàng)

目孵化、企業(yè)使用開源項(xiàng)目守護(hù)、以及內(nèi)源項(xiàng)目開發(fā)。

其開源治理主要包括：

1、開源文化建設(shè)，以內(nèi)源方式構(gòu)建內(nèi)部組件開發(fā)

和交易機(jī)制。

2、內(nèi)部孵化開源項(xiàng)目，為可信開源項(xiàng)目做好準(zhǔn)備。

3、核心開源組件識別及可信商業(yè)化要求內(nèi)源開源

守護(hù)。

企業(yè)只有結(jié)合自身特點(diǎn)和商業(yè)模式，選擇合適的開

源治理類別和目標(biāo)，一步一個(gè)腳印，從 SCA掃描開始做起，

逐步構(gòu)建起支撐企業(yè)經(jīng)營的全方位的開源治理管控架構(gòu)

和能力，它和企業(yè)軟件處于什么階段、企業(yè)大小無關(guān)。

24

百家論道 LECTURE ROOM

DevSecOps 實(shí)踐：如何在研

發(fā)過程中做好供應(yīng)鏈安全

資深安全研發(fā)顧問、安全

敏捷教練、DevSecOps 專家、安

全工具專家、研發(fā)效能專家。有

10 年軟件安全行業(yè)從業(yè)經(jīng)驗(yàn)。

具有豐富的研發(fā)實(shí)踐、安全工

具開發(fā)和實(shí)踐、S-SDLC 實(shí)踐、

DevSecOps 實(shí)踐經(jīng)驗(yàn)。輔導(dǎo)多家

企業(yè)從零開始構(gòu)建 DevSecOps、

S-SDLC。

潘志祥 一、DevSecOps 與供應(yīng)鏈安全

現(xiàn)在很多企業(yè)都建立了 DevOps 流程，但安全基本還處在流程之外，沒有融

入傳統(tǒng) DevOps 流程，導(dǎo)致安全一直都是敏捷交付的瓶頸。

（一）DevSecOps———供應(yīng)鏈安全治理基石

在很多企業(yè)尋求 DevSecOps解決方案的背景下，安全左移的理念愈發(fā)重要。

美國國防部白皮書中也提到 DevSecOps 落地的核心就是安全左移，但其中強(qiáng)調(diào)

的安全左移是在研發(fā)階段做安全測試，這樣的左移并不徹底。真正實(shí)施安全左

移比較徹底的是微軟的 SDLC 理念，強(qiáng)調(diào)安全應(yīng)該在更早期階段介入。

經(jīng)過近幾年的不斷實(shí)踐，DevSecOps 已經(jīng)做到了比較深度的安全左移，并

不只是在研發(fā)階段做安全測試，而是在需求階段就考慮安全，甚至是在立項(xiàng)階

段就介入安全。

安全左移的價(jià)值不容忽視，我們知道在不同階段發(fā)現(xiàn)并修復(fù)問題的成本是

呈幾何增長的。如果在研發(fā)階段發(fā)現(xiàn)并且修復(fù)問題的成本是“1”，在測試階段

修復(fù)問題的成本就是“2”，在發(fā)布階段修復(fù)問題的成本就變成了“10”，在運(yùn)行

階段發(fā)現(xiàn)并修復(fù)問題的成本就會(huì)是“100”，甚至于對業(yè)務(wù)運(yùn)營的影響難以估量，

因?yàn)橛行┌踩珕栴}就是一個(gè)企業(yè)的生命線。

（二）供應(yīng)鏈安全治理落地難點(diǎn)

1、供應(yīng)鏈安全治理環(huán)節(jié)分散。在編碼、編譯、部署等環(huán)節(jié)都容易出問題。

2、研發(fā)修復(fù)成本高。安全問題修復(fù)滯后，頻繁回歸。

3、供應(yīng)鏈安全治理依賴多工具能力。單一工具難以覆蓋供應(yīng)鏈安全所有的

治理對象，現(xiàn)在提到供應(yīng)鏈治理工具基本都是 SCA，但是像操作系統(tǒng)、中間件這

些都是在供應(yīng)鏈治理過程中需要考慮的治理對象。

4、安全是孤島而不是流程。安全工具獨(dú)立使用，安全漏洞只存在于安全工

具內(nèi)，沒有跟研發(fā)、測試、安全、運(yùn)維流程打通，沒有融入流程，進(jìn)而導(dǎo)致安

全工作只能階段性介入，影響交付節(jié)奏和周期。

5、缺乏全流程治理經(jīng)驗(yàn)?；诎踩就袄碚?，補(bǔ)足安全短板，做到供應(yīng)鏈

安全的全面治理也有賴于安全經(jīng)驗(yàn)。

6、沒有供應(yīng)鏈資產(chǎn)管理。這一塊主要是針對 SBOM 解決方案而言，SBOM 只

是一個(gè)靜態(tài)的軟件物料清單，如果發(fā)現(xiàn) 0day 安全問題，掃描所有代碼倉庫的

25

LECTURE ROOM 百家論道

效率顯然太低，而且掃描之后能否快速呈現(xiàn)有問題的軟

件，也是需要去考慮的，從資產(chǎn)管理以及事后盤查等角

度出發(fā)。

（三）交付管道

CI/CD 交付管道，也就是流水線，現(xiàn)在的安全工具

基本都是采用編排的形式接入到流水線中。因?yàn)榘踩?/p>

具種類繁多，不可能每一個(gè)都登錄進(jìn)去制定掃描計(jì)劃，

加上現(xiàn)在很多核心系統(tǒng)都實(shí)現(xiàn)了服務(wù)化改造，在每個(gè)工

具上針對每個(gè)服務(wù)應(yīng)用去創(chuàng)建檢測任務(wù)的工作量對安全

團(tuán)隊(duì)來講幾乎無法完成，所以現(xiàn)在的安全檢測工具已經(jīng)

上升到了編排的維度。

值得一提的是，盡管在流水線中可以同時(shí)發(fā)起多個(gè)

檢測工具進(jìn)行檢測，但在實(shí)際情況中并不會(huì)這樣來編排

流水線。如果是研發(fā)測試環(huán)境的流水線，通常會(huì)將安全

檢測全部靠后，因?yàn)榇藭r(shí)要做的事情是快速把應(yīng)用構(gòu)建

起來進(jìn)行部署，然后讓研發(fā)和測試去驗(yàn)證功能。驗(yàn)證完

功能之后，再去看安全檢測工具檢測到的漏洞，因?yàn)樵?/p>

部署之后，安全檢測工具同時(shí)開啟檢測，功能測試與安

全檢測工作幾乎可同時(shí)完成。

如果是針對上線的流水線，所有安全檢測工具編排

會(huì)盡量靠前，而且此時(shí)安全檢測工具必須要有安全卡點(diǎn)

的能力，也就是在每個(gè)工具中設(shè)置一個(gè)安全閾值，比如

針對 SCA 工具，定義它的超危組件不能超過一個(gè)，否則

不允許執(zhí)行后續(xù)的流水線。通過這種方式，就能實(shí)現(xiàn)質(zhì)

量一致性保障通道。所謂質(zhì)量一致性保障，就是無論在

何種業(yè)務(wù)研發(fā)背景下，每次通過流水線交付出去的制品

都符合質(zhì)量要求。這就能形成一種文化，即研發(fā)人員在

提交代碼時(shí)就會(huì)思考能否過安全卡點(diǎn)，如此思考安全問

題的方式也就得以改變。

此外，現(xiàn)在針對安全工具的很多解決方案是在流水

線里寫一個(gè)腳本，把代碼提交到白盒檢測工具中掃描，

然后去拿檢測結(jié)果，但是現(xiàn)在很多微服務(wù)應(yīng)用少則幾十

個(gè)，多則成百上千個(gè)。面對上千個(gè)應(yīng)用，每天提交一次

代碼到流水線中檢測，任何一款白盒工具能無法支撐。

所以將安全工具放到流水線中，常態(tài)化、自動(dòng)化執(zhí)行對

于安全工具的技術(shù)要求也發(fā)生了根本性的變化。它并不

是在流水線中簡單寫個(gè)腳本去調(diào)用檢測工具的檢測接

口，然后獲取數(shù)據(jù)，而是要考慮每一種檢測工具的檢測

能力是分布式的。

所以我們在 DevSecOps 流水線中可以衍生很多跟現(xiàn)

在企業(yè)實(shí)施思路不一樣的地方，我們可能要評估現(xiàn)在的

流水線能否承載核心系統(tǒng)未來的業(yè)務(wù)發(fā)展，整個(gè)安全執(zhí)

行的效率是否達(dá)到要求。而且無論在什么狀態(tài)下，軟件

的質(zhì)量都要符合風(fēng)險(xiǎn)可接受的范圍。

二、DevSecOps 安全能力體系建設(shè)

DevSecOps 有兩個(gè)發(fā)展方向，一個(gè)是 One by one，

一個(gè)是 All in one。

One by one 就是基于 Jira、Jenkins、GitLab 的解

決方案，組合在一起形成一個(gè)自動(dòng)化流程。All in one

是一體化平臺，它不是簡單的將工具集成進(jìn)來，而是在

平臺上重新開發(fā)。

（一）DevSecOps 一體化平臺

DevSecOps 是效率的代名詞，之所以很多企業(yè)一直

在提倡它，是因?yàn)楣?yīng)鏈治理工作的復(fù)雜性，除了供應(yīng)

鏈治理以外，還要考慮云原生安全、應(yīng)用安全、數(shù)據(jù)安

全、合規(guī)安全等，企業(yè)要想做好這些安全工作比較困

難。White Hat 組織在 2021 年針對全美公共事業(yè)部的互

聯(lián)網(wǎng)應(yīng)用發(fā)布了一份安全調(diào)研報(bào)告，報(bào)告顯示制造業(yè)有

60% 以上的企業(yè)存在可利用漏洞，暴露窗口期在 365 天

以上，金融行業(yè)有 40% 以上的企業(yè)存在此類問題。由此

可見，國內(nèi)的在線運(yùn)營系統(tǒng)，其安全狀況也不容樂觀，

在這種情況下一體化平臺將是發(fā)展的必然趨勢。

根 據(jù) GitLab 和 Jenkins 的 官 網(wǎng) 介 紹，GitLab 的

配置文件叫 gitlab-ci.yml，是解決持續(xù)集成的問題；

Jenkins 的配置文件是 Jenkinsfile，是持續(xù)部署的解決

方案。國外的 CI/CD 流水線比較嚴(yán)謹(jǐn)，CI 與 CD 的功能

更加明確，但是簡單的將 GitLab 與 Jenkins 相加并不等

同于 CI/CD，所以真正在做 CI/CD 時(shí)必然是向一體化的

趨勢發(fā)展。

在一體化的平臺框架之下，可以進(jìn)行大量的數(shù)據(jù)挖

掘。需求從郵件列表提出來，進(jìn)入到需求中心，到產(chǎn)研

環(huán)境，再到預(yù)發(fā)環(huán)境，然后上線。需求這一數(shù)據(jù)對象流

26

百家論道 LECTURE ROOM

經(jīng)很多工具，每一個(gè)工具停滯的時(shí)間都由不同角色的工

作來決定。DevOps 講究高效的端到端價(jià)值流交付，但

是像需求平均交付周期、需求流負(fù)載、產(chǎn)研周期等指標(biāo)

都統(tǒng)計(jì)不出來，就不能算真正的 DevOps，只是一個(gè)自

動(dòng)化流程而已，這也是很多企業(yè)的現(xiàn)狀。所以一體化的

DevOps，也將是未來研發(fā)效能的發(fā)展趨勢。

（二）DevSecOps 安全能力體系

DevSecOps 安全能力體系，就是針對整個(gè)研運(yùn)流程去

做安全能力抽象。比如在設(shè)計(jì)階段做威脅建模，但現(xiàn)在

做威脅建模的企業(yè)并不多，因?yàn)樗穆涞胤浅Ｒ蕾囉谪?fù)

責(zé)人豐富的經(jīng)驗(yàn)，除了要懂安全，還要懂滲透、攻擊、

研發(fā)、架構(gòu)、業(yè)務(wù)等等，才能考慮怎樣去解決這些風(fēng)險(xiǎn)。

在供應(yīng)鏈這一塊需要做很多檢測，比較多的就是直

接引用的第三方組件，我們在供應(yīng)鏈中經(jīng)常會(huì)提到開源

軟件，但是我更偏向于提開源組件或第三方組件，因?yàn)?/p>

開源軟件的范圍太泛了。比如 Redis 緩存，從第三方組

件的角度來考慮，就是在代碼里引入了一個(gè) Redis 的調(diào)

用組件，這個(gè)組件可能有問題，但是 Redis 部署的服務(wù)

可能也有問題，所以開源軟件治理的范圍從組件和軟件

兩個(gè)角度來講，就有兩個(gè)不同的維度需要去治理。

Redis 的環(huán)境基本上都要進(jìn)行基線掃描，甚至要人

工去做安全配置檢查，所以安全不能只想著引入工具和

如何使用它，而是這個(gè)工具能解決什么問題，接下來要

怎么把它放到流程里面，自動(dòng)化建立起來。

接下來，如果要做供應(yīng)鏈安全治理，只需要建立

一個(gè)視圖即可，能查到所有應(yīng)用資產(chǎn)下面的組件漏洞信

息，以及每一個(gè)部署環(huán)境的信息。所有的檢測任務(wù)或者

漏洞的修復(fù)情況，只需在流程中完成即可。

三、DevSecOps 實(shí)踐落地

實(shí)踐一：IDE 安全自測

一旦建立流程之后，必須確保讓研發(fā)有一個(gè)高效的

流程可以提前感知，因?yàn)檠邪l(fā)會(huì)考慮提交的代碼要過安

全卡點(diǎn)，否則會(huì)影響 KPI 考核。而且代碼提交到線上之

后觸發(fā) CI 流程比較耗時(shí)，如果在 IDE 層面有檢測插件，

研發(fā)就可以快速自測，就能知道自己引入了哪些有問題

的包，經(jīng)修改檢測無誤就可以將代碼上傳。

實(shí)踐二：創(chuàng)建安全私服

如果我們使用第三方私服，或者不對內(nèi)部的私服做

任何安全管控，在做軟件構(gòu)建之后就需要依賴大量的檢

測。如前所述，在測試階段發(fā)現(xiàn)漏洞的修復(fù)成本是研發(fā)

階段的兩倍，因此為避免在研發(fā)階段投入更多成本，可

以在所有的第三方組件進(jìn)入私服時(shí)進(jìn)行安全審計(jì)，只有

符合安全要求才能進(jìn)入私服。其實(shí)這也是 SCA 工具的一

個(gè)功能，它開放了一個(gè)網(wǎng)絡(luò)代理，當(dāng)我們?nèi)ス驳慕M件

倉庫下載組件時(shí)，組件會(huì)經(jīng)過代理的檢查，檢查通過再

將其放到倉庫中；如果檢查有問題，可以有不同的處理

策略，比如先放到一個(gè)緩存隊(duì)列中去做評估或者直接拒

絕。在具體實(shí)施時(shí)，可以再配置外部私服，然后動(dòng)態(tài)去

做入庫檢測以及構(gòu)建的動(dòng)作。

實(shí)踐三：建立一致性質(zhì)量內(nèi)循環(huán)

CI/CD 是兩個(gè)階段的流程，但是現(xiàn)在企業(yè)能做到 CD

的并不多，因?yàn)?CD 有不同的理解，一個(gè)是持續(xù)交付，一

個(gè)是持續(xù)部署。持續(xù)部署是一個(gè)技術(shù)行為，跟 CI 差不

多，但是持續(xù)交付則需要非常多的能力來支撐。CI 環(huán)節(jié)

也不是一個(gè)過程，因?yàn)樵诓煌沫h(huán)節(jié)有不同的流水線去

做安全工作，整個(gè)安全工作已經(jīng)實(shí)現(xiàn)了一個(gè)常態(tài)化自動(dòng)

化，敏捷的特點(diǎn)就是小步快走，檢測到增量漏洞后快速

修復(fù)，這個(gè)增量漏洞并不只是定義到修復(fù)超危漏洞，而

是低危漏洞也要一起修復(fù)。這是進(jìn)入了一個(gè)比較好的狀

態(tài)，質(zhì)量內(nèi)循環(huán)建立起來會(huì)非常高效，軟件安全的質(zhì)量

控制也會(huì)更加高效。

實(shí)踐四：建立安全管控機(jī)制

安全管控機(jī)制，就是前面說到的安全工具卡點(diǎn)，現(xiàn)

在幾乎是沒有哪一個(gè)安全工具有卡點(diǎn)能力。一般做安全

卡點(diǎn)，都是自己通過寫腳本，然后去判斷當(dāng)前的安全漏

洞數(shù)據(jù)情況?，F(xiàn)在的工具可以去配置添加不同的卡點(diǎn)閾

值要求，然后去選擇執(zhí)行策略，比如說終止或繼續(xù)，同

時(shí)還可以快速通知到相關(guān)的責(zé)任人。

計(jì)劃階段

威脅建模

安全分析與設(shè)計(jì)

安全需求評審

架構(gòu)安全評審

數(shù)據(jù)安全評審

安全需求標(biāo)準(zhǔn)庫

編碼階段

安全編碼

代碼實(shí)時(shí)安全檢測

源代碼安全評審

證書、秘鑰安全

開源組件安全

License合規(guī)

代碼庫安全防護(hù)

運(yùn)營階段

網(wǎng)站威脅掃描

應(yīng)用安全監(jiān)控

數(shù)據(jù)服務(wù)安全管理

安全事件監(jiān)控響應(yīng)

云上云下資產(chǎn)漏洞掃描

運(yùn)行時(shí)安全防護(hù)（RASP）

輿情風(fēng)險(xiǎn)威脅

安全應(yīng)急響應(yīng)

安

全

活

動(dòng)

能力

引擎

鏡像掃描引擎 源代碼審計(jì)引擎 成分分析引擎 資產(chǎn)發(fā)現(xiàn)引擎 漏洞檢測引擎 入侵檢測引擎 基線掃描引擎 惡意文件庫攻擊行為模型

安全需求庫 安全設(shè)計(jì)庫 安全研發(fā)庫 安全測試庫 安全培訓(xùn) 研發(fā)安全培訓(xùn) 應(yīng)急響應(yīng)方案 基線庫漏洞庫

測試、持續(xù)集成階段

鏡像掃描

依賴分析（SCA）

代碼規(guī)范掃描

APP安全掃描

安全質(zhì)量門禁

代碼安全掃描

（SAST）

漏洞掃描

滲透測試

接口安全測試

APP安全掃描

APP安全加固

制品庫安全防護(hù)

灰盒安全測試（IAST）

動(dòng)態(tài)安全掃描（DAST）

制品安全檢測

鏡像安全檢測

配置安全管控

安全基線檢測

重大漏洞檢測

27

LECTURE ROOM 百家論道

DevSecOps 度量和正確的使

用方式

某世界 500 強(qiáng)金融企業(yè)

DevOps/DevSecOps 負(fù)責(zé)人。

英國倫敦帝國理工學(xué)院博士

畢業(yè)。畢業(yè)后在多家大型銀

行從事 DevOps 工作。2019 年

加入騰訊 TEG。2020 年作為

首席技術(shù)布道師加入騰訊云

CODING。從 2018 年到 2020 年

間，作為演講嘉賓出席過國

內(nèi)外 30 幾場技術(shù)峰會(huì)和論壇

分 享 DevOps 和 DevSecOps 經(jīng)

驗(yàn)（Open Source Summit,DevOpsDays,National DevOps

Conference,Gdevops 等）。

在企業(yè)發(fā)展的過程中，有很多問題都是可以被感知到的，但是可能缺乏一

種方式去量化它。所以我們需要一把“尺子”使得團(tuán)隊(duì)里的人都能夠感受到變化，

以及分析這種變化是不是我們希望的趨勢和使用這把“尺子”去影響我們對未

來的判斷。度量，就是在企業(yè)內(nèi)部落地這把“尺子”的方式之一。

一、為什么需要度量

管理學(xué)之父德魯克說：“如果你不能度量它，就無法改變它”。度量可以幫

助我們更深刻地理解研發(fā)效能，甚至影響我們的決策，指引改進(jìn)方向，并量化

改進(jìn)效果。而度量驅(qū)動(dòng)是通過度量數(shù)據(jù)，認(rèn)識和理解目標(biāo)及其背后的原因，最

終作為決策的輸入，影響到技術(shù)的使用，人的文化意識的改變，甚至管理層的

決策。

當(dāng)基于度量做決策時(shí)，因?yàn)橛袛?shù)據(jù)的支撐，減少了誤判的概率，并且讓決

定變得更快更準(zhǔn)確、有邏輯、易于闡述，因此不需要太多解釋，也不易被反駁。

團(tuán)隊(duì)間的溝通也可以由度量數(shù)據(jù)驅(qū)動(dòng)，使得大家避免過多的主觀判斷，因此也可

以減少團(tuán)隊(duì)之間的指責(zé)，從而改善團(tuán)隊(duì)的合作氣氛和加強(qiáng)團(tuán)隊(duì)之間的溝通。

另外，在組織內(nèi)實(shí)現(xiàn)度量驅(qū)動(dòng)，這不僅僅是技術(shù)的改變，更重要的是文化

上的變化。每個(gè)人都需要轉(zhuǎn)換觀念，態(tài)度和對開發(fā)過程的理解。最終通過度量

去驅(qū)動(dòng)人的思維模式的轉(zhuǎn)變，進(jìn)而逐漸改變整個(gè)企業(yè)的文化。另外，度量通過

數(shù)據(jù)反饋也可以降低轉(zhuǎn)型過程中的不確定性，實(shí)時(shí)的度量指標(biāo)可以幫助企業(yè)快

速調(diào)整提高轉(zhuǎn)型的成功率。縮短交付周期找到可行的敏捷實(shí)踐。形成通過度量

快速反饋和快速?zèng)Q策的機(jī)制，讓改善可以持續(xù)發(fā)生，鼓勵(lì)分享改進(jìn)經(jīng)驗(yàn)提升員

工榮譽(yù)感。最后，用流程固化有效的 DevSecOps 實(shí)踐，并在流程里進(jìn)行度量跟

蹤和關(guān)聯(lián)。從而提高研發(fā)能力與交付速度，質(zhì)量和安全的關(guān)聯(lián)性。

雖然度量可以為團(tuán)隊(duì)帶來持續(xù)反饋和持續(xù)改進(jìn)，并且驅(qū)動(dòng)整個(gè) DevSecOps

轉(zhuǎn)型的落地，然而，大量實(shí)踐證明，向開發(fā)團(tuán)隊(duì)引入度量，可能需要經(jīng)歷一個(gè)

理解、學(xué)習(xí)、踩坑，最終成功的漫長而艱難的過程，因?yàn)楹芏嘁蛩囟紩?huì)影響最

終結(jié)果，比如企業(yè)的文化、員工的意識和態(tài)度、管理層是否支持、度量的使用

方法、以及大家的工作習(xí)慣等。因此，為了更好更容易地讓管理層支持和開發(fā)

團(tuán)隊(duì)接受度量，需要梳理并使用正確的度量指標(biāo)，以及分析如何正確地使用度

量等。

周紀(jì)海

28

百家論道 LECTURE ROOM

二、DevSecOps 度量指標(biāo)

前面我們提到，度量可以幫助團(tuán)隊(duì)發(fā)現(xiàn)問題和瓶

頸，并檢驗(yàn)改進(jìn)措施效果，但是不同團(tuán)隊(duì)所處階段、

研發(fā)能力成熟度、面臨問題的不同，導(dǎo)致了度量體系并

沒有所謂的唯一性，因此團(tuán)隊(duì)需要根據(jù)自己的場景選擇

合適的度量指標(biāo)和方法。并且即使是在同一個(gè)公司或者

團(tuán)隊(duì)內(nèi)，度量體系也應(yīng)該是持續(xù)演進(jìn)的，而不是固定不

變。雖然度量體系沒有唯一性，但行業(yè)眾多公司經(jīng)過大

量的度量實(shí)踐，也總結(jié)了一些具有普適性的研發(fā)效能度

量的考量維度 - 交付速度、交付質(zhì)量和交付安全等，這

些指標(biāo)的提升需要組織通過管理、技術(shù)、協(xié)作等多方面

的系統(tǒng)性地改進(jìn)。下圖列舉了研發(fā)效能常見的度量指標(biāo)。

關(guān)于交付效率或速度，從軟件開發(fā)整個(gè)生命周期層

面的交付周期，開發(fā)周期，到需求側(cè)的需求吞吐量，持

續(xù)集成過程中的相關(guān)的過程數(shù)據(jù)，如代碼提交頻率、構(gòu)

建次數(shù)、構(gòu)建頻率、構(gòu)建時(shí)長、構(gòu)建成功率、構(gòu)建修復(fù)

時(shí)間等，以及發(fā)布部署側(cè)相關(guān)的指標(biāo)、發(fā)布頻率、發(fā)布

成功率、發(fā)布時(shí)長、發(fā)布前置時(shí)間等，都可以幫助團(tuán)隊(duì)

去判定研發(fā)團(tuán)隊(duì)是否能夠做到小步提交、頻繁提交，并

且當(dāng)發(fā)現(xiàn)問題之后能否快速地響應(yīng)等。

質(zhì)量方面的度量又分為結(jié)果質(zhì)量度量和過程質(zhì)量度

量。線上或結(jié)果質(zhì)量度量（比如線上故障個(gè)數(shù)、線上缺

陷密度、系統(tǒng)下線時(shí)長、故障平均恢復(fù)時(shí)間等）是常見

的容易被領(lǐng)導(dǎo)關(guān)注的度量指標(biāo)，因?yàn)檫@種結(jié)果度量指標(biāo)

可以很直觀的體現(xiàn)團(tuán)隊(duì)對于業(yè)務(wù)交付的價(jià)值。傳統(tǒng)的線

上度量也更多是監(jiān)控提供的關(guān)于業(yè)務(wù)、應(yīng)用和基礎(chǔ)設(shè)施

的度量，這些往往是運(yùn)維團(tuán)隊(duì)掌控的。除了結(jié)果質(zhì)量度

量指標(biāo)去驗(yàn)證和保證 DevSecOps 交付的最終質(zhì)量以外，

過程質(zhì)量度量更能幫助團(tuán)隊(duì)確保各個(gè)環(huán)節(jié)的交付質(zhì)量，

以保障最終交付的質(zhì)量。比如，低質(zhì)量的、重復(fù)的、高

復(fù)雜度的代碼會(huì)產(chǎn)生大量的技術(shù)負(fù)債，使得軟件交付效

率無法得到有效提升，所以需要持續(xù)獲取代碼質(zhì)量相關(guān)

的數(shù)據(jù)，持續(xù)改進(jìn)代碼質(zhì)量。

單元測試作為開發(fā)階段的自動(dòng)化測試方案，其單元

測試用例數(shù)，單元用例通過率，單元用例覆蓋率等參數(shù)

也常常作為這個(gè)階段的標(biāo)準(zhǔn)指標(biāo)，用來保證代碼層面關(guān)

于函數(shù)和邏輯方面的質(zhì)量。除了開發(fā)過程中的代碼質(zhì)量

外，另一類常常被關(guān)注的過程質(zhì)量度量是與需求最相關(guān)

的缺陷。測試階段發(fā)現(xiàn)的缺陷代表開發(fā)的代碼并沒有滿

足需求里的變更要求（比如新的功能點(diǎn)等），尤其是與業(yè)

務(wù)關(guān)聯(lián)的嚴(yán)重缺陷。因此，缺陷個(gè)數(shù)或密度、嚴(yán)重缺陷

比等度量指標(biāo)通常作為開發(fā)質(zhì)量保障（QA）的驗(yàn)收指標(biāo)。

除了功能性要求，某些場景對系統(tǒng)或產(chǎn)品的性能也有著

特殊的要求，因此相關(guān)的性能度量指標(biāo)（比如延遲時(shí)長、

流量負(fù)載等）也作為 QA 驗(yàn)收指標(biāo)而變得同樣重要。

前面我們討論了交付速度和交付質(zhì)量的度量，這些

更多是傳統(tǒng) DevOps 所關(guān)注的領(lǐng)域。而 DevSecOps 度量體

系不僅僅包含速度和質(zhì)量，安全作為核心目標(biāo)也同等重

要。目前的 DevSecOps 更多的安全左移發(fā)生在開發(fā)和測

試階段，比如代碼安全掃描、第三方安全掃描以及對于

測試環(huán)境的動(dòng)態(tài)和交互式安全掃描。各種安全掃描的結(jié)

果主要總結(jié)為不同級別（高危、中危、低危等）的安全

風(fēng)險(xiǎn)和漏洞數(shù)量等指標(biāo)和參數(shù)。

除了掃描出來的安全漏洞數(shù)量本身，發(fā)布階段的時(shí)

長是 DevSecOps 團(tuán)隊(duì)一直關(guān)注的參數(shù)。它通常指測試通

過到成功線上部署之間的時(shí)長，包括各種審批流程的時(shí)

長，安全評審和掃描的時(shí)長，以及生產(chǎn)環(huán)境部署準(zhǔn)備以

及部署本身（采用相關(guān)的部署策略，比如藍(lán)綠部署、金

絲雀部署或者灰度部署等）的時(shí)長。其中安全評審和掃

已選擇 設(shè)計(jì) 待開發(fā) 開發(fā) 待測試 測試 待發(fā)布 發(fā)布

成功發(fā)

布完成

交付周期

開發(fā)周期

發(fā)布前置時(shí)間

29

LECTURE ROOM 百家論道

描往往在整個(gè)部署階段占了很大的比重。

傳統(tǒng)開發(fā)模式中，如果上線前的安全評估和掃描階

段發(fā)現(xiàn)了高危安全漏洞，是一定會(huì)被要求返工給開發(fā)團(tuán)

隊(duì)進(jìn)行修復(fù)才能上線的。開發(fā)團(tuán)隊(duì)修復(fù)安全漏洞后，需

要再次通過整個(gè)研發(fā)流程（構(gòu)建、測試、發(fā)布等）。這個(gè)

過程消耗的時(shí)間則稱為返工時(shí)長，也就是返工消耗的成

本（包括人力成本和資源成本）。由于 DevSecOps 實(shí)現(xiàn)

了安全的左移，使得安全漏洞可以在更早階段發(fā)現(xiàn)并修

復(fù)，因此減少了返工的可能性，并因此節(jié)省了相關(guān)的成

本。另外我們也需要關(guān)心相關(guān)安全事故和事件的工單數(shù)

的減少情況，代表著開發(fā)團(tuán)隊(duì)通過安全左移過程中的培

訓(xùn)，提高了自身的編碼安全能力，從而最終產(chǎn)出更安全

的代碼。

三、實(shí)踐 DevSecOps 度量常見的問題和誤區(qū)

雖然度量在企業(yè)推動(dòng) DevSecOps 過程中擁有巨大

的價(jià)值。然而，在實(shí)踐中，度量有些時(shí)候或者在有些場

景下是比較敏感，并且可能是從上到下都在回避的一件

事。所以，在實(shí)際操作方面，需要考量加入度量指標(biāo)的

時(shí)間點(diǎn)，并且需要考慮哪些度量指標(biāo)更合理，以及使用

方式等。使用錯(cuò)誤的度量（指標(biāo)）或者錯(cuò)誤地使用度量，

不僅起不到驅(qū)動(dòng) DevSecOps 落地讓團(tuán)隊(duì)受益，反而可能

會(huì)起到反向效果，引發(fā)領(lǐng)導(dǎo)或者團(tuán)隊(duì)的不滿意而不愿配

合 DevSecOps 推廣。所以使用 DevSecOps 度量的第一步

是需要先了解 DevSecOps 度量在實(shí)踐過程中常見的問題

和誤區(qū)，從而避免團(tuán)隊(duì)抵制和資源的浪費(fèi)。

首先，針對錯(cuò)誤的度量指標(biāo)，我們可以先從管理者

常常關(guān)注的傳統(tǒng)的用于控制成本的人力度量指標(biāo)入手，

例如資源使用率（如工時(shí)）、代碼行數(shù)、缺陷數(shù)、需求數(shù)

量（故事點(diǎn)數(shù)量）等。最常見的就是以打卡或工時(shí)數(shù)據(jù)

進(jìn)行度量——這是很多管理者最傾向于衡量的指標(biāo)，因

為他們最關(guān)心的可能是手下的人到底是不是在干活和干

了多少活（是不是加班工作了額外的時(shí)間）。然而，工作

時(shí)間長就一定代表著產(chǎn)出高嗎？另一方面，就算額外的

工作量全部是有效并且有產(chǎn)出的，如果只考慮個(gè)人工作

量和產(chǎn)出，在實(shí)際中，當(dāng)局部人力資源過度優(yōu)化，會(huì)造

成大量排隊(duì)、等待以及頻繁的工作任務(wù)切換，看上去很

高的資源利用率不但無法轉(zhuǎn)化成生產(chǎn)力，反而會(huì)傷害端

到端的生產(chǎn)效率。

除了使用錯(cuò)誤的度量指標(biāo)，另一個(gè)問題是錯(cuò)誤地使

用正確的度量指標(biāo)，而這一點(diǎn)卻是更不容易被發(fā)現(xiàn)和經(jīng)

常被忽視的。其中一個(gè)常見的現(xiàn)象就是，同一個(gè)指標(biāo)在

不同業(yè)務(wù)場景下的使用也應(yīng)當(dāng)不同。比如 DevOps 的實(shí)踐

非常推崇開發(fā)過程中的單元測試，也建議將單元測試的

通過率和覆蓋率作為質(zhì)量門禁的度量指標(biāo)之一。然而單

元測試覆蓋率也不是越高越好。首先單元測試覆蓋率越

高，需要的開發(fā)成本越高。另外，對于業(yè)務(wù)變化快的代

碼，單元測試的維護(hù)成本也會(huì)越高。因此，對于單元測

試覆蓋率的具體數(shù)字要求也應(yīng)結(jié)合業(yè)務(wù)和成本來看，單

純的追求數(shù)字沒有任何意義。因此對于單元測試的覆蓋

率，建議逐步進(jìn)行提升，確保每次加入新代碼后，單元

測試覆蓋率不會(huì)下降即可。

四、實(shí)踐中如何正確使用度量

前面我們列舉了一些常見的使用錯(cuò)誤的度量指標(biāo)和

錯(cuò)誤地使用度量所造成的問題。接下來，我們從度量的

各個(gè)方面（比如全局性、可視化、提醒和預(yù)警、度量的

分析、度量門禁等），分析一下如何正確地使用度量，從

而避免之前提到的誤區(qū)和反向效果。

（一）度量不能用來橫向?qū)Ρ葓F(tuán)隊(duì)

首先，度量指標(biāo)的數(shù)據(jù)不能簡單地進(jìn)行跨團(tuán)隊(duì)的橫

向比對，因?yàn)閳F(tuán)隊(duì)之間的業(yè)務(wù)場景不同，沒有可比性。

可以進(jìn)行一定程度地縱向?qū)Ρ龋簿褪呛妥约哼M(jìn)行對

比，對比的是不同時(shí)間段的狀況，從而梳理出團(tuán)隊(duì)改進(jìn)

的情況。當(dāng)然，縱向?qū)Ρ纫灿幸欢ǖ娜毕?，對于研發(fā)效

能已經(jīng)很好的團(tuán)隊(duì)，其改進(jìn)空間也就很小了，因此在同

樣努力的前提下，縱向?qū)Ρ鹊母倪M(jìn)比例很有可能比不上

基礎(chǔ)比較差的團(tuán)隊(duì)的改進(jìn)比例。所以，縱向?qū)Ρ鹊母倪M(jìn)

數(shù)據(jù)需要結(jié)合現(xiàn)狀數(shù)據(jù)一起來看，這樣可以從一個(gè)綜合

的比較公平的視角去跟蹤和評判團(tuán)隊(duì)的研發(fā)效能狀況。

30

百家論道 LECTURE ROOM

（二）度量需要考慮全局

另外度量需要考慮全局的指標(biāo)使用情況，而不能讓

某個(gè)單點(diǎn)度量指標(biāo)給團(tuán)隊(duì)引導(dǎo)錯(cuò)了方向。不能聚焦某階

段的工作輸出指標(biāo)，而需要聚焦整體結(jié)果產(chǎn)出指標(biāo)。這

些指標(biāo)也反映出了研發(fā)效能改進(jìn)的關(guān)鍵點(diǎn)，即以端到端

的流動(dòng)效率（而非資源效率）為核心。流動(dòng)效率是指需

求在整個(gè)流程中跨越不同職能和團(tuán)隊(duì)流動(dòng)的速度，速度

越快則需求交付的效率越高，交付時(shí)長越短。在實(shí)際工

作中，流動(dòng)效率和資源效率需要進(jìn)行協(xié)同優(yōu)化，而不是

簡單地只考慮其中一類。

（三）度量不能作為 KPI

度量指標(biāo)不能與績效掛鉤 , 但是可作為 KPI 的參考

幫助管理者了解現(xiàn)狀，發(fā)現(xiàn)問題和做出判斷。因?yàn)槎攘?/p>

數(shù)據(jù)并不能直接并且 100% 準(zhǔn)確地反映研發(fā)效能對產(chǎn)品

價(jià)值的影響，因此無法進(jìn)行絕對公平的衡量，一旦作為

KPI，就會(huì)容易衍生出為了度量結(jié)果的“數(shù)字游戲”。這

時(shí)，使用度量非但起不到正面效果，還會(huì)對公司和團(tuán)隊(duì)

造成傷害。度量需要作為改進(jìn)機(jī)會(huì)定位的風(fēng)向標(biāo)，確保

團(tuán)隊(duì)能夠一起往正確的方向走，而不是簡單粗暴地作為

懲罰團(tuán)隊(duì)的依據(jù)。

舉個(gè)反面教材的例子：一個(gè)背負(fù)“需求按時(shí)完成率”

的團(tuán)隊(duì)，為了確保需求能按時(shí)完成，估算時(shí)留了盡量多

的 buffer, 另一方面，盡量少做一些需求，按時(shí)完成率

就容易實(shí)現(xiàn)。結(jié)果造成的問題是該研發(fā)團(tuán)隊(duì)只接了團(tuán)隊(duì)

容量 60% 的需求。所以，如果簡單地以需求交付數(shù)量作

為 KPI，甚至將度量作為懲罰性依據(jù)，則團(tuán)隊(duì)有可能為

了數(shù)字和績效，把已經(jīng)比較合理大小的需求有目的性地

再次進(jìn)行拆分成毫無道理的粒度。所謂上有政策，下有

對策，當(dāng)團(tuán)隊(duì)放棄以改進(jìn)為目標(biāo)，而僅僅是為了以完成

任務(wù)免受懲罰為目的，就會(huì)以游戲，規(guī)避或者利己的心

態(tài)對待度量，從而使得很多度量指標(biāo)被用非預(yù)期的方式

完成了。

（四）度量需要可視化

為了讓度量足夠引起重視進(jìn)而影響人的意識從而

改變團(tuán)隊(duì)或者企業(yè)文化，度量的可視化是非常必要的手

段。關(guān)鍵的度量數(shù)據(jù)可以展示在公共區(qū)域，或者人流密

集大（比如公司入口的門廳、團(tuán)隊(duì)旁邊等地點(diǎn)）或者比

較顯眼的區(qū)域的大型顯示屏或者投影上。展示的度量數(shù)

據(jù)需要和相關(guān)的團(tuán)隊(duì)甚至個(gè)人相關(guān)聯(lián)一同展示。另外，

作為管理者，要經(jīng)常關(guān)注大屏幕上和自己團(tuán)隊(duì)相關(guān)的信

息，對異常的度量數(shù)據(jù)提出質(zhì)疑，并讓相關(guān)團(tuán)隊(duì)或者人

員及時(shí)進(jìn)行解決。另外，設(shè)置一定的激勵(lì)機(jī)制配合度量

結(jié)果也能起到一定的積極作用。很多實(shí)踐證明，度量的

可視化是改變個(gè)人意識，以及團(tuán)隊(duì)或公司文化的有效手

段之一。通過這種潛移默化的影響，逐漸讓團(tuán)隊(duì)開始通

過度量指標(biāo)關(guān)注研發(fā)效能，尤其是過程效能。

（五）度量需要提醒和預(yù)警機(jī)制配合使用

除了可視化，相關(guān)的提醒和預(yù)警機(jī)制也可以配合

度量一起使用，保證度量發(fā)現(xiàn)的問題可以及時(shí)和按時(shí)解

決。提醒和預(yù)警的方法和手段可以通過郵件、電話、短

信、微信等方式。提醒機(jī)制也可以歸類為度量可視化的

一種，比如通過每天微信群的模板，列出團(tuán)隊(duì)每個(gè)人的

任務(wù)進(jìn)度的狀態(tài)，以及研發(fā)過程中各種指標(biāo)的情況（代

碼質(zhì)量、單元測試覆蓋率等），通過每天在微信群進(jìn)行通

知并公開個(gè)人對應(yīng)的度量指標(biāo)，促使團(tuán)隊(duì)積極完成任務(wù)

和及時(shí)改進(jìn)。

（六）分析度量數(shù)據(jù)

再有，前面提到過，度量驅(qū)動(dòng)的目的包括幫助團(tuán)隊(duì)

發(fā)現(xiàn)過程中的瓶頸和評估改進(jìn)的結(jié)果。因此需要對度量

數(shù)據(jù)進(jìn)行分析，發(fā)現(xiàn)最有價(jià)值的信息，如趨勢、上下文

信息等，進(jìn)而幫助團(tuán)隊(duì)發(fā)現(xiàn)深層次的問題并為解決方案

提供實(shí)驗(yàn)數(shù)據(jù)，并且由此進(jìn)行改進(jìn)。比如，如果測試階

段發(fā)現(xiàn)的缺陷數(shù)量過多，耗費(fèi)了大量的測試資源，就要

分析缺陷的分類和數(shù)量，判斷是否左移簡單的測試工作

給開發(fā)（單元測試和冒煙測試）可以提高測試效率，從

而節(jié)省測試成本。那么，如何進(jìn)行度量分析呢？

首先是通過抓需求梳理整個(gè)研發(fā)過程，因?yàn)樾枨笫?/p>

貫穿研發(fā)交付過程始終的，沒有之一。另外需要驗(yàn)證數(shù)

31

LECTURE ROOM 百家論道

據(jù)的真實(shí)有效性，才能讓團(tuán)隊(duì)認(rèn)可這個(gè)客觀數(shù)據(jù)。接下

來，對大的階段進(jìn)行拆分，保證數(shù)字的合理性，比如拆

解測試周期。通過把表面問題細(xì)分到各個(gè)步驟的實(shí)際情

況下，才能搞清楚到底是哪個(gè)步驟導(dǎo)致的問題。最后根

據(jù)不同的視角和維度劃分指標(biāo)，比如劃分組織級指標(biāo)、

團(tuán)隊(duì)級指標(biāo)和項(xiàng)目級指標(biāo)。劃分指標(biāo)的核心由大到小，

從指標(biāo)受眾和試圖解決的問題出發(fā)，進(jìn)行層層拆解，從

而直達(dá)問題的根本原因。

（七）基于度量的質(zhì)量門禁

除了通過自動(dòng)化方式持續(xù)獲得軟件交付各個(gè)階段所

產(chǎn)生的數(shù)據(jù)外，某些關(guān)鍵度量指標(biāo)可以作為質(zhì)量門禁，

集成在流水線上作為質(zhì)量和安全的把控，保證產(chǎn)品質(zhì)量

和安全，并且避免技術(shù)負(fù)債。比如高危安全漏洞、嚴(yán)重

缺陷、嚴(yán)重代碼質(zhì)量問題、單元測試通過率和覆蓋率、

接口測試通過率等。如果結(jié)果不滿足質(zhì)量門禁指標(biāo)的要

求，比如高危安全漏洞數(shù)大于零，則強(qiáng)制流水線構(gòu)建失

敗，分支不能進(jìn)行合并或者測試結(jié)果不達(dá)標(biāo)等方式阻止

流程繼續(xù)執(zhí)行。

（八）監(jiān)控度量數(shù)據(jù)

關(guān)于應(yīng)用運(yùn)維端的度量，尤其是監(jiān)控度量數(shù)據(jù)可以

在三個(gè)層面進(jìn)行分類和可視化：業(yè)務(wù)指標(biāo)、應(yīng)用指標(biāo)和

基礎(chǔ)設(shè)施指標(biāo)。數(shù)據(jù)分層的方法讓度量更加結(jié)構(gòu)化，方

便業(yè)務(wù)和開發(fā)人員理解和分析。業(yè)務(wù)指標(biāo)可以檢查當(dāng)前

的狀態(tài)是否符合要求的 SLA，使用趨勢或收入。應(yīng)用指

標(biāo)可以檢查應(yīng)用組件的性能，不同服務(wù)執(zhí)行的延遲及數(shù)

據(jù)增長等。而基礎(chǔ)設(shè)施指標(biāo)可以檢查最底層的 CPU、內(nèi)

存、硬盤和 I/O使用率的情況。要找出問題的根本原因，

需要把不同的指標(biāo)關(guān)聯(lián)起來。比如可以把關(guān)鍵指標(biāo)的度

量數(shù)據(jù)圖疊加起來，從上而下依次是業(yè)務(wù)、應(yīng)用和基礎(chǔ)

設(shè)施指標(biāo)。分析時(shí)比如從上往下看時(shí)，可以看到 QPS 的

變化是如何影響應(yīng)用性能和服務(wù)器 CPU的。從下往上時(shí)，

可以看出 I/O 的變化是如何影響 SLA。

最后，度量只是工具和手段，不是目的。度量的真

正目標(biāo)是提高效能，因此不要舍本逐末。舉個(gè)例子，如

果花費(fèi)在度量精準(zhǔn)度上的時(shí)間超過了收益，那就不要浪

費(fèi)太多人力物力去做得那么精準(zhǔn)了，可以換個(gè)方法從多

維角度綜合參考不同地度量指標(biāo)數(shù)據(jù)。另外，雖然我們

推崇量化和數(shù)字驅(qū)動(dòng)，但在效能的度量上，不能過于迷

信數(shù)字，更不能一刀切式地使用度量，很多時(shí)候還是要

結(jié)合場景具體情況具體分析。

32

百家論道 LECTURE ROOM

OWASP 中國 S-SDLC CMM

項(xiàng)目介紹

S-SDLC CMM 項(xiàng)目主理人、

SDL 咨詢師、S-SDLC CMM 模型主

導(dǎo)者。具有超過十五年的軟件安

全從業(yè)經(jīng)驗(yàn)，熟悉安全需求分析、

安全架構(gòu)設(shè)計(jì)、安全編碼等開發(fā)

生命周期中的安全活動(dòng)，對企業(yè)

級的安全開發(fā)體系構(gòu)建、落地與

實(shí)施具有豐富的實(shí)踐經(jīng)驗(yàn)。主導(dǎo)

參與了超過 20 家企業(yè)的 SDL 咨

詢項(xiàng)目。在開源項(xiàng)目方面，曾主

導(dǎo)《源碼工具審核基準(zhǔn)》的研制

工作，并參與了《OWASP 安全測

試指南（第 4 版）》、《OWASP

代碼審核》等書籍的譯制與出版

工作。

徐瑞祝

一、創(chuàng)建 OWASP S-SDLC CMM 項(xiàng)目的背景

從團(tuán)隊(duì)成員收集的企業(yè)訴求來看，主要體現(xiàn)在幾個(gè)方面：一是評估不足，

組織絕大多數(shù)情況無法客觀評價(jià)自身的安全能力水平，對自身的安全開發(fā)能力

不夠清楚；二是無法落地，組織的安全實(shí)踐缺少經(jīng)驗(yàn)，且多數(shù)情況下缺乏明確

的安全細(xì)則和要求，無法提供很好的落地指導(dǎo)；三是缺乏規(guī)劃，組織內(nèi)部對安

全不夠重視，甚至不做安全規(guī)劃，導(dǎo)致安全開發(fā)管理體系缺乏系統(tǒng)性規(guī)劃。

這是我們做軟件能力成熟度評估模型的背景，對于該模型的應(yīng)用，乙方公

司可以用來做差距分析，企業(yè)也可以用來做自評估與構(gòu)建安全開發(fā)體系的參考。

二、S-SDLC CMM 模型介紹

S-SDLC CMM 模型是一種“指導(dǎo)式”的軟件安全開發(fā)能力成熟度評估模型。

當(dāng)前業(yè)界也有一些“觀察式”的模型，比如說統(tǒng)計(jì)一些規(guī)模較大的甲方

企業(yè)的最佳實(shí)踐，將其羅列出來并分類，告訴企業(yè)哪些階段有哪些活動(dòng)值得去

做。但這種形式會(huì)有幾個(gè)問題，因?yàn)椴⒉皇敲總€(gè)企業(yè)都適合這些活動(dòng)，而且不

知道這些活動(dòng)要做到什么程度，這樣在實(shí)踐時(shí)會(huì)給企業(yè)帶來困惑，因此我們希

望提供一種“指導(dǎo)式”模型，可以按照最佳實(shí)踐的角度去開展安全開發(fā)體系的

建設(shè)。

（一）模型概述及結(jié)構(gòu)

S-SDLC CMM 模型完整定義了標(biāo)準(zhǔn)的軟件安全開發(fā)流程和安全實(shí)踐，從組織

的安全基礎(chǔ)設(shè)施、安全技術(shù)能力和活動(dòng)標(biāo)準(zhǔn)、軟件開發(fā)全生命周期安全活動(dòng)執(zhí)

行、軟件上線后運(yùn)維安全，共計(jì) 4 個(gè)維度評價(jià)組織的安全能力水平。

1、監(jiān)管：包括制定軟件安全戰(zhàn)略，以及配套安全流程、合規(guī)政策和安全培

訓(xùn)方面的實(shí)踐；

2、能力：包括攻擊模型研究、安全知識庫建設(shè)以及安全活動(dòng)標(biāo)準(zhǔn)建設(shè)方面

的實(shí)踐；

今天給大家介紹最近我們在 OWASP 中國發(fā)布的 S-SDLC CMM 軟件能力成熟

度評估模型的項(xiàng)目，當(dāng)時(shí)主導(dǎo)該項(xiàng)目的初衷，是因?yàn)槲覀儓F(tuán)隊(duì)在工作中看到了

很多國內(nèi)企業(yè)在軟件安全能力成熟度評估以及安全開發(fā)體系建設(shè)上的訴求與痛

點(diǎn)，我們希望該項(xiàng)目可以幫助企業(yè)解決他們的問題。接下來，我會(huì)從 S-SDLC

CMM 項(xiàng)目的背景、S-SDLC CMM 模型介紹與 S-SDLC CMM 開源項(xiàng)目介紹這三個(gè)方面

來展開分享。

33

LECTURE ROOM 百家論道

3、觸點(diǎn)：涵蓋需求、設(shè)計(jì)、實(shí)現(xiàn)和測試等階段的安

全活動(dòng)實(shí)踐；

4、運(yùn)維：包括滲透測試、軟件環(huán)境安全、運(yùn)營支持

以及應(yīng)急響應(yīng)相關(guān)的實(shí)踐。

模型通過劃分安全域→安全子域→安全實(shí)踐的三層

結(jié)構(gòu)，將安全能力細(xì)化至可客觀量化的執(zhí)行動(dòng)作，由此

得出安全實(shí)踐客觀的執(zhí)行水平，完成對組織安全能力成

熟度的評估。

（二）成熟度級別

S-SDLC CMM 定義了 5 個(gè)成熟度級別以表示 S-SDLC

評估子域和組織能力成熟度：

1、隨機(jī)、被動(dòng)的安全開發(fā)過程：

第 1 級，S-SDLC 子域內(nèi)少部分的安全實(shí)踐通常會(huì)被

執(zhí)行。但實(shí)踐的執(zhí)行可能未經(jīng)嚴(yán)格的計(jì)劃和跟蹤，而是

基于個(gè)人的知識和努力。同時(shí)，該安全能力并未完全內(nèi)

化到組織內(nèi)。

2、主動(dòng)、非正式的安全開發(fā)過程：

第 2 級，S-SDLC 子域內(nèi)安全實(shí)踐執(zhí)行是經(jīng)計(jì)劃并被

跟蹤的。同時(shí)，組織通過對安全實(shí)踐進(jìn)行測量來跟蹤執(zhí)

行情況并保持對安全活動(dòng)的管理。

3、正式、規(guī)范的安全開發(fā)過程：

第 3 級，S-SDLC 子域內(nèi)的安全實(shí)踐按照充分定義

的過程執(zhí)行。充分定義是指軟件安全開發(fā)流程實(shí)踐有標(biāo)

準(zhǔn)化、文檔化的管理流程或經(jīng)過裁剪并得到批準(zhǔn)的一部

分。這一過程與第 2 級（計(jì)劃跟蹤級）的主要區(qū)別在于

安全實(shí)踐的管理過程是組織級標(biāo)準(zhǔn)化、文檔化的。

4、可量化控制的安全開發(fā)過程：

第 4 級，S-SDLC 子域內(nèi)的安全實(shí)踐經(jīng)過組織級地

收集、分析和執(zhí)行詳細(xì)的測量活動(dòng)，使組織獲得對軟件

安全開發(fā)流程的量化理解和預(yù)測后續(xù)執(zhí)行情況的能力。

這個(gè)級別執(zhí)行的管理是客觀的，安全管理的質(zhì)量是量化

的。這一級與第 3 級（充分定義級）的主要區(qū)別在于對

安全實(shí)踐管理的定量理解和控制。

5、安全過程可持續(xù)優(yōu)化，建立業(yè)界標(biāo)桿：

第 5 級，S-SDLC 子域內(nèi)的安全實(shí)踐會(huì)基于組織長久

的業(yè)務(wù)目標(biāo)建立一個(gè)針對過程有效性和執(zhí)行效率的量化

目標(biāo)，并圍繞這一目標(biāo)進(jìn)行持續(xù)改進(jìn)。這一級與第 4 級

（量化管理級）的主要區(qū)別在于組織存在持續(xù)的優(yōu)化過

程。同時(shí)，由于安全管理過程是持續(xù)優(yōu)化的，組織會(huì)實(shí)

時(shí)向行業(yè)輸出安全實(shí)踐和安全能力，形成組織對行業(yè)的

輻射和對外的影響力。

（三）量化維度

關(guān)于子域能力成熟度，S-SDLC CMM 定義了 3 個(gè)成熟

度級別以表示 S-SDLC 評估子域和組織能力成熟度：

1、頻率：包含實(shí)踐本身的發(fā)生頻率、升級頻率、更

新頻率等。如：“對高管進(jìn)行安全意識培訓(xùn)”實(shí)踐下對高

管參加培訓(xùn)的頻率有客觀的量化要求；

2、覆蓋度：指活動(dòng)發(fā)生時(shí)覆蓋的情況。如：“對技

術(shù)人員提供安全技能培訓(xùn)”實(shí)踐下對“安全技能課程覆

蓋的項(xiàng)目組成員比例”提出了要求，包括開發(fā)、測試、

產(chǎn)品、項(xiàng)目經(jīng)理等參與技能培訓(xùn)的人員占比項(xiàng)目組全部

人員的比例；

3、執(zhí)行質(zhì)量：指企業(yè)實(shí)踐執(zhí)行的質(zhì)量如何，一般從

活動(dòng)的角色、職責(zé)、流程、輸入輸出等方面評判。如：

“識別可能存在的潛在攻擊者”評價(jià)質(zhì)量時(shí)，會(huì)針對攻

擊者的識別是否從不同的角度和側(cè)面進(jìn)行識別，包括企

業(yè)外側(cè)和內(nèi)測、系統(tǒng)的業(yè)務(wù)側(cè)和數(shù)據(jù)側(cè)等，評價(jià)是否識

別得完善和系統(tǒng)。

（四）安全域

安全域有四個(gè)大域：監(jiān)管域、能力域、觸點(diǎn)域、運(yùn)

維域。

1、監(jiān)管域

包括制定軟件安全戰(zhàn)略，以及配套安全流程、合規(guī)

政策和安全培訓(xùn)制度以及供應(yīng)鏈管理制度。

（1）流程與政策：主要評估組織對安全戰(zhàn)略目標(biāo)制

定、運(yùn)營和量化管理的能力。包含建立統(tǒng)一的軟件安全

戰(zhàn)略、制定組織安全開發(fā)管理流程、建設(shè)和運(yùn)營組織安

全文化、建立組織級別 SDL 量化管理體系共計(jì) 4 個(gè)方面

的實(shí)踐。

（2）合規(guī)性：主要評估軟件開發(fā)組織對于監(jiān)管規(guī)則

的重視度，含合規(guī)性法律文件轉(zhuǎn)化為安全需求這樣的安

全實(shí)踐。

（3）培訓(xùn)：安全知識的培訓(xùn)對于組織中的每一個(gè)人

都是至關(guān)重要的，這是做好相關(guān)實(shí)踐活動(dòng)的前提?！芭嘤?xùn)”

34

百家論道 LECTURE ROOM

的子域主要評估了組織對各崗位是否提供了符合崗位要求

的軟件安全培訓(xùn)內(nèi)容，以及評估了培訓(xùn)內(nèi)容的有效性。

（4）供應(yīng)鏈安全管理：主要是幫助企業(yè)建立正式的

制度來管理軟件供應(yīng)鏈的安全風(fēng)險(xiǎn)，該子域下面主要包

括成立軟件供應(yīng)鏈安全風(fēng)險(xiǎn)管理委員會(huì)和建立正式的軟

件供應(yīng)鏈安全管理制度兩個(gè)子實(shí)踐。

2、能力域

該域描述了組織在軟件安全開發(fā)全生命周期中的各

種安全活動(dòng)的基礎(chǔ)設(shè)置支持能力，包括攻擊模型研究、

安全知識庫、安全組件、安全工具鏈。

（1）攻擊模型：從攻擊者的視角分析和研究可能存

在的攻擊者、攻擊模式和相關(guān)技術(shù)，以便軟件開發(fā)組織

能夠防患于未然。該子域下包括識別可能存在的攻擊者、

建立攻擊模型和技術(shù)知識庫、構(gòu)建攻擊團(tuán)隊(duì) 3個(gè)子實(shí)踐。

（2）安全設(shè)計(jì)方案與安全開發(fā)組件：評估軟件開發(fā)

組織構(gòu)建支持安全開發(fā)、安全設(shè)計(jì)和威脅分析方面的技

術(shù)知識庫及開發(fā)組件的能力。

（3）第三方組件庫管理：軟件系統(tǒng)的開發(fā)會(huì)用到大

量的開源組件，不少軟件開發(fā)組織在第三方組件庫的管

理方面，都存在流程不完善，安全管控不足的情況，嚴(yán)

重影響了軟件系統(tǒng)的安全性。因此，有必要建立內(nèi)部第

三方組件庫，并對組件的選擇、下載、安裝和更新進(jìn)行

規(guī)范管理。

（4）標(biāo)準(zhǔn)與要求：為把控 S-SDLC 流程的整體質(zhì)量，

需要對其中的安全活動(dòng)建立相關(guān)的標(biāo)準(zhǔn)和要求，即安全

基線、安全編碼規(guī)范以及代碼審計(jì)等。

（5）敏感數(shù)據(jù)處理：黑客的攻擊，甚至內(nèi)部工作人

員的信息販賣、離職員工的信息泄露、第三方外包人員

的交易行為、數(shù)據(jù)共享第三方的數(shù)據(jù)泄露、開發(fā)測試人

員的違規(guī)等都可能導(dǎo)致敏感數(shù)據(jù)泄露，因此有必要對敏

感數(shù)據(jù)予以識別，并在傳輸和存儲過程中進(jìn)行加密處理。

3、觸點(diǎn)域

涵蓋了需求、設(shè)計(jì)、實(shí)現(xiàn)和測試等階段安全活動(dòng)相

關(guān)的實(shí)踐，其可以評價(jià)企業(yè)軟件系統(tǒng)開發(fā)中安全活動(dòng)的

落實(shí)情況。

（1）安全需求分析：需求分析階段完成系統(tǒng)功能的

安全需求分析，識別可能面臨的安全風(fēng)險(xiǎn)，并將安全需

求加入需求說明書里。軟件安全需求分析是軟件需求分

析的一個(gè)必要組成部分。安全需求與業(yè)務(wù)需求同樣重要，

并能對功能需求具有約束力。

（2）安全設(shè)計(jì)：安全設(shè)計(jì)活動(dòng)，包括在架構(gòu)設(shè)計(jì)時(shí)

考慮系統(tǒng)的安全性，對系統(tǒng)進(jìn)行威脅分析，評估系統(tǒng)面

臨的風(fēng)險(xiǎn)，對設(shè)計(jì)方案進(jìn)行安全檢查和評審。

（3）安全實(shí)現(xiàn)：安全開發(fā)階段包括對代碼和第三方組

件進(jìn)行人工和自動(dòng)化的審核，落實(shí)安全編碼規(guī)范的實(shí)施。

（4）安全測試：主要是為了驗(yàn)證安全需求分析階段

識別的安全需求是否得到正確實(shí)現(xiàn)，通過設(shè)計(jì)安全測試

用例、執(zhí)行安全測試用例以及對發(fā)現(xiàn)的安全漏洞進(jìn)行跟

蹤管理的方式，以確保軟件系統(tǒng)的安全性。安全測試的

執(zhí)行可以使用人工與工具結(jié)合的方式進(jìn)行。

4、運(yùn)維域

包括滲透測試、軟件環(huán)境安全、運(yùn)營支持以及應(yīng)急

響應(yīng)相關(guān)的實(shí)踐，可以評價(jià)企業(yè)在軟件系統(tǒng)運(yùn)維中安全

活動(dòng)的落實(shí)情況。

（1）滲透測試：是對軟件系統(tǒng)進(jìn)行滲透測試?？尚?/p>

賴的第三方通過模擬真實(shí)黑客攻擊的技術(shù)及手段對目標(biāo)

網(wǎng)站、服務(wù)器系統(tǒng)進(jìn)行攻擊，在發(fā)現(xiàn)目標(biāo)存在安全隱患

后給出專業(yè)的安全加固建議。

（2）軟件環(huán)境：主要是遵循“默認(rèn)安全”的設(shè)計(jì)理

念來保證軟件環(huán)境安全。

（3）運(yùn)營支持：有效的運(yùn)營支持可以規(guī)范軟件開發(fā)

組織的安全運(yùn)營行為，降低系統(tǒng)受攻擊的概率，提升安

全事件的應(yīng)對效率，保障軟件程序的安全運(yùn)行。

（4）應(yīng)急響應(yīng)：為了有效地對安全事件的發(fā)生做出

及時(shí)的處置，軟件開發(fā)組織應(yīng)組建相關(guān)的應(yīng)急響應(yīng)團(tuán)隊(duì)

以及制定信息安全事件的應(yīng)急預(yù)案，這樣軟件開發(fā)組織

在安全事故發(fā)生時(shí)也能做到有人可用，有章可循。

三、S-SDLC CMM 開源項(xiàng)目介紹

關(guān)于 S-SDLC CMM 開源項(xiàng)目，我們制作了一個(gè)網(wǎng)站

http://s-sdlccmm.com/，網(wǎng)站上有三大模塊，分別是

S-SDLC CMM模型介紹、安全技術(shù)資訊和安全能力自我評測。

模型介紹詳細(xì)描述了安全域 - 安全子域 - 安全實(shí)踐

的層級結(jié)構(gòu)關(guān)系，并且該模塊功能支持下載 S-SDLC CMM

文檔至您的本地進(jìn)行參考閱讀。安全技術(shù)資訊信息主要

以行業(yè)、技術(shù)和業(yè)界新的安全實(shí)踐為主，通過有深度的

技術(shù)好文分享，引導(dǎo)讀者思考安全技術(shù)的新走向。安全

能力的自我評測功能主要為用戶提供一個(gè)簡易的自我評

測工具，用于自身安全能力的評估，通過問卷形式模擬

差距分析過程得出安全能力水平和安全能力雷達(dá)圖。

由于前期的團(tuán)隊(duì)成員相對有限，所以我們希望諸位

有志之士可以積極參與到該項(xiàng)目中，對該模型提出寶貴

的意見，共同完善并推動(dòng)該項(xiàng)目的進(jìn)展。

35

LECTURE ROOM 百家論道

軟件安全研發(fā)建設(shè)之路

每個(gè)公司的實(shí)際情況不同，所擁有的資源以及面臨的業(yè)務(wù)場景也不一樣，

所以解決方案也會(huì)有一定的差異。本文分享一些軟件安全研發(fā)的經(jīng)驗(yàn)，希望可

以給各位讀者帶來一些幫助和啟發(fā)。

一、軟件安全研發(fā)流程實(shí)踐

軟件安全研發(fā)流程的設(shè)計(jì)，首先需要定義幾個(gè)關(guān)鍵角色，分別是：安全團(tuán)

隊(duì)、產(chǎn)品安全負(fù)責(zé)人和常規(guī)測試團(tuán)隊(duì)的安全測試人員。

安全團(tuán)隊(duì)，以我們團(tuán)隊(duì)為例，除了合規(guī)相關(guān)的工作較少（主要總部在負(fù)

責(zé)），其他與軟件安全相關(guān)的工作都要做，包括滲透測試、安全設(shè)計(jì)流程、安全

技術(shù)培訓(xùn)、安全技術(shù)積累、安全運(yùn)營、安全事件調(diào)查等等。

產(chǎn)品安全負(fù)責(zé)人，主要的責(zé)任是把控產(chǎn)品迭代過程中和安全相關(guān)的工作，

保證執(zhí)行到位。然后要確保安全部門的培訓(xùn)、任務(wù)、信息能有效傳達(dá)到產(chǎn)品團(tuán)隊(duì)。

常規(guī)測試團(tuán)隊(duì)的安全測試人員，由于公司產(chǎn)品較多，安全部門資源又有

限，所以由常規(guī)測試人員來學(xué)習(xí)滲透測試和漏洞掃描，可以緩解很大一部分工作

壓力。經(jīng)過實(shí)踐，測試團(tuán)隊(duì)可以勝任簡單的滲透測試的工作。我們的做法是，首

先由安全團(tuán)隊(duì)來培訓(xùn)測試團(tuán)隊(duì)基礎(chǔ)的測試步驟，比如如何測試權(quán)限、如何測試前

后臺的參數(shù)驗(yàn)證等，然后寫成測試案例，交給測試團(tuán)隊(duì)執(zhí)行基本的滲透測試。這

樣可以大大節(jié)省安全團(tuán)隊(duì)的資源，也可以對提高應(yīng)用安全起到很大的作用。

（一）產(chǎn)品迭代中的安全工作

在產(chǎn)品迭代過程中，要做的任務(wù)包括安全設(shè)計(jì)流程、靜態(tài)代碼分析、軟件

組成分析、容器鏡像掃描、主機(jī)漏洞掃描及安全加固、動(dòng)態(tài)應(yīng)用安全測試、常

規(guī)測試人員測試基本安全測試用例、上線等。

眾所周知，從研發(fā)、測試、發(fā)布到運(yùn)營的不同階段，漏洞修復(fù)成本是成倍

增長的，所以現(xiàn)在軟件安全行業(yè)特別推崇“安全左移”，以期能夠盡早發(fā)現(xiàn)問

題，并降低修復(fù)成本。然而很多企業(yè)的“安全左移”就是“IDE+ 靜態(tài)代碼分析

插件”，但其實(shí)兩者并不等同，雖然“IDE+ 靜態(tài)代碼分析插件”確實(shí)能發(fā)現(xiàn)一些

問題，但也僅局限于靜態(tài)代碼分析能發(fā)現(xiàn)的問題，而像業(yè)務(wù)邏輯問題或權(quán)限問

題是無法被發(fā)現(xiàn)的，所以要做到“安全左移”，需要從設(shè)計(jì)階段就考慮安全。

（二）安全設(shè)計(jì)流程

當(dāng)然理論上修改任何代碼都可能帶來安全問題，然而評估任何代碼改動(dòng)是

否會(huì)引起安全問題顯然是不切實(shí)際的，所以我們制定了這個(gè)安全設(shè)計(jì)流程。

OWASP 中國吉林區(qū)域負(fù)

責(zé)人，某外企安全部門負(fù)責(zé)

人，資深研發(fā)工程師。擁有

11 年軟件安全和軟件研發(fā)經(jīng)

驗(yàn)，軟件公司安全研發(fā)流程

和安全團(tuán)隊(duì)從 0 到 1 的建設(shè)

經(jīng)驗(yàn)。

郭振新

36

百家論道 LECTURE ROOM

如上圖所示，是我們設(shè)計(jì)的一套安全設(shè)計(jì)流程。迭

代剛開始，產(chǎn)品安全負(fù)責(zé)人需要檢查本次迭代和安全相

關(guān)的一些功能，然后把這些功能挑出來，通過郵件發(fā)給

安全部門，審核該功能是否和安全相關(guān)，是否需要安全

設(shè)計(jì)文檔。關(guān)于安全設(shè)計(jì)文檔，有一點(diǎn)需要說明，并不

是所有的功能都需要安全設(shè)計(jì)文檔，比如需要在頁面上

加一個(gè)富文本編輯器，很顯然這個(gè)功能不需要寫文檔去

說明開發(fā)的用處，只需要告知這個(gè)功能，由安全部門確

認(rèn)之后，再郵件告知產(chǎn)品安全負(fù)責(zé)人哪些功能與安全相

關(guān)并且是否需要安全文檔來解釋該功能的作用。

安全負(fù)責(zé)人收到郵件之后，針對每個(gè)功能會(huì)創(chuàng)建安

全審核 Jira，然后在開發(fā)之前確認(rèn)是否需要安全設(shè)計(jì)文

檔，如果需要?jiǎng)t進(jìn)行文檔審核以及信息提供，然后進(jìn)行

開發(fā)，如果不需要?jiǎng)t直接開發(fā)即可。開發(fā)完成之后，開

始滲透測試。在滲透測試這塊也有一個(gè)分流，比如說開

發(fā)修改了權(quán)限模型，滲透測試的工作量會(huì)非常大，因?yàn)?/p>

每個(gè) API 或每個(gè)頁面可能都需要測試，這時(shí)就需要常規(guī)

測試人員的幫助。

做這套流程主要有兩個(gè)目的：第一，優(yōu)先挑選重要

的和安全相關(guān)的功能和邏輯，這樣就可以做安全設(shè)計(jì)流

程，讓開發(fā)人員提供文檔，尤其在開發(fā)人員寫代碼之前

注意可能存在的問題。第二，即使不寫安全設(shè)計(jì)文檔，

也可以把較大可能產(chǎn)生漏洞的功能列出來，知道哪些產(chǎn)

品添加了哪些功能，這些功能是否更容易出現(xiàn)問題，是

否需要滲透測試。

開始推動(dòng)這套流程時(shí)，我們發(fā)現(xiàn)產(chǎn)品安全負(fù)責(zé)人的

安全意識不足，挑不出哪些功能與安全相關(guān)。所以最初的

執(zhí)行是由安全部門去挑重點(diǎn)的產(chǎn)品和功能，執(zhí)行了兩三個(gè)

迭代之后再給產(chǎn)品安全負(fù)責(zé)人進(jìn)行培訓(xùn)，告知哪些功能與

安全相關(guān)。結(jié)合之前的數(shù)據(jù)，產(chǎn)品安全負(fù)責(zé)人就可以參考

這些數(shù)據(jù)在之后的工作中去挑選負(fù)責(zé)的產(chǎn)品是否有與安全

相關(guān)的功能。經(jīng)過不斷的積累，產(chǎn)品安全負(fù)責(zé)人的安全意

識逐步提升上來，就可以獨(dú)立負(fù)責(zé)相關(guān)的工作。

二、軟件安全研發(fā)工具

（一）威脅建模

Microsoft Threat Modeling Tool 是一款免費(fèi)建

模工具，可以針對當(dāng)前的架構(gòu)圖評估可能面臨的安全問

題，以及對應(yīng)的設(shè)計(jì)建議和緩解措施，同時(shí)該工具可以

很好的降低威脅建模的門檻。

前面說的安全設(shè)計(jì)流程的安全設(shè)計(jì)文檔，只要開發(fā)

人員能把整個(gè)業(yè)務(wù)邏輯體現(xiàn)出來即可，說明其中可能存

在的問題以及對應(yīng)的預(yù)防方法，但開發(fā)人員有時(shí)不一定

能完全在文檔中體現(xiàn)，我們在審核文檔時(shí)也會(huì)跟開發(fā)溝

通，當(dāng)前業(yè)務(wù)邏輯場景下可能發(fā)生的問題，然后跟他一

（圖一 安全設(shè)計(jì)流程圖）

37

LECTURE ROOM 百家論道

起把這些問題都加到文檔里，這樣讓開發(fā)在實(shí)現(xiàn)該功能

之前可以了解可能會(huì)存在的問題。

（二）靜態(tài)代碼分析（SAST）

我們使用的是 SonarQube 開源的靜態(tài)代碼分析工具，

可以分析漏洞、代碼質(zhì)量、潛在的Bug以及代碼重復(fù)率等。

使用該工具的方式是將它集成到 GitLab 的 CI/CD 流

程中，每天掃描一次。掃描完后，如果有問題就會(huì)給對

應(yīng)的開發(fā)人員發(fā)郵件，通知他有新的問題需要修改。

（三）軟件組成分析（SCA）

在當(dāng)前網(wǎng)絡(luò)環(huán)境下，供應(yīng)鏈攻擊是我們需要面對的

重大挑戰(zhàn)，比如像 Log4j 這種級別的漏洞肯定是越早發(fā)

現(xiàn)越好，而且使用不安全的組件，一直都是 OWASP Top

10 中的一個(gè)重要威脅。

我 們 使 用 的 工 具 是 OWASP 的 開 源 工 具 OWASP

Dependency-Check，可以用于識別依賴項(xiàng)，并且檢查依

賴項(xiàng)中是否存在公開披露的漏洞。執(zhí)行原理就是把幾個(gè)

漏洞數(shù)據(jù)庫下載下來，和代碼組件進(jìn)行匹配。

使 用 方 法 是 把 它 集 成 到 SonarQube 中， 同 時(shí) 在

SonarQube 的 GitLab 的 CI/CD 流程中添加 DependencyCheck，每天掃描一次。有問題會(huì)通過郵件形式通知開發(fā)

人員修改，結(jié)果可以顯示在 SonarQube 中。

（四）容器鏡像掃描

我們使用的是 Trivy，可以掃描的內(nèi)容很多，包括

掃描鏡像中操作系統(tǒng)軟件包、應(yīng)用程序依賴項(xiàng)、軟件的

許可證以及配置文件中的安全問題。該工具使用很方便，

而且結(jié)果精確。

使用方式是把它集成到 GitLab 的 CI/CD 流程中，每

次打包都會(huì)掃描。另外也做了一些額外的集成，有問題

可以自動(dòng)的創(chuàng)建 Jira 跟蹤，開發(fā)人員看到 Jira 就會(huì)去

解決問題。

（五）動(dòng)態(tài)應(yīng)用安全測試（DAST）

DAST 基本上是每個(gè)做安全的企業(yè)首先要做的事，

我們使用過三款 DAST 工具，分別是 Acunetix(AWVS)、

Burp Suite Professional 和 OWASP ZAP，經(jīng)過對比其結(jié)

果也是大同小異。

針對 DAST 比較重要的兩點(diǎn)是，第一是掃描時(shí)要保持

登錄狀態(tài)，因?yàn)楝F(xiàn)在做的應(yīng)用程序基本都需要登錄，登

錄之后才能使用里面的功能，所以沒有一個(gè)登錄腳本，

是不可能掃描到登錄后的頁面的。第二點(diǎn)是對于整個(gè)網(wǎng)

站是否掃描足夠全面，也就是爬網(wǎng)邏輯。關(guān)于這兩點(diǎn)，

這三款工具都沒有很完美，因?yàn)槊總€(gè)產(chǎn)品用的前端技術(shù)

都不太一樣，所以對于這種網(wǎng)站的掃描總是差強(qiáng)人意。

我們的做法是讓測試人員把要測試的功能先清點(diǎn)一

遍，把收集來的請求導(dǎo)入到工具中再進(jìn)行掃描。但局限

于上面描述的兩點(diǎn)，沒有辦法將 DAST 集成到 CI/CD 流程

中，所以我們是讓測試人員手動(dòng)來掃描。

（六）服務(wù)器漏洞掃描和安全加固

我們并不是所有的產(chǎn)品或組件都使用了容器化，

有一些可能還在常規(guī)的服務(wù)器上。每一次迭代都會(huì)執(zhí)

行漏洞掃描和安全加固，使用的工具是 Nessus Pro，

該工具可以花錢買也可以去官網(wǎng)下載免費(fèi)版的 Nessus

Essentials。

（七）漏洞應(yīng)急響應(yīng)中心（SRC）

我們是使用 Bugcrowd 建立應(yīng)急響應(yīng)中心，這對安全

部門來說也是一種工作的驗(yàn)收，可以驗(yàn)證工作的開展情

況。起初我們在上線 Bugcrowd 時(shí)定的目標(biāo)是讓滲透測試人

員發(fā)現(xiàn)不了安全漏洞去努力的，但后來發(fā)現(xiàn)確實(shí)做不到。

我們使用 Bugcrowd 一段時(shí)間，發(fā)現(xiàn)的問題都是一

些老功能或老產(chǎn)品的問題，而且沒有發(fā)現(xiàn)嚴(yán)重的問題。

如果是經(jīng)過安全設(shè)計(jì)流程的新功能，基本不會(huì)有什么問

題。所以從結(jié)果來看，安全設(shè)計(jì)流程這套方法對于軟件

安全有很大幫助。

三、安全團(tuán)隊(duì)建設(shè)

組建安全團(tuán)隊(duì)有兩個(gè)渠道，分別是招聘和內(nèi)部培

養(yǎng)。當(dāng)然，招聘是最快最直接補(bǔ)充有生力量的一個(gè)方法，

但是我們公司是在二三線城市，很難招到合適的人才，

38

百家論道 LECTURE ROOM

所以我們是兩條路并行，側(cè)重于內(nèi)部培養(yǎng)。

因?yàn)槲覀兪且患臆浖邪l(fā)公司，研發(fā)人員比較多，

占公司人員的一半左右，而且因?yàn)槭窃诙€城市，人

員留存率很高，所以培養(yǎng)研發(fā)人員轉(zhuǎn)行到安全的操作性

更強(qiáng)，而且培養(yǎng)出來的人也完全符合自身的要求。我們

的做法是挑出來一些對安全感興趣的人，讓他們每天抽

出來一兩個(gè)小時(shí)學(xué)習(xí)滲透測試和安全相關(guān)的技術(shù)，如果

合適再慢慢轉(zhuǎn)到半全職或者是全職做安全。

（一）研發(fā)背景的重要性

一個(gè)沒有研發(fā)背景的人，很難跟開發(fā)去討論安全設(shè)

計(jì)流程中需要注意的問題，很難全面考慮業(yè)務(wù)邏輯中的

安全問題。我們團(tuán)隊(duì)有一位在國內(nèi)某些 src 里做的不錯(cuò)

的選手，他的滲透能力很強(qiáng)，在內(nèi)網(wǎng)或攻擊相關(guān)的技術(shù)

都很擅長，比內(nèi)部培養(yǎng)出來的研發(fā)人員強(qiáng)很多。但如果

去做安全左移或安全設(shè)計(jì)流程的工作，還是做了四五年

研發(fā)轉(zhuǎn)安全的同事更好，而且面對越復(fù)雜的需求，研發(fā)

經(jīng)驗(yàn)不足帶來的弊端顯現(xiàn)的就會(huì)越大，畢竟術(shù)業(yè)有專攻。

研發(fā)轉(zhuǎn)安全還有一個(gè)好處，就是在做 Web 滲透的同

時(shí)也可以直接做代碼審計(jì)。當(dāng)然滲透測試人員也可以，

只是效率沒那么高。其實(shí)我們內(nèi)部也做了一些討論，如

果看 20 行代碼，有沒有研發(fā)背景都無所謂，只要能看懂

代碼就行。但是如果面對大量的代碼，比如一個(gè) 20 萬行

代碼的產(chǎn)品，這時(shí)有研發(fā)背景的人做代碼審計(jì)會(huì)比沒有

研發(fā)背景的人好很多。

在安全團(tuán)隊(duì)中，如果同時(shí)有滲透測試做的很好的人

和有研發(fā)背景的人會(huì)更好。像前面提到的滲透能力很強(qiáng)

的同事，在資源充足的情況下，可以讓他從事一些攻擊

相關(guān)的研究性工作，讓擅長的人做擅長的事。當(dāng)然，如

果想做好安全左移，保證軟件安全，那么安全團(tuán)隊(duì)一定

需要有研發(fā)背景的人。

（二）學(xué)習(xí)建議

不管是針對個(gè)人還是公司人才培養(yǎng)，如果想學(xué)習(xí)應(yīng)

用安全技術(shù)，有幾個(gè)比較好的資源。

第一，是 Burp Suite Web Security Academy，可

以免費(fèi)注冊賬號使用，上面會(huì)提供 Web 安全的技術(shù)文檔

和對應(yīng)的 Labs，對于學(xué) Web 相關(guān)的技術(shù)非常有幫助。

第二，推薦兩個(gè)證書，OSCP 和 OSWE。OSCP，在學(xué)

習(xí)過程中可以全面了解網(wǎng)絡(luò)攻擊 / 滲透，可以補(bǔ)充很多

Web 安全之外的技術(shù)。OSWE，針對 Web 安全工作的鍥合

度非常高，在考證過程中 80% 左右的內(nèi)容都可以在以后

的工作中用到。

（三）軟件安全研發(fā)人才培養(yǎng)

從我們內(nèi)部的實(shí)際經(jīng)驗(yàn)來看，在研發(fā)人員中培養(yǎng)安

全人才的成功率大概是 15：1，比如我們每次做內(nèi)部安全

培訓(xùn)，報(bào)名 30人左右，留到最后的大概也就 2個(gè)人左右。

培訓(xùn)方式，首先進(jìn)行滲透測試培訓(xùn)，然后做 Labs，

再慢慢從自己負(fù)責(zé)的產(chǎn)品挖掘漏洞。因?yàn)楸旧硎茄邪l(fā)出

身，對于自己負(fù)責(zé)的產(chǎn)品也很了解，有些就是自己寫的

代碼，所以很容易就可以找到問題，甚至有時(shí)可以找到

一些隱藏很深的問題。

安全研發(fā)人才培養(yǎng)成功的幾點(diǎn)決定性因素，首先是

工作飽和度，如果一個(gè)人他有時(shí)間就會(huì)愿意多學(xué)一點(diǎn)，

但如果本身的工作每天都會(huì)加班到很晚，他就不會(huì)有時(shí)

間去學(xué)習(xí)安全相關(guān)的技術(shù)，這是很重要的一個(gè)因素。其

次是興趣，興趣是最好的老師，包括我也是因?yàn)榕d趣才

走上這條道路。第三是上進(jìn)心，學(xué)習(xí)一項(xiàng)新技術(shù)肯定需

要有自驅(qū)力，往往堅(jiān)持到最后的可能就是上進(jìn)心比較強(qiáng)

的。最后是天賦，天賦可能說起來有點(diǎn)虛，但是做安全

尤其是做滲透測試確實(shí)需要一些天賦，有些研發(fā)做的比

較好的人在學(xué)安全時(shí)也很努力，但就是感覺不開竅，所

以天賦也很重要。

當(dāng)然，經(jīng)過培訓(xùn)之后，這些人不一定會(huì)留在安全團(tuán)

隊(duì)，但是他回到自己的團(tuán)隊(duì)負(fù)責(zé)某一個(gè)產(chǎn)品的安全，對

整個(gè)公司的安全也會(huì)起到非常大的作用。

39

LECTURE ROOM 百家論道

安全與業(yè)務(wù)戰(zhàn)略一致性的

理想與現(xiàn)實(shí)

網(wǎng)絡(luò)信息安全所有關(guān)于人員的資質(zhì)認(rèn)證中，都會(huì)有一個(gè)核心思想：安全戰(zhàn)

略需要為業(yè)務(wù)戰(zhàn)略服務(wù)，安全戰(zhàn)略需要與業(yè)務(wù)戰(zhàn)略保持一致性。

在信息化時(shí)代，信息化是業(yè)務(wù)支撐管理體系的信息化，是管理流程的信息

化，目的是實(shí)現(xiàn)企業(yè)管理信息的流轉(zhuǎn)。企業(yè)的 IT 部門通過購買商業(yè)軟件套件

（COTS）支撐管理體系的發(fā)展，從工作流支撐的行政辦公系統(tǒng)（OA），到財(cái)務(wù)

（ERP）、人力（HRM）、客戶關(guān)系（CRM）、進(jìn)銷存（ERM）、產(chǎn)品設(shè)計(jì)與管理（PDM）、

生產(chǎn)制造（MES），雖然對企業(yè)的業(yè)務(wù)發(fā)展起著至關(guān)重要的作用，但主要還是通

過管理系統(tǒng)的執(zhí)行和分析發(fā)揮價(jià)值，建立數(shù)據(jù)倉庫，通過智能分析（BI）系統(tǒng)

輔助分析與決策。但在企業(yè)實(shí)際運(yùn)作過程中，信息異步、人工錄入、流于形式、

生產(chǎn)與管理兩張皮的現(xiàn)象比比皆是。

業(yè)務(wù)部門對信息化部門雖談不上怨聲載道，但敬而遠(yuǎn)之，選擇性忽視，有

可能成為常態(tài)。信息化尚且如此，保障信息化體系的網(wǎng)絡(luò)信息安全部門距離業(yè)

務(wù)戰(zhàn)略的鴻溝讓安全與業(yè)務(wù)戰(zhàn)略保持一致，未免顯得過于理想。因此，網(wǎng)絡(luò)信

息安全從業(yè)者，沉醉于技術(shù)體系的升級換代，在攻防對抗的世界中沉迷，任你

業(yè)務(wù)如何風(fēng)云變幻，我謹(jǐn)守網(wǎng)絡(luò)與系統(tǒng)底層基礎(chǔ)安全的防護(hù)，業(yè)務(wù)與安全兩不

相見，相安無事，各得其所，何不快哉。

一、數(shù)字化

數(shù)字化的解讀汗牛充棟，華為在《華為數(shù)據(jù)之道》中提出了數(shù)字原生企業(yè)

與非原生企業(yè)的區(qū)別，數(shù)字作業(yè)系統(tǒng)是數(shù)字化的關(guān)鍵，在《華為數(shù)字化轉(zhuǎn)型之

道》提出了華為數(shù)字化轉(zhuǎn)型的 ROADS 方法論，Real-time（實(shí)時(shí)），On-denmand（按

需），All-online（在線），Diy（自制），Social（社交），對我們所提到的信息

化或者叫管理支撐系統(tǒng)的弊端進(jìn)行體系化的變革。清華大學(xué)朱巖教授的觀點(diǎn)是，

信息化是對內(nèi)，數(shù)字化是對外，對供應(yīng)鏈、產(chǎn)業(yè)鏈、監(jiān)管機(jī)構(gòu)和用戶，實(shí)質(zhì)上

也是支撐管理系統(tǒng)到生態(tài)作業(yè)系統(tǒng)的體系化轉(zhuǎn)變。

從這個(gè)維度而言，互聯(lián)網(wǎng)企業(yè)具有數(shù)字化原生的本質(zhì)，以淘寶、支付寶為

例，淘寶實(shí)現(xiàn)了零售的數(shù)字化轉(zhuǎn)型，用戶與商家的交易過程在實(shí)時(shí)、按需、在

線、自制、社交的前提下實(shí)現(xiàn)了作業(yè)的信息化，為了解決支付的效率、體驗(yàn)以

及實(shí)現(xiàn)線上信用背書，催生了支付寶，當(dāng)然為解決消費(fèi)金融以及供應(yīng)鏈金融誕

生的螞蟻金服、網(wǎng)商銀行等一系列創(chuàng)新，更促進(jìn)了金融行業(yè)的數(shù)字化，當(dāng)然與

傳統(tǒng)金融行業(yè)的杯葛不在本文探討范圍之內(nèi)。

數(shù)字化首先是業(yè)務(wù)的數(shù)字化轉(zhuǎn)型，基于業(yè)務(wù)數(shù)字化的組織變革，以此為基

礎(chǔ)的數(shù)字業(yè)務(wù)信息化，才是數(shù)字化的本質(zhì)與內(nèi)涵。

樂信集團(tuán)信息安全中心

總監(jiān)，中科院心理研究所管

理心理學(xué)博士，印第安納大

學(xué) Kelley 商 學(xué) 院 金 融 碩 士

（MF），香港理工大學(xué)軟件理

學(xué) 與 工 商 管 理（MBA） 雙 碩

士。前中國移動(dòng)電子認(rèn)證中

心（CMCA）負(fù)責(zé)人，OWASP 中

國廣東區(qū)域負(fù)責(zé)人，CSA 大中

華區(qū)數(shù)據(jù)安全專家，網(wǎng)安加

社區(qū)特聘專家。關(guān)注智慧城

市，企業(yè)數(shù)字化過程中網(wǎng)絡(luò)

空間安全風(fēng)險(xiǎn)治理，對大數(shù)

據(jù)、人工智能、區(qū)塊鏈等新

技術(shù)在金融風(fēng)險(xiǎn)治理領(lǐng)域的

應(yīng)用，以及新技術(shù)帶來的技

術(shù)風(fēng)險(xiǎn)治理方面擁有豐富的

理論和相關(guān)經(jīng)驗(yàn)。

劉志誠

40

百家論道 LECTURE ROOM

業(yè)務(wù)的數(shù)字化，不能僅停留在消費(fèi)互聯(lián)網(wǎng)的模式和

方法論上實(shí)現(xiàn)產(chǎn)業(yè)的業(yè)務(wù)數(shù)字化。在《數(shù)字經(jīng)濟(jì)：內(nèi)涵

與路徑》中，朱巖教授提出了“消費(fèi)互聯(lián)網(wǎng)的核心是流

量，產(chǎn)業(yè)互聯(lián)網(wǎng)的核心是信任”的觀點(diǎn)，從產(chǎn)業(yè)的維度

來看，不僅是消費(fèi)互聯(lián)網(wǎng) To C，產(chǎn)業(yè)互聯(lián)網(wǎng) To B 的問

題，產(chǎn)業(yè)互聯(lián)網(wǎng)的生態(tài)體系相對于消費(fèi)互聯(lián)網(wǎng)，網(wǎng)狀結(jié)

構(gòu)的復(fù)雜性不能僅用 Social（社交）來代替，我們的主

體不是談?wù)摦a(chǎn)業(yè)互聯(lián)網(wǎng)。簡而言之，當(dāng)諸多傳統(tǒng)行業(yè)選

擇了阿里、騰訊消費(fèi)互聯(lián)網(wǎng)大佬主導(dǎo)數(shù)字化變革，可能

已經(jīng)走了彎路。

業(yè)務(wù)數(shù)字化，從實(shí)現(xiàn)的角度離不開技術(shù)的進(jìn)步，

云原生技術(shù) 4 個(gè)核心特性，奠定了數(shù)字化技術(shù)的基礎(chǔ)。

DevOps，開發(fā)運(yùn)維一體化，為什么放在第一位，是因?yàn)?/p>

數(shù)字化業(yè)務(wù)的本質(zhì)必須是作業(yè)系統(tǒng)的自研，如果說管理

的標(biāo)準(zhǔn)化、體系化具有通用意義，那么作業(yè)系統(tǒng)代表業(yè)

務(wù)的性能、效率和獨(dú)特性，是業(yè)務(wù)的核心競爭力，如果

仍是采購的商業(yè)軟件（COTS），那么業(yè)務(wù)數(shù)字化這件事

首先就不成立。有人會(huì)說，自研系統(tǒng)當(dāng)然可以實(shí)現(xiàn)差異

化競爭優(yōu)勢，但如何解決開發(fā)人員稀缺的問題？這時(shí)

ChatGPT為代表的AIGC技術(shù)的進(jìn)步，讓我們看到了曙光。

容器化作為從獨(dú)立服務(wù)器到虛擬化的動(dòng)態(tài)資源池建

設(shè)的下一站，其彈性進(jìn)一步增強(qiáng)，虛擬機(jī)仍需要維持獨(dú)

立服務(wù)器時(shí)代硬件資源的調(diào)配管理的操作系統(tǒng)模式，對

資源的消耗，以及持久化維持，彈性仍然受制。容器化

通過應(yīng)用打包的模式，與應(yīng)用的活躍程度保持一致，可

以實(shí)現(xiàn)資源的調(diào)用和釋放的靈活性，對服務(wù)隔離、資源

彈性，以及非生產(chǎn)資源消耗優(yōu)化，均有極大的提升。

微服務(wù)作為軟件架構(gòu)的顛覆性升級，實(shí)現(xiàn)了組織阿

米巴模式的軟件架構(gòu)，不再限于獨(dú)立的單體軟件，或子

系統(tǒng)與模塊依賴的軟件體系，而是通過拆解原子能力服

務(wù)，實(shí)現(xiàn)服務(wù)解耦。這種技術(shù)的進(jìn)步，除了解決軟件團(tuán)

隊(duì)規(guī)模陷阱，實(shí)現(xiàn)軟件團(tuán)隊(duì)“兩塊披薩”的高效模式外，

對容器化的應(yīng)用集成，實(shí)現(xiàn)快速發(fā)布奠定了基礎(chǔ)。

持續(xù)發(fā)布是數(shù)字化業(yè)務(wù)的根本需求，為了應(yīng)對市

場競爭，實(shí)現(xiàn)業(yè)務(wù)的靈活調(diào)整，需要數(shù)字化系統(tǒng)實(shí)現(xiàn)持

續(xù)發(fā)布，當(dāng)然相對于傳統(tǒng)產(chǎn)品的瀑布式開發(fā)模式，消費(fèi)

互聯(lián)網(wǎng)時(shí)代成為主流的敏捷開發(fā)已經(jīng)具備了基因，結(jié)合

DevOps 的工具鏈，以及容器化和微服務(wù)架構(gòu)，實(shí)現(xiàn)持續(xù)

發(fā)布能力。

相對于我們通常關(guān)注的“ABCDE”技術(shù)進(jìn)步，重點(diǎn)闡

述了“C”云計(jì)算的云原生對數(shù)字化業(yè)務(wù)的理念和變革的

價(jià)值。當(dāng)然“A”人工智能隨著 AIGC 的爆火，對數(shù)字化

業(yè)務(wù)的運(yùn)營自動(dòng)化帶來了更多的想象空間?！癇”區(qū)塊鏈

的智能合約技術(shù)在金融領(lǐng)域 DiFI 的大放異彩，如何在數(shù)

字化業(yè)務(wù)的自動(dòng)化、契約化、去中心化中發(fā)揮作用，依

然有很大的空間，畢竟數(shù)字孿生背景下的元宇宙再造一

個(gè)宇宙，甚至超越物理宇宙的宏愿讓人心向往之?！癉”

大數(shù)據(jù)在數(shù)據(jù)作為除了土地、人力、資本、技術(shù)之外的

第五大要素，如何實(shí)現(xiàn)資源化、資產(chǎn)化、資本化，在理

論探索和實(shí)踐領(lǐng)域均有突破，是數(shù)字化在數(shù)據(jù)、算力、

算法三個(gè)核心要素中的關(guān)鍵一化，需要另文詳述?！癊”

邊緣計(jì)算的價(jià)值，目前仍被嚴(yán)重低估，5G 三大場景中

邊緣計(jì)算擁有一席之地，對傳統(tǒng) OT 網(wǎng)絡(luò)的替代，實(shí)現(xiàn)

IT、OT、CT 一體化，對傳統(tǒng)行業(yè)的影響更甚。（限于篇幅，

此處不再展開論述，感興趣的朋友可與筆者詳聊。）

二、安全

回歸到安全主體，我們要討論的是安全戰(zhàn)略與業(yè)

務(wù)戰(zhàn)略如何保持一致性的問題，信息化時(shí)代，由于信息

化本身和業(yè)務(wù)并不緊密的特征，以及支撐技術(shù)能力的欠

缺，理想雖在，落地不易，而數(shù)字化的本質(zhì)特征，為安

全戰(zhàn)略與業(yè)務(wù)戰(zhàn)略一致性落地提供了基礎(chǔ)。

信息化時(shí)代的安全關(guān)注的是網(wǎng)絡(luò)安全、主機(jī)安全、

系統(tǒng)安全、終端安全，圍繞的邊界也是企業(yè)邊界。因此

安全廠商圍繞的也是企業(yè)安全的解決方案，信息化時(shí)代

的管理系統(tǒng)承載，以購買的第三方信息系統(tǒng)套件（COTS）

為主，具備標(biāo)準(zhǔn)化、規(guī)范化、體系化的特征，另外網(wǎng)絡(luò)

信息安全監(jiān)管機(jī)構(gòu)關(guān)注的也是靜態(tài)的標(biāo)準(zhǔn)化安全基線的

檢查，以及在系統(tǒng)安全基礎(chǔ)上的紅藍(lán)對抗為主的攻防演

練。因此，大多數(shù)組織和企業(yè)的安全人員關(guān)注的是在保

41

LECTURE ROOM 百家論道

證監(jiān)管合規(guī)基礎(chǔ)上的網(wǎng)絡(luò)信息安全，通過購買標(biāo)準(zhǔn)化的

網(wǎng)絡(luò)信息安全產(chǎn)品，通過標(biāo)準(zhǔn)化的網(wǎng)絡(luò)信息安全測評服

務(wù)，拿到標(biāo)準(zhǔn)化的安全體系認(rèn)證，合規(guī)安全萬事大吉，

實(shí)際安全風(fēng)險(xiǎn)帶來的安全事故、應(yīng)急響應(yīng)，靠天吃飯。

在網(wǎng)絡(luò)、主機(jī)、系統(tǒng)之外，互聯(lián)網(wǎng)的普及，使得應(yīng)

用安全也逐漸成為信息安全關(guān)注的熱點(diǎn)，WAF、應(yīng)用攻防

也逐漸被納入網(wǎng)絡(luò)安全管理的范疇。數(shù)字化安全首當(dāng)其

沖需要關(guān)注的是研發(fā)安全，研發(fā)安全不僅是應(yīng)用安全，

如果說應(yīng)用安全是從攻防視角去關(guān)注應(yīng)用潛在的漏洞利

用以及攔截和修復(fù)，研發(fā)安全關(guān)注的是研發(fā)過程的風(fēng)險(xiǎn)

管理和風(fēng)險(xiǎn)處置能力的建設(shè)和運(yùn)營。信息系統(tǒng)成為數(shù)字

化業(yè)務(wù)的核心競爭力，自主開發(fā)信息系統(tǒng)的安全性就需

要依賴安全團(tuán)隊(duì)的研發(fā)安全管控能力。這個(gè)領(lǐng)域的創(chuàng)新

安全探討比較多，從傳統(tǒng) S-SDLC 支撐產(chǎn)品瀑布研發(fā)過

程，到 DevSecOps 對 DevOps 的支持，在商業(yè)產(chǎn)品研發(fā)類

企業(yè)中，白盒測試（SAST）具有悠久的歷史；在互聯(lián)網(wǎng)

應(yīng)用攻防領(lǐng)域，基于漏洞掃描和滲透測試的黑盒（DAST）

也已經(jīng)成為主流工具；在數(shù)字化業(yè)務(wù)運(yùn)營系統(tǒng)中研發(fā)安

全領(lǐng)域，灰盒（IAST）是目前崛起的新生勢力；與 IAST

異曲同工實(shí)現(xiàn)在 OPS 狀態(tài)防護(hù)應(yīng)用運(yùn)營狀態(tài)防護(hù)（RASP）

產(chǎn)品，也已經(jīng)展露頭角。不過需要關(guān)注的是，如何在運(yùn)

營系統(tǒng)中實(shí)現(xiàn)性能、穩(wěn)定性與平衡，仍有待實(shí)踐驗(yàn)證。

研發(fā)安全另外一個(gè)需要重點(diǎn)關(guān)注的問題是開源軟件

的治理，開源軟件帶來軟件領(lǐng)域繁榮的同時(shí)，也存在系

列問題，已經(jīng)另文撰述，就不再展開。唯一需要提醒的

是，在關(guān)注組件的同時(shí)，也需要關(guān)注中間件、應(yīng)用軟件

與采購的商業(yè)軟件一致，需要建立完整的生命周期管理

機(jī)制，對風(fēng)險(xiǎn)與漏洞進(jìn)行體系化管理。

業(yè)務(wù)安全也是個(gè)復(fù)雜的問題，不同數(shù)字化業(yè)務(wù)

的業(yè)務(wù)規(guī)則、流程不同，統(tǒng)一實(shí)現(xiàn)業(yè)務(wù)安全的產(chǎn)品也

難以標(biāo)準(zhǔn)化，需要考慮具體業(yè)務(wù)的場景、流程，參照

MarlonDumas在《過程感知的信息系統(tǒng)》里面的建模模式，

實(shí)現(xiàn)業(yè)務(wù)過程的跟蹤與處理，建立自己特色的業(yè)務(wù)安全

能力建設(shè)與運(yùn)營體系。

僅從幾個(gè)通用的維度來稍微展開一下業(yè)務(wù)安全的基

礎(chǔ)防御，首先是 To C 的賬號體系風(fēng)險(xiǎn)管理與控制。企業(yè)

內(nèi)部賬號管理體系在經(jīng)歷 IAM 管理的演進(jìn)，已經(jīng)從傳統(tǒng)

的賬號密碼認(rèn)證過渡到多因素（MFA），以及賬號、認(rèn)證、

鑒權(quán)、審計(jì)的 4A 甚至 5A 體系，再結(jié)合遠(yuǎn)程辦公的終端

設(shè)備風(fēng)險(xiǎn)和網(wǎng)絡(luò)風(fēng)險(xiǎn)從 VPN 升級到零信任，防御能力逐

步增強(qiáng)，但 To C 的用戶賬號，由于其終端不可控、網(wǎng)

絡(luò)不可控、環(huán)境不可控、用戶不可控，導(dǎo)致的黑灰產(chǎn)肆

虐，引起的爬蟲爬取用戶敏感信息和商業(yè)秘密信息、欺

詐、薅羊毛等系列風(fēng)險(xiǎn)，雖然業(yè)務(wù)風(fēng)控體系基于業(yè)務(wù)規(guī)

則進(jìn)行識別、封控和攔截，但往往基于事后的規(guī)則命中

機(jī)制亡羊補(bǔ)牢，難以提前防御和處理。在賬號注冊和關(guān)

鍵行為中，識別用戶側(cè)風(fēng)險(xiǎn)，是安全技術(shù)部門可以助力

業(yè)務(wù)的典型應(yīng)用。結(jié)合業(yè)務(wù)安全情報(bào)、終端環(huán)境、IP、

設(shè)備識別碼、行為特征、流量特征，實(shí)現(xiàn)前置的識別、

處置，事半功倍。

其次，是從生態(tài)的角度，關(guān)注 To B 合作伙伴的接入

和流量安全，專線和白名單的網(wǎng)絡(luò)安全控制措施，對應(yīng)

用層和業(yè)務(wù)層的安全保障難以起到作用，如何實(shí)現(xiàn)應(yīng)用

接入生命周期的管理，實(shí)現(xiàn)業(yè)務(wù)的實(shí)時(shí)跟蹤審計(jì)，規(guī)避

應(yīng)用與數(shù)據(jù)安全的滲入效應(yīng)，在實(shí)現(xiàn)企業(yè)安全的同時(shí)，

規(guī)避生態(tài)安全的影響，是解決 To B 安全的手段之一。另

外，數(shù)字化組織結(jié)構(gòu)的變革帶來的業(yè)務(wù)外包問題也不容

小覷，如何實(shí)現(xiàn) To B 員工在非受控網(wǎng)絡(luò)、非受控終端、

非受控用戶的情景下，訪問企業(yè)的作業(yè)系統(tǒng)，實(shí)現(xiàn)業(yè)務(wù)

安全保障，同樣也是個(gè)值得探討的課題。

僅從研發(fā)安全、業(yè)務(wù)安全的兩個(gè)場景聊一下，安

全的范圍與邊界的變革，但涉及到安全體系和機(jī)制的變

革，更重要的是組織變革和模式變革，這個(gè)話題談起來

并非三言兩語可以說清，可能也并不是目前安全從業(yè)者

關(guān)注的話題，畢竟即使擁抱變革，也不會(huì)對遙不可及或

看起來遙不可及的事情過于關(guān)注。

不過，還是簡單說幾句。相對于大企業(yè)構(gòu)建完整

的安全體系，實(shí)現(xiàn)體系化數(shù)字化安全能力的自建，中小

企業(yè)面對的其實(shí)是個(gè)兩難困境，要實(shí)現(xiàn)業(yè)務(wù)的核心競爭

力，構(gòu)建數(shù)字化業(yè)務(wù)的信息化系統(tǒng)，就需要針對性的自

主安全能力建設(shè)，而自主安全能力體系的建設(shè)和運(yùn)營，

帶來的成本增長，又難以消化解決。信息安全托管服務(wù)

（MSSP）這個(gè)概念不妨拿來借鑒與發(fā)展，企業(yè)未必全面

投資自身的數(shù)字化安全體系建設(shè)，只是需要數(shù)字化安全

保障服務(wù)，信息化時(shí)代的簡單性托管服務(wù)成為雞肋，而

數(shù)字化安全的復(fù)雜性，反而帶來了機(jī)會(huì)。當(dāng)然，傳統(tǒng)的

MSSP 體系建設(shè)和運(yùn)營一體化服務(wù)，難以實(shí)現(xiàn)資源的全

面復(fù)用和成本分擔(dān)，也并不能支撐企業(yè)的數(shù)字化安全，

而結(jié)合網(wǎng)絡(luò)安全保險(xiǎn)以及融資租賃的網(wǎng)絡(luò)安全金融化服

務(wù)，以及改變服務(wù)對象的網(wǎng)絡(luò)安全保險(xiǎn)科技就有了雙贏

的機(jī)會(huì)。

安全戰(zhàn)略與業(yè)務(wù)戰(zhàn)略一致性，看似理想與遙遠(yuǎn)，其

實(shí)，很快理想就會(huì)照亮現(xiàn)實(shí)，這也是網(wǎng)絡(luò)安全從業(yè)者不

可多得的機(jī)會(huì)。

42

百家論道 LECTURE ROOM

漫談安全的兩三事

本科畢業(yè)于西南交通大

學(xué)，碩士畢業(yè)于中南大學(xué)，目前

中南大學(xué)博士在讀，具備計(jì)算機(jī)

領(lǐng)域?qū)I(yè)背景和根基，是網(wǎng)安加

社區(qū)特聘專家。先后就職于中國

中鐵五局、株洲中車時(shí)代電氣股

份有限公司、廣東 OPPO 移動(dòng)通

信有限公司等大型集團(tuán)企業(yè)，目

前任職三一重工股份有限公司信

息安全負(fù)責(zé)人，全面負(fù)責(zé)三一集

團(tuán)的企業(yè)信息安全戰(zhàn)略規(guī)劃、企

業(yè)安全體系架建、安全人才隊(duì)伍

建立和培養(yǎng)等。

孟翔巍

一、關(guān)于網(wǎng)絡(luò)安全域?qū)崿F(xiàn)的一些個(gè)人看法

（一）網(wǎng)絡(luò)安全域參考模型

關(guān)于網(wǎng)絡(luò)安全域，現(xiàn)在很多企業(yè)都想?yún)⒖碱^部企業(yè)的模型來落地實(shí)施，其

關(guān)鍵點(diǎn)是通過紅黃綠三個(gè)區(qū)來實(shí)踐落地。

紅區(qū)，該區(qū)域終端僅能訪問內(nèi)網(wǎng)核心研發(fā)系統(tǒng)，且外設(shè)接口均被封閉；無

互聯(lián)網(wǎng)訪問權(quán)限，有互聯(lián)網(wǎng)訪問需求時(shí)由公共機(jī)解決；進(jìn)入該區(qū)域的人員，不

允許帶入任何具備留痕能力的設(shè)備，包含但不限于手機(jī)、U 盤等。

黃區(qū)，該區(qū)域終端能訪問內(nèi)網(wǎng)非核心研發(fā)系統(tǒng)與部分辦公系統(tǒng)，且外設(shè)接

口均被封閉，有配套流程可以進(jìn)行開放；具備基礎(chǔ)互聯(lián)網(wǎng)訪問權(quán)限，即普通查

詢的 web 資源等；進(jìn)入該區(qū)域的人員，在授權(quán)情況下允許帶入具備留痕能力的

設(shè)備，但需要一定處理，比如有專門的安保人員會(huì)用封條將筆記本和手機(jī)的攝

像頭貼起來。

綠區(qū)，該區(qū)域終端僅能訪問內(nèi)網(wǎng)辦公系統(tǒng)，外設(shè)均處于放開狀態(tài)；互聯(lián)網(wǎng)

訪問權(quán)限無限制；人員可隨意進(jìn)出該區(qū)域，無物理限制。

這是一個(gè)非常理想的模型，但它有一個(gè)核心規(guī)則，即從低密到高密的單向

數(shù)據(jù)流，從而保護(hù)整體的核心研發(fā)資產(chǎn)。該模型比較適合研發(fā)相對集中的企業(yè)。

（二）達(dá)成該模型的前置條件

從實(shí)際落地經(jīng)驗(yàn)來看，要達(dá)成該模型有三個(gè)關(guān)鍵的前置條件：

物理先行。至少得把具備同類屬性的人員聚合在同一個(gè)物理空間里面，這

個(gè)難度非常大，因?yàn)闃?biāo)桿企業(yè)在開始就把同一類人員聚集到同一個(gè)辦公區(qū)，就

會(huì)簡單很多。如果剛開始沒有這么做，后期幾乎不可能把人員聚到一起，人員

一定是交錯(cuò)的，這時(shí)候再進(jìn)行人員辦公區(qū)域調(diào)整將是一個(gè)巨大的工程量，這也

是該標(biāo)準(zhǔn)模型落實(shí)不了的原因之一。

數(shù)據(jù)單向流的可行性。這個(gè)節(jié)點(diǎn)得解決兩個(gè)問題，一個(gè)是技術(shù)實(shí)現(xiàn)問題，

能否實(shí)現(xiàn)單向流，我當(dāng)時(shí)有做過相關(guān)的工具調(diào)研，可以實(shí)現(xiàn)，但是部署和運(yùn)維

的難度比較大。一個(gè)是規(guī)則實(shí)現(xiàn)問題，是不是一定能做到低密往高密流，如果

在業(yè)務(wù)規(guī)則源頭上沒有定義清楚，會(huì)很難實(shí)現(xiàn)，因?yàn)闃I(yè)務(wù)之間的交付已經(jīng)形成

定式，要去打破這種定式，用另外一個(gè)規(guī)則去約束業(yè)務(wù)，那么對業(yè)務(wù)的效率將

造成極大的影響。

本文將以故事和經(jīng)驗(yàn)實(shí)踐的方式展示給大家，分享的內(nèi)容主要有三個(gè)話

題，分別是網(wǎng)絡(luò)安全域的實(shí)踐、API 治理實(shí)踐與 SOAR 的暢想與實(shí)踐。本文僅為

拋磚引玉之作，希望能給大家提供借鑒，并期待與業(yè)界同仁的深入探討。

43

LECTURE ROOM 百家論道

成本的控制?；谖锢砣?shí)現(xiàn)這樣的模型，取決

于本身物理空間的需求較大，造成較大的成本投入；其

次，物理空間規(guī)劃好之后，每一塊物理區(qū)域都需要一套

IDC基礎(chǔ)設(shè)施，如何說服老板投入，這本身也是個(gè)問題。

實(shí)際上，在做安全工作的過程中都會(huì)面臨說服老板

的情況，因?yàn)榘踩幸粋€(gè)重要的屬性是“既不降本也不

增效”，它與企業(yè)降本增效的理念是相違背的，因此安全

工作都是通過降低安全事故的發(fā)生率去說服老板來進(jìn)行

投入。

（三）純邏輯方式實(shí)現(xiàn)裁剪模型

如果做不到物理先行，那就只能從邏輯上面去考

慮。不再通過物理層面區(qū)分人員，盡量把相關(guān)人員集中

在一起，從路由層面來建紅黃綠區(qū)，再通過不同層面的

路由互寫，也就是 ingress 和 exgress 的方式，把路由

進(jìn)行輸出和導(dǎo)入，從而實(shí)現(xiàn)類似物理先行那種管控狀態(tài)。

但是經(jīng)過試驗(yàn)發(fā)現(xiàn)這一套很難走下去，主要原因

有三個(gè)：一是運(yùn)維難度非常大，人員位置的變換還能解

決，但是路由空間的配置本身就非常復(fù)雜，如果稍微有

一點(diǎn)業(yè)務(wù)變更，意味著路由這邊要調(diào)整很多東西，運(yùn)維

難度非常大；二是人員依賴性很強(qiáng)，這一套工作完整做

下來的人員，在很熟悉路由規(guī)則的情況，運(yùn)維還是可以

搞定的，但如果人員進(jìn)行了更替，意味著整體的延續(xù)性

就不好了，因?yàn)橐粋€(gè)月都不一定能交接完，即使交接完

也需要有很長的適應(yīng)周期；三是成本相對較小，這算是

一個(gè)優(yōu)點(diǎn)，基本上就是一套網(wǎng)絡(luò)設(shè)備加上一套安全設(shè)備。

（四）物理與邏輯相結(jié)合的方式實(shí)現(xiàn)裁剪模型

物理與邏輯相結(jié)合的方式，就是將物理層面定義為

類似實(shí)驗(yàn)室的方式，相對封閉，按照“二八原則”把最

核心的 10-20% 的人聚集到一起，然后以實(shí)驗(yàn)室的方式參

照前面的模型把它徹底隔離起來，建立紅區(qū)，其物理和

路由層面是統(tǒng)一的。黃區(qū)和綠區(qū)還是用純邏輯的方法，

通過路由層面進(jìn)行隔開。相對純邏輯的裁剪模型來說成

本會(huì)高一些，因?yàn)橛形锢砗吐酚蓪用娼y(tǒng)一的部分，至少

會(huì)多一套設(shè)備。

而且，即使將紅區(qū)摘出去，黃區(qū)和綠區(qū)的運(yùn)維難度

也不小，因?yàn)榧t區(qū)在整體規(guī)劃中的占比較小，黃區(qū)和綠

區(qū)還是占大部分。此外，對人員的依賴性依然很強(qiáng)，因

為它的復(fù)雜度就決定了如果出現(xiàn)人員交替，其連續(xù)性一

定會(huì)存在問題。所以經(jīng)過一段時(shí)間的實(shí)踐，隨著整體覆

蓋面的鋪開，發(fā)現(xiàn)最終的目的難以實(shí)現(xiàn)。

（五）解決方案的探索過程

基于上面幾種模型的探索，我就在思考，到底要

通過這個(gè)模型解決什么問題？我認(rèn)為這個(gè)模型是嘗試從

人員、終端、應(yīng)用三個(gè)角度實(shí)現(xiàn)防攻擊、防泄漏和防特

權(quán)，這是它要實(shí)現(xiàn)的頂層目標(biāo)。

其次，參考這個(gè)模型，最大的價(jià)值點(diǎn)是什么？我個(gè)

人認(rèn)為是從物理角度出發(fā)，解決了人、機(jī)（設(shè)備）、料（應(yīng)

用）之間的問題。為何很多組織參照模型的時(shí)候落不了

地，有個(gè)最重要的原因，就是對于物理先行上有絕對的

執(zhí)行鴻溝。因?yàn)樵谖锢砦恢霉潭ê玫慕M織中，再去進(jìn)行

位置的調(diào)換將是絕對達(dá)不成的工作，基本不是某個(gè)人能

決定的，牽涉的范圍很大。

因此，既然物理層面落不下去，那就拋開一定的輸

出點(diǎn)，不再考慮人的問題，轉(zhuǎn)而去解決機(jī)、料的問題，

實(shí)際上就是在實(shí)現(xiàn)能不能訪問、權(quán)限給不給的問題，而

這個(gè)問題就可以通過 SDP 來解決。

縱觀SDP整體架構(gòu)，其中關(guān)于用戶部分有信任引擎，

可以從 IAM/PAM/4A 獲取一些基礎(chǔ)的權(quán)限數(shù)據(jù)，然后通過

一部分通道策略傳輸?shù)綉?yīng)用代理，明確可以訪問哪些應(yīng)

用。經(jīng)過兩兩組合來解決前面提到的兩個(gè)核心問題，就

是本身的基礎(chǔ)權(quán)限的源和信任引擎加到一起，信任引擎

對權(quán)限通過模型的方式去做加權(quán)，根據(jù)本地終端的環(huán)境

數(shù)據(jù)來決定給多少權(quán)限，這就解決了權(quán)限到底給不給的

問題，然后信任引擎加上代理的 porxy，解決能不能訪

問的問題。

事實(shí)上 SDP 概念是基于零信任而來，被炒作了很長

一段時(shí)間，主要體現(xiàn)的核心價(jià)值有兩個(gè)，動(dòng)態(tài)鑒權(quán)與動(dòng)

態(tài)授權(quán)，也就是解決權(quán)限和訪問的問題。

二、關(guān)于 API 治理過程中的一些心得

關(guān)于 API 治理心得，先給大家介紹一下背景。有一

天，研發(fā)負(fù)責(zé)人找過來，說業(yè)務(wù)正在做數(shù)字化轉(zhuǎn)型，要

44

百家論道 LECTURE ROOM

構(gòu)建應(yīng)用產(chǎn)品生態(tài)，想通過一個(gè)平臺做 API 的生命周期

管理，問安全要不要一起聯(lián)合立項(xiàng)？聽完我很感興趣，

因?yàn)槲冶緛硪蚕胱鲋卫磉@塊的事情，但是業(yè)務(wù)不參與到

整個(gè)過程中，只靠安全來推動(dòng)會(huì)遇到很大阻力。所以當(dāng)

研發(fā)負(fù)責(zé)人愿意來一起建設(shè)，我們是一拍即合。

（一）安全的考慮點(diǎn)與業(yè)務(wù)的適配性

在請示老板意見的這段時(shí)間發(fā)生了一些狀況，因?yàn)?/p>

彼此較忙中間沒有太多交流，等我們第一次碰撞的時(shí)候

才發(fā)現(xiàn)兩人的思考方向完全不同。研發(fā)負(fù)責(zé)人想的是平

臺的架構(gòu)、API 的管理、以及應(yīng)用之間的區(qū)分等等。而

我是從安全角度出發(fā)，想的是API發(fā)布之后的權(quán)限范圍、

使用協(xié)議、敏感數(shù)據(jù)加密、數(shù)據(jù)脫敏、API 認(rèn)證、授權(quán)

等等。

然后研發(fā)負(fù)責(zé)人就說了，你想那么多安全需求，我

怎么去做融合，總得先要溝通梳理一下。我一想也對，

至少應(yīng)該通過溝通去調(diào)研到一些內(nèi)容，比如架構(gòu)層設(shè)

計(jì)、技術(shù)支撐管理的流程配套、內(nèi)部 API 和外部供應(yīng)鏈

等等，這次事情也讓我明白安全應(yīng)該考慮到與業(yè)務(wù)的適

配性，不能只站在自己安全的角度思考問題。

（二）業(yè)務(wù)的分層方案

兩周之后，業(yè)務(wù)給出了方案架構(gòu)，初始的想法是內(nèi)

部的 API 要管，上游的也要管，但是一個(gè)平臺全部管理

的復(fù)雜度有點(diǎn)高，于是就有兩個(gè)方向：一是就做一個(gè)平

臺，將它做成兩個(gè)模塊，分管內(nèi)外；另一個(gè)是，把平臺

一拆為二，內(nèi)外部分開管理。區(qū)別在于，兩個(gè)平臺相對

來說成本和周期更高，一個(gè)平臺更簡單一些；但是從從

后期管理來看，兩個(gè)平臺運(yùn)營的成本要低一些，一個(gè)平

臺運(yùn)營成本則偏高。兩種方式各有優(yōu)劣，但是從安全的

角度來說，兩個(gè)平臺要比一個(gè)平臺好，因?yàn)槿绻獠科?/p>

臺萬一被漏洞利用，內(nèi)部平臺還能用，比一個(gè)平臺的安

全性更穩(wěn)妥一點(diǎn)。

經(jīng)過綜合考慮，最后還是將平臺一拆為二，即如圖

所示的 Inbound 與 Outbound。在整個(gè)過程中，我們把

APP 分類之后，在平臺中嵌入了一個(gè)流程點(diǎn)，就是在產(chǎn)

品上線時(shí)一定要把 API 發(fā)布到平臺，如果有對外的交付

需求，可以把 API 在對外的網(wǎng)絡(luò)上再做一次發(fā)布。當(dāng)然

后期還在完善中，只需要一次發(fā)布就可以完成兩件事。

然后，其他 APP 來調(diào)用時(shí)直接從平臺調(diào)用即可，不需要

再進(jìn)行 APP 之間的調(diào)用。大概整體架構(gòu)和業(yè)務(wù)的實(shí)現(xiàn)，

安全與研發(fā)基本達(dá)成共識。

（三）安全應(yīng)對與解決方案

框架與業(yè)務(wù)實(shí)現(xiàn)達(dá)成共識之后，我就著手考慮安全

應(yīng)對與解決方案。首先是對應(yīng)用進(jìn)行定級，才能確定后

面 API 的范圍。然后，盡量梳理清楚現(xiàn)有的 API 資產(chǎn)，

包括數(shù)量與類型。做完這兩項(xiàng)基礎(chǔ)工作，就開始研發(fā)。

在 Inbound 的安全工作中，首先重點(diǎn)肯定要有流程

配套，包括 API 的發(fā)布、使用以及隨著產(chǎn)品的下線的生

命周期，一定要有一個(gè)配套流程。第二步，根據(jù)應(yīng)用定

級和 API 資產(chǎn)治理的結(jié)果，確定哪些 API 需要什么樣的

安全配套。第三步，梳理 API 的時(shí)候也會(huì)把一些 APP 之

間的關(guān)系梳理清楚，這時(shí)沒必要把授權(quán)卡的太緊，就給

予了較為寬松的授權(quán)范圍。然后，做輕量級的傳輸加密，

挑重點(diǎn)去做，保證即使發(fā)生 API 的泄露，這種基本的加

密形式也會(huì)有所保障。最后，通過一些工具對威脅進(jìn)行

監(jiān)控。

在 Outbound 的安全工作中，主要分為公有云和供應(yīng)

鏈上下游兩個(gè)部分。首先把使用協(xié)議做出來，將供應(yīng)鏈

這塊的使用協(xié)議推下去，風(fēng)險(xiǎn)共擔(dān)。第二步，要有認(rèn)證

45

LECTURE ROOM 百家論道

機(jī)制，確定哪些 APP 需要嚴(yán)格一些的認(rèn)證。第三步，要

有嚴(yán)格的授權(quán)范圍，要調(diào)用哪個(gè) APP 就只能調(diào)用哪個(gè)。

第四步，重量級傳輸加密，只要是出去的數(shù)據(jù)都要加

密，也是為了防止數(shù)據(jù)泄露。最后，點(diǎn)對點(diǎn)消費(fèi)，就是

上下游每一次抓取數(shù)據(jù)，使用完后就銷毀掉，不再留存。

通過這種方法來實(shí)現(xiàn)安全與業(yè)務(wù)的協(xié)同，同時(shí)完成

各自的目標(biāo)。

（四）API 治理心得

首先，安全不要嘗試走到業(yè)務(wù)前面。安全實(shí)際上

是一個(gè)孿生技術(shù)，基本上是孿生在整個(gè)業(yè)務(wù)的成熟度上

面，因此安全的成熟度不可能高于業(yè)務(wù)，一般比較厲害

的能跟業(yè)務(wù)保持一致，比業(yè)務(wù)慢半拍也是比較合理的。

第二，先治理后技術(shù)，技術(shù)的價(jià)值是為管理服務(wù)

的。既然為管理服務(wù)，那么要做好支撐，肯定是個(gè)自上

而下的過程，如前文提到的先把應(yīng)用資產(chǎn)治理好再去實(shí)

現(xiàn)技術(shù)會(huì)更順暢。

最后，常態(tài)化運(yùn)營，不要湮沒建立起來的秩序，通

過流程的方式讓整體更加規(guī)范化。

三、關(guān)于 SOAR 的一些暢想與實(shí)踐

我對 SOAR 的理解分為三層，第一層就是業(yè)內(nèi)對

SOAR 的定義，即 SOAR 是安全自動(dòng)化編排，是實(shí)現(xiàn)自動(dòng)

化安全威脅響應(yīng)的能力。第二層，基于該定義我認(rèn)為

SOAR 是一個(gè)技術(shù)框架，有兩個(gè)關(guān)鍵詞，即自動(dòng)化響應(yīng)和

編排，自動(dòng)化響應(yīng)其實(shí)是靠整體的技術(shù)棧來解決，編排

是靠流程來解決。基于這個(gè)理解，我認(rèn)為它是在解決安

全運(yùn)營最后一公里的問題，在我的團(tuán)隊(duì)里我更愿意稱之

為“自愈”，這是我的第三層理解。

談到自愈，此處分享一個(gè)經(jīng)典劇本，相當(dāng)于威脅處

置的 SOAR 過程。第一步植入，第二步潛伏等待，第三部

命令執(zhí)行，當(dāng)其去做 CC 回連，這時(shí)相關(guān)工具就會(huì)檢測到

威脅數(shù)據(jù)，產(chǎn)生一些日志，然后會(huì)有一個(gè)腳本化過程，

把 CC 回連阻斷掉。

基于這個(gè)劇本，我一直認(rèn)為 SOAR 是一個(gè)技術(shù)框架，

這里列舉了三個(gè)例子，基線管理、漏洞管理和補(bǔ)丁管理。

實(shí)際上，SOAR 上線之前，其他流程都是自動(dòng)化，

唯獨(dú)修復(fù)階段都需要人工，無論是基線、漏洞，還是

補(bǔ)丁。這就是前面提到的最后一公里，也是我想推動(dòng)的

方面。首先，我是把基線抽出來做，寫一些修復(fù)腳本，

也就是自愈腳本，然后找了一個(gè)下發(fā)成功率最高的樁，

檢驗(yàn)時(shí)發(fā)現(xiàn)該思路可行，于是就往上推?，F(xiàn)在，基線的

SOAR 實(shí)踐基本沒有問題，工單從產(chǎn)生到整體閉環(huán)，不再

需要人工去干預(yù)。

其中，自愈腳本和樁一起做了編排，讓樁能做的事

更多一點(diǎn)，這樣的話基線流程基本實(shí)現(xiàn) 100% 自動(dòng)化，補(bǔ)

丁也接近 100% 自動(dòng)化，漏洞做不到 100%，但會(huì)提高自

動(dòng)化率，通過這種方式把整體的SOAR體系逐步構(gòu)建起來。

在實(shí)踐完之后，我當(dāng)時(shí)在考慮要不要做一個(gè)中臺，

有兩種方式，一是做成中臺，把 SOAR 最后流程的人工端

點(diǎn)補(bǔ)完；二是把 SOAR 做成 SOC 的一個(gè)模塊，模塊之間來

調(diào)用，整體過程還是“SOC-SOAR- 樁”互相拉動(dòng)的方式。

其實(shí)這兩種方式差別不大，把前中臺分開去看，覺得可

能邏輯更清晰一點(diǎn)，方便整體架構(gòu)的橫向擴(kuò)容和收縮；

把前中臺做到一起，相對來說功能更集約，前臺能力更

全面。因?yàn)槟繕?biāo)都是自愈，從底層來看，兩種方式實(shí)現(xiàn)

流程都一樣，怎么選擇取決于組織的具體情況。

46

百家論道 LECTURE ROOM

OCBC 框架下企業(yè)云化 CSPM

落地思考和實(shí)踐探索

某互聯(lián)網(wǎng)公司高級安全專

家，網(wǎng)安加社區(qū)特聘專家，近

10 年安全行業(yè)從業(yè)經(jīng)驗(yàn)，5 年 +

團(tuán)隊(duì)管理經(jīng)驗(yàn)，長期負(fù)責(zé)企業(yè)安

全建設(shè)，探求安全體驗(yàn)與效率并

存的安全能力和解決方案建設(shè)。

熟悉公有云安全、數(shù)據(jù)安全、基

礎(chǔ)安全和安全運(yùn)營等領(lǐng)域，擅長

企業(yè)的信息安全解決方案高效落

地，并有體系規(guī)劃和安全運(yùn)營實(shí)

踐經(jīng)驗(yàn)。在企業(yè)安全產(chǎn)品方案選

型和建設(shè)（特別是數(shù)據(jù)安全）、

解決方案規(guī)劃與落地、安全運(yùn)營

能力體系化建設(shè)等方面具備獨(dú)特

理解和全過程實(shí)踐經(jīng)驗(yàn)。

李 磊

一、CSPM 歷史

（一）CSPM 的產(chǎn)生

很早以前，隨著云市場的蓬勃發(fā)展，與云相關(guān)的概念應(yīng)運(yùn)而生。Gartner 敏

銳地捕獲到了類似的變化，早早創(chuàng)立了以 C 字母打頭為縮寫的與云市場密切關(guān)

聯(lián)的各種領(lǐng)域詞匯，像Cloud Computing、Cloud Security Solution等。CSPM（即

Cloud Security Posture Management）是其云安全解決方案家族中的普通一員。

根據(jù) Gartner 歷年發(fā)布的“云安全技術(shù)成熟度曲線”數(shù)據(jù)，筆者粗繪了圖

一 CSPM 及其關(guān)聯(lián)技術(shù)成熟度炒作曲線時(shí)間軸。大約在 2017 年時(shí)，Gartner 提

出了 CSPM 一詞。為什么是大約呢？因?yàn)樵?2018 年 Gartner 發(fā)布的“云安全技

術(shù)成熟度曲線”中，Gartner 將 CSPM 定位在期望膨脹期，所以至少在 2017 年以

前 Gartner應(yīng)該已經(jīng)提出了類似概念。不過，在 2017 年或更早前的相關(guān)報(bào)告中，

并未發(fā)現(xiàn) CSPM 這個(gè)縮略詞。

CSPM（圖一綠色字體部分）從提出到現(xiàn)在，短短幾年，經(jīng)歷大起大落。當(dāng)

前正處于所謂“穩(wěn)步爬升恢復(fù)期”，看似一片大好。

（圖一 CSPM 及其關(guān)聯(lián)技術(shù)成熟度炒作曲線時(shí)間軸）

為什么要花這么長的時(shí)間去梳理 CSPM 產(chǎn)生的時(shí)間線呢？筆者希望通過拉開

時(shí)間的維度，來看具體是在什么樣的誘因下 Gartner 提出了 CSPM 一詞，這樣更

有利于理解 CSPM 最初是寄希望于解決怎樣的問題。

本文作為《新視角下企業(yè)云化安全治理框架 OCBC》B 基準(zhǔn)（云產(chǎn)品安全基

準(zhǔn)中安全基線子項(xiàng)）的縱向闡釋篇，細(xì)化在云產(chǎn)品和服務(wù)風(fēng)險(xiǎn)管控中的一些個(gè)

人理解、思考和落地實(shí)踐。

47

LECTURE ROOM 百家論道

回顧 2017-2018 年，與云相關(guān)幾個(gè)重大事件有：

（1）根據(jù)《2017 年云計(jì)算行業(yè)市場發(fā)展分析報(bào)告》

數(shù)據(jù)顯示，當(dāng)年全球云計(jì)算巨頭收入增長驚人；

（2）2017 年，中國工信部正式頒布云牌照監(jiān)管政

策，讓很多云廠商的合規(guī)之路順利上岸。而且在 2018

年，BAT 云計(jì)算戰(zhàn)略升級，云部門被提升到一個(gè)新的高

度。如阿里云事業(yè)群升級為阿里云智能事業(yè)群。全新

的阿里云智能事業(yè)群，將中臺的智能化能力（包括機(jī)器

智能的計(jì)算平臺、算法能力、數(shù)據(jù)庫、基礎(chǔ)技術(shù)架構(gòu)平

臺、調(diào)度平臺等核心能力）將和阿里云全面結(jié)合。

（3）根據(jù) ITRC 數(shù)據(jù)泄露報(bào)告內(nèi)容顯示，2017 年的

數(shù)據(jù)泄露事件較 2016 年增加 44.7%，達(dá)到一個(gè)創(chuàng)歷史的

記錄。同時(shí)，云上數(shù)據(jù)占 TOP 數(shù)據(jù)泄露比例為 28%，并

呈逐步上升趨勢。

（4）根據(jù)統(tǒng)計(jì)，云上數(shù)據(jù)泄露由于云服務(wù)配置錯(cuò)誤

的占比約為 40%，而這一趨勢仍在增長。

通過這些與云相關(guān)的重大事件，可見云的發(fā)展高

歌猛進(jìn)，企業(yè)云化帶來高價(jià)值數(shù)據(jù)集中，但云上因?yàn)?/p>

配置問題導(dǎo)致的數(shù)據(jù)泄露頻發(fā)?？梢园l(fā)現(xiàn)，Gartner 最

初提出 CSPM 的理念最希望解決的是 configuration of

cloud services 中的問題。

神奇的點(diǎn)在于，這是誰的責(zé)任？

甲方云化企業(yè)以為是云企業(yè)的問題，云廠商以為甲

方已經(jīng)知道了這個(gè)是它自己的責(zé)任。

實(shí)際上，多數(shù)上云的甲方是不清楚的，很多云化的

企業(yè)或安全從業(yè)者本來是尚未準(zhǔn)備好應(yīng)對云帶來的安全

變化，在如何更安全的用云和云上的責(zé)任劃分存在著認(rèn)

知偏差，事實(shí)上亦是如此。根據(jù) 2020 年 CISO MAG 調(diào)查

顯示 ,76% 的用戶認(rèn)為云廠商是要為云上安全負(fù)所有責(zé)任

的。顯然，這是不現(xiàn)實(shí)的。

作為云廠商的乙方，其實(shí)早早看透了這一點(diǎn)，很早

就發(fā)布了自己的“責(zé)任共擔(dān)模型”。所以，我們還是再看

下它到底說了什么。

（二）云上責(zé)任共擔(dān)模型

責(zé)任共擔(dān)模式的出現(xiàn)，本質(zhì)上是因?yàn)榛ê头?wù)的

提供方發(fā)生了變化。

責(zé)任共擔(dān)模型是定義云服務(wù)提供者及其客戶之間的

安全責(zé)任的框架。基本每家云廠商都推出了自己的責(zé)任

共擔(dān)模式，但是實(shí)質(zhì)的內(nèi)容大同小異。筆者的理解主要

是兩個(gè)點(diǎn)：

（1）云“基建”的安全責(zé)任屬于云廠商，可以理解

為冰山下的。

（2）云“使用”的安全責(zé)任屬于云用戶，可以理解

為冰山上的。

我們以圖二 AWS責(zé)任共擔(dān)模型為例，來簡要做下解釋。

如果我是云用戶，但是在自己的租戶環(huán)境下，發(fā)

現(xiàn)可以通過私網(wǎng)方式訪問到其他與我無任何業(yè)務(wù)關(guān)系

云租戶的環(huán)境或資源，或者直接訪問到 AWS 云環(huán)境的

Infrastructure 管控端，那這個(gè)屬于漏洞，修洞的責(zé)任

或出現(xiàn)問題的背責(zé)方肯定是云廠商。說白了，云廠商要

為自己的基建安全性負(fù)責(zé)。

如果我是云用戶，買了 AWS 的 S3，類似阿里云

的 OSS。我在 S3 中存了很多的數(shù)據(jù)，但是我卻把 S3 桶

sec-data 的權(quán)限設(shè)置為 Public，造成互聯(lián)網(wǎng)上的任何用

戶都可以訪問。那么，這個(gè)責(zé)任肯定是屬于云用戶自身

的。因?yàn)?，作為云廠商提供了豐富的 Identity&Access

management 機(jī)制，而且事實(shí)上我也完全可以通過這些機(jī)

制將 sec-data 設(shè)置為 Private 來規(guī)避這個(gè)問題。其實(shí)，

這個(gè)問題本質(zhì)是云用戶沒有做好圖 2 中 Identity&Access

management。

通過這個(gè)簡單的例子，其實(shí)是想表達(dá)，把云用好的

安全責(zé)任是歸屬云用戶的。即，上述云配置的安全風(fēng)險(xiǎn)

責(zé)任是需要甲方自己關(guān)注的，甲方需要根據(jù)自己的業(yè)務(wù)

特點(diǎn)，使用云服務(wù)或產(chǎn)品的功能來安全的服務(wù)自身業(yè)務(wù)。

筆者在《新視角下企業(yè)云化安全治理框架 OCBC》一

文中，已提到云產(chǎn)品安全基線，本質(zhì)上也是希望解決云

產(chǎn)品使用中的配置安全問題。

（圖二 AWS 責(zé)任共擔(dān)模型）

二、CSPM 介紹

（一）CSPM 定義

好了，了解以上的背景后，我們現(xiàn)在看一下，

Gartner 對 CSPM 的具體定義。剛看到圖一時(shí)，部分讀者

48

百家論道 LECTURE ROOM

可能會(huì)非常好奇，為什么講 CSPM，還要關(guān)聯(lián)帶上 CWPP、

CIEM、CNAPP 等名詞。因?yàn)閺默F(xiàn)在的時(shí)間看來，Gartner

自身對 CSPM 的定義也是日趨豐富和完善。

另一個(gè)希望表達(dá)的是，無論是 CSPM 抑或 CIEM、

CWPP等間都存在著關(guān)聯(lián)性。這點(diǎn)，筆者后面會(huì)詳細(xì)提到。

為免翻譯帶來的理解差異，筆者直接引用 Gartner

的原文最新定義：

Cloud security posture management (CSPM) consists of offerings that continuously manage IaaS

and PaaS security posture through prevention,

detection and response to cloud infrastructure

risks.

在上述的定義中，可以清晰的看到幾點(diǎn)：

（1）CSPM 管控對象為 IaaS、PaaS，注重的是 infra

的風(fēng)險(xiǎn)

（2）CSPM 管控的是對象的 Security Posture

（3）CSPM 管控能力覆蓋 prevention、detection 和

response

（4）CSPM 具備持續(xù)管控的能力

現(xiàn)在基本可以理解 CSPM 的定義和定位了。

這里也說下關(guān)于 CSPM 的中譯，看到不少文章將其

翻譯為云安全態(tài)勢感知。筆者很早前看到這個(gè)翻譯的時(shí)

候，最大的疑惑是既然翻譯成態(tài)勢，Gartner 為什么要用

Posture，而非用 situational。在相關(guān)介紹中，筆者亦發(fā)

現(xiàn) Gartner 解釋 CSPM 應(yīng)視為一個(gè)持續(xù)改進(jìn)和適應(yīng)云安全

配置的過程。綜合可見，CSPM 中的 Posture 是指配置，而

非態(tài)勢，所以將CSPM翻譯為云上安全配置管理是恰當(dāng)?shù)摹?/p>

另外，從當(dāng)前多數(shù) CSPM 實(shí)現(xiàn)管控的原理也能看到，

其對接的是對應(yīng)云管控環(huán)境中的配置審計(jì)等日志信息，

所以本質(zhì)上也是配置或云產(chǎn)品或服務(wù)基線管控的一部分。

當(dāng)然，乙方廠商在落地 CSPM 時(shí)也一直在夾“私貨”，

這里我主要 CSPM 的一些通用能力。

（二）CSPM 功能

根據(jù)筆者調(diào)研來看，CSPM 一般具備如下通用能力 :

1、云服務(wù)配置風(fēng)險(xiǎn)安全檢測能力。這個(gè)屬于 CSPM

的最基礎(chǔ)能力，是真正考驗(yàn)乙方廠商 CSPM 好壞的一個(gè)最

根本指標(biāo)。同時(shí)，該能力需要能夠支持自定義和調(diào)整。

2、合規(guī)檢測能力。例如可以支持國際上常見的 PCI

DSS、SOC 2、GDPR、RMiT 金融標(biāo)準(zhǔn)合規(guī)檢測；國內(nèi)常見

的等保三級、網(wǎng)絡(luò)合規(guī)管理檢測等。

3、多云管理能力。支持跨云檢測，如同時(shí)支持阿里

云、AWS、GCP 等。

4、自動(dòng)修正的能力。發(fā)現(xiàn)了云服務(wù)配置風(fēng)險(xiǎn)，支持

自動(dòng)進(jìn)行修復(fù)。

5、報(bào)表能力。各種炫酷的展示等等，算是Plus項(xiàng)了。

當(dāng)然，隨著 2020 年 CNAPP 的產(chǎn)生，CSPM 的功能和

定位也在持續(xù)擴(kuò)大。正如圖一顯示的那樣，CSPM 出現(xiàn)后，

Gartner 又提出了 CIEM、CNAPP 等名詞，希望更廣的覆

蓋云原生的安全防護(hù)。但是，確實(shí)名詞太多，各名詞功

能定位有重疊。筆者就與 CSPM 關(guān)聯(lián)性比較高的 2 個(gè)做下

對比介紹。

三、CSPM 關(guān)聯(lián)對比

（一）CSPM 與 CIEM

正如圖一所示，2020 年，Gartner 又提出了 CIEM，

即 Cloud infrastructure entitlement management ，

寄希望于解決賬號權(quán)限的風(fēng)險(xiǎn)。這里還是直接放下

Gartner 的原文定義：

CIEM offerings are specialized identitycentric SaaS solutions focused on managing cloud

access risk via administration-time controls for

the governance of entitlements in hybrid and

multicloud IaaS. They typically use analytics,

machine learning (ML) and other methods to

detect anomalies in account entitlements,

like accumulation of privileges, dormant and

unnecessary entitlements. CIEM ideally provides

remediation and enforcement of least privilege

approaches.

原文就不做解釋了。談下個(gè)人對 CIEM 的理解。

本質(zhì)上，CIEM 關(guān)注的是身份或賬號，這里的身份不

僅僅是從用戶側(cè)來看，同時(shí)還關(guān)注云基礎(chǔ)設(shè)施和服務(wù)的

權(quán)限。通過以最小權(quán)限原則來解決身份權(quán)限過大或不當(dāng)

的風(fēng)險(xiǎn)。不過，目前看到多數(shù)實(shí)現(xiàn) CIEM 的商用產(chǎn)品，仍

是以采用事中或事后監(jiān)控的邏輯來實(shí)現(xiàn)身份風(fēng)險(xiǎn)管理，

這本質(zhì)上與甲方訴求是有差距的。

另外，更尷尬的點(diǎn)出現(xiàn)了，CSPM 其實(shí)也可以用來解

決這個(gè)問題，而且在 CNAPP 云原生應(yīng)用保護(hù)平臺解決方

案中，也能發(fā)現(xiàn)這個(gè)控制點(diǎn)也被揉到了 CSPM 的功能中。

所以，從這個(gè)維度上看，CIEM 的地位是略尷尬的，但是

它的重要性不言而喻，CSPM 也扛不起這個(gè)大旗，后面會(huì)

進(jìn)一步解釋。