測量、監(jiān)控、報(bào)告和行動(dòng)DevSecOps工作組的官網(wǎng)地址是◎2025云安全聯(lián)盟一保留所有權(quán)利。您可以下載、存儲(chǔ)、在計(jì)算機(jī)上顯示、查看、打印并鏈接到云安全聯(lián)盟或其他聲明。在遵循中華人民共和國著作權(quán)法相關(guān)條款情況下合理使用本文內(nèi)容，使用時(shí)請注明引2高亞楠伏偉任卜宋博賀志生江澎林藝芳謝紹志(以上排名不分先后)4郵箱research@:國際云安全聯(lián)盟CSA公眾號。GCR秘書處給予雅正!聯(lián)系5目錄 4 8介紹 8 9目標(biāo)讀者 9使數(shù)據(jù)可觀察 9脆弱性的可觀測性 1.平均識(shí)別時(shí)間 2.平均補(bǔ)救時(shí)間 3.發(fā)展速度與脆弱性趨勢相對應(yīng) 安全架構(gòu)觀察 4.威脅量 5.計(jì)量控制 6.計(jì)量安全措施 7.威脅模型燃盡 8.采用安全模型 9.威脅場景與網(wǎng)絡(luò)風(fēng)險(xiǎn)映射 事件響應(yīng)的可觀察性 10.平均檢測時(shí)間(MeantimetodetectMTTD) 11.平均遏制時(shí)間(MeantimetocontainMTTC) 12.平均恢復(fù)時(shí)間(MeantimetorestorenormalityMTTRN) 團(tuán)隊(duì)間的成熟度比較 團(tuán)隊(duì)“Alpha”-低成熟度和效能 團(tuán)隊(duì)“Beta”-中等成熟度和效能 團(tuán)隊(duì)“Charlie”-高成熟度和效能 20三個(gè)團(tuán)隊(duì)之間的安全可觀察性 6跨團(tuán)隊(duì)的漏洞可觀察性 跨團(tuán)隊(duì)的安全架構(gòu)可觀察性 跨團(tuán)隊(duì)的事件響應(yīng)可觀測性 通過報(bào)告提高 28原則一使數(shù)據(jù)可訪問和可觀察 28原則-突出改進(jìn)機(jī)會(huì) 原則-突出變化，推動(dòng)持續(xù)改進(jìn) 原則-鼓勵(lì)溝通和協(xié)作 應(yīng)用這些報(bào)告原則 報(bào)告路線圖 結(jié)論 附錄A:軟件生命周期分解 參考資料 407前言云安全聯(lián)盟和SAFECode都致力于改善軟件安全成狀況。2019年8月發(fā)表的論文《DevSecOps的六個(gè)支柱》提供了高端方法論和成功實(shí)施解決方案，作者們使用這些方法和解決方案可以快速構(gòu)建軟件，并最小化安全相關(guān)錯(cuò)誤數(shù)量。這六個(gè)支柱是：支柱3:務(wù)實(shí)的實(shí)現(xiàn)(2022年12月14日發(fā)布)支柱6:測量、監(jiān)控、報(bào)告和行動(dòng)(2024年5月發(fā)布)支撐這些支柱的成功解決方案是云安全聯(lián)盟和SAFECode一系列更詳細(xì)的聯(lián)合出版物。本文是六個(gè)后續(xù)出版物的最后一篇。介紹DevSecOps舉措的實(shí)施和維護(hù)可能需要幾個(gè)月到幾年的時(shí)間。在考慮人員、流程和工具的大規(guī)模變化時(shí)，持續(xù)測量DevSecOps的成功和失敗是關(guān)鍵的差異化因素?！澳銦o法管理你不能測量的事物”這句話十分正確，沒有可操作的測量標(biāo)準(zhǔn)和可觀察性去測量績效，就無法理解進(jìn)步，無法復(fù)制成功，也無法意識(shí)到失敗。測量、監(jiān)測、報(bào)告和行動(dòng)的能力是任何成功的安全計(jì)劃的基本特征，以支持有效的決策。在本文中，我們探討：8●基于場景的修正：安全可觀察性概念應(yīng)用于高績效和低績效場景案例云安全聯(lián)盟的DevSecOps工作組(WG)在“DevSecOps的六個(gè)支柱”1中發(fā)布了高級別指南，倡導(dǎo)采用新的安全方法。這六個(gè)支柱被認(rèn)為是任何希望實(shí)施DevSecOps的組織需要重點(diǎn)關(guān)注的領(lǐng)域，其中一個(gè)支柱是"支柱6:測量、監(jiān)測、報(bào)支柱6的目標(biāo)是促進(jìn)和展示DevSecOps安全狀況的確切測量。這將使安全和數(shù)字領(lǐng)導(dǎo)者能夠確定其安全實(shí)踐的有效性，以及安全如何融入軟件開發(fā)生命周期。目標(biāo)讀者本文件的目標(biāo)讀者包括從事信息安全和信息技術(shù)管理和業(yè)務(wù)職能的人員。其團(tuán)隊(duì)、架構(gòu)、信息安全、治理和合規(guī)。使數(shù)據(jù)可觀察如果一個(gè)系統(tǒng)具備有效且可見的系統(tǒng)狀態(tài)數(shù)據(jù)，那么它就是可觀察的，這對于追根溯源至關(guān)重要。一個(gè)系統(tǒng)現(xiàn)狀的可觀察性測量基于其生生成的數(shù)據(jù)，如日志、指標(biāo)和跟蹤狀態(tài)。可觀測性旨在了解整體環(huán)境中發(fā)生的情況，以便檢測和解決問題，從而保持系統(tǒng)的高效和可靠性。組織采用可觀察性來幫助檢測和分析運(yùn)營、軟件開發(fā)生命周期、應(yīng)用程序安全和最終用戶體驗(yàn)中事件的影響程度。日志、指標(biāo)、分布式跟蹤和用戶體驗(yàn)的測量是實(shí)現(xiàn)可觀測性成功的關(guān)鍵支柱：9●指標(biāo)：是指計(jì)數(shù)或度量的值，通常在一段時(shí)間內(nèi)進(jìn)行計(jì)算或聚合。指標(biāo)可以來自各種來源，包括基礎(chǔ)設(shè)施、主機(jī)、服務(wù)、云平臺(tái)和外部來源·分布式跟蹤：事務(wù)或請求在應(yīng)用程序中流動(dòng)的代碼級別的詳細(xì)信息●用戶體驗(yàn)：在應(yīng)用程序上，甚至在生產(chǎn)前環(huán)境中，添加具體的、由外向內(nèi)用戶視角的數(shù)字化體驗(yàn)，擴(kuò)展傳統(tǒng)的遠(yuǎn)程可觀測性。一旦產(chǎn)品團(tuán)隊(duì)具備基于正確工具和工作流程的掃描機(jī)制，如靜態(tài)應(yīng)用程序安將十分簡單。而挑戰(zhàn)始于團(tuán)隊(duì)持續(xù)性開展掃描、修正和報(bào)告。隨著時(shí)間的推移，脆弱性積壓可能會(huì)增加，在某些情況下甚至?xí)黾拥綌?shù)以萬計(jì)，直到變得難以管理和補(bǔ)救。有效的脆弱性管理程序應(yīng)該在開發(fā)生命周期的早期發(fā)現(xiàn)并修復(fù)漏洞，以減少其平臺(tái)/產(chǎn)品的總體風(fēng)險(xiǎn)暴露。脆弱性的可觀察性要求識(shí)別以下三個(gè)屬性。MTTI是識(shí)別脆弱性所花費(fèi)的時(shí)間。較高的MTTI表明，在開發(fā)生命周期后期發(fā)現(xiàn)的脆弱性，將增加補(bǔ)救成本和將問題引入生產(chǎn)環(huán)境的風(fēng)險(xiǎn)。通過及早識(shí)別脆弱性，開發(fā)人員可以防止可利用脆弱性引入生產(chǎn)環(huán)境。在圖2中，識(shí)別時(shí)間為脆弱性暴露窗口的開始日期(1月10日)和識(shí)別所述脆弱性的日期(1月16日),因此，識(shí)別所需時(shí)間為7天。對數(shù)百個(gè)脆弱性進(jìn)行識(shí)別的時(shí)間會(huì)有所不同，MTTL是所有漏洞識(shí)別值的平均值。MTTR指示識(shí)別后修復(fù)脆弱性所花費(fèi)的平均時(shí)間。MTTR有助于跟蹤脆弱性是否被識(shí)別，是否被解析器團(tuán)隊(duì)“遺忘”。與MTTI一樣，MTTR可以根據(jù)嚴(yán)重性和接受風(fēng)險(xiǎn)的脆弱性數(shù)量進(jìn)行跟蹤圖2中，補(bǔ)救時(shí)間是識(shí)別日期(1月16日)和補(bǔ)救日期(2月10日)的差值，因此，補(bǔ)救所需時(shí)間為26天。與MTTI一樣，對數(shù)百個(gè)脆弱性進(jìn)行補(bǔ)救的時(shí)間不同，MTTR是所有漏洞補(bǔ)救值的平均值。開發(fā)速度是否超過了修復(fù)脆弱性的能力?跟蹤這一趨勢有助于確定開發(fā)團(tuán)隊(duì)是否在開發(fā)和運(yùn)營過程中難以跟上脆弱性補(bǔ)救的步伐，以及補(bǔ)救是否與發(fā)展速度保持同步。MTTI/MTTR可以根據(jù)發(fā)展速度和嚴(yán)重程度評分進(jìn)行跟蹤。這可以幫助確定開發(fā)團(tuán)隊(duì)和安全團(tuán)隊(duì)在脆弱性管理中是否存在脫節(jié)。在圖2中，脆弱性暴露窗口(1月10日-2月10日)跨越了兩個(gè)發(fā)布窗口。此值將有助于提供上下文信息，以幫助證明MTTI和MTTR值的正確性。以下可觀察因素旨在指導(dǎo)開發(fā)團(tuán)隊(duì)開展可接受程度威脅建模工作及其補(bǔ)救活動(dòng)。組織可以利用這些改進(jìn)他們的威脅建模模式和形式。跟蹤從威脅建模工作中識(shí)別出的威脅數(shù)量、威脅類型和相應(yīng)的控制。將有助于了解是否采用了縱深防御方法。圖3演示了對STRIDE(欺騙、篡改、抵賴、信息泄露、拒絕服務(wù)、特權(quán)提升)應(yīng)用于每個(gè)威脅主題的控制量。深度防御平均值是每個(gè)STRIDE威脅類型的控制覆蓋率平均值?？梢杂^察到，本例中的信息披露是最普遍的威脅，因?yàn)樗成涞目刂屏孔罡摺ａ槍耐{建模工作中識(shí)別到的威脅，跟蹤相應(yīng)的控制措施。這有助于了解補(bǔ)救活動(dòng)是否按規(guī)模進(jìn)行了優(yōu)化。例如，單個(gè)控件具有多個(gè)用途。圖4演示了通常從威脅模型中識(shí)別出的控件的示例集，以及每個(gè)控制用于解決威脅的用法。這衡量了每個(gè)控件的投資回報(bào)率(ROI)。在本例中，基于角色的訪問控制(RBAC)和安全監(jiān)控這兩項(xiàng)控制所能處理的威脅最多，投資回報(bào)率最高，這提示了應(yīng)該優(yōu)先考慮相關(guān)控制措施。而每個(gè)控制措施可平均處理5到6個(gè)威脅用為應(yīng)對已識(shí)別的脆弱性/威脅而轉(zhuǎn)換為安全措施的控制量。這有助于了解環(huán)境是否得到了保護(hù)，以防止風(fēng)險(xiǎn)、威脅或脆弱性發(fā)生。圖5顯示了隨著時(shí)間推移的安全措施的實(shí)施情況，強(qiáng)調(diào)了針對威脅狀況采取預(yù)防性安全措施的重要性。衡量對威脅的控制狀況是威脅建模的一項(xiàng)關(guān)鍵輸出。通過跟蹤已識(shí)別狀況與當(dāng)前實(shí)施狀況，團(tuán)隊(duì)可以評估威脅建模的有效性，驗(yàn)證威脅建模對開發(fā)過程的價(jià)值賦能狀況。圖5顯示了威脅模型的燃盡情況，通過實(shí)施控制，在5個(gè)沖刺階段(10周)內(nèi)將25個(gè)未解決的威脅減少到10個(gè)。這種類型的衡量將證明威脅模型實(shí)施是否成功。在這個(gè)例子中，在10周內(nèi)實(shí)施的控制措施中，有60%是良好的做法。分析安全設(shè)計(jì)模型的實(shí)施情況是評價(jià)安全架構(gòu)成熟度的衡量方法。安全模式是一種可重用的解決方案，可解決軟件或系統(tǒng)設(shè)計(jì)中的常見安全挑戰(zhàn)和漏洞。它可以是一份工作文檔，也可以是一段可重復(fù)使用的代碼(模板)。通常情況下，一個(gè)更成熟的組織會(huì)有更多的模型和模板，以確保遵循一致的設(shè)計(jì)/工程實(shí)踐。完善的模型有助于提高重復(fù)性和一致性，減少重復(fù)出現(xiàn)的弱點(diǎn)和漏洞的數(shù)量。缺乏采用可能表明團(tuán)隊(duì)沒有意識(shí)到這些模型的存在，或者模型并不有效。圖表6中，模型/模板數(shù)量為20個(gè)，采用率僅為70%,表明六種模型存在效率低下的問題。計(jì)量威脅，為風(fēng)險(xiǎn)聲明提供說明，即有多少威脅與某個(gè)風(fēng)險(xiǎn)聲明相對應(yīng)。與風(fēng)險(xiǎn)不同，威脅是無法緩解的；但是，威脅是可以應(yīng)對的，并可用于提供風(fēng)險(xiǎn)信圖表6展示了這一指標(biāo)。在該示例中，敏感數(shù)據(jù)暴露風(fēng)險(xiǎn)與14個(gè)威脅有關(guān)；所以，從理論上講，處理這14個(gè)威脅能降低敏感數(shù)據(jù)暴露的風(fēng)險(xiǎn)分?jǐn)?shù)。Threatthemevolume(againstcontrolstoimDefenceindepth=6.3(eachthrvolume(addressingthrecontroladdressosonavandsecuritymonitoringcontrolsrepresenttoolsprocessesand◎2025云安全聯(lián)盟大中華區(qū)版權(quán)所有—Threatvolume(unaddressedthreat)—Threatvolume(unaddressedthreat)Controlvolume(implementedtoaddressControlimplementodasguardrail(pmventativemProductreleases(every2weeks)Controthreshold(60%ofcontrolsThreatsaddressedovertime(15addressedin>10controlsimplementedasguardrallsThreatremedationplateau(10其他指標(biāo)：共有31/34個(gè)威脅與3個(gè)風(fēng)險(xiǎn)聲明有關(guān)聯(lián)，平均每個(gè)風(fēng)險(xiǎn)有11.3個(gè)威脅。3個(gè)威脅因不屬于業(yè)務(wù)風(fēng)險(xiǎn)而未被計(jì)算。風(fēng)險(xiǎn)1:"敏感數(shù)據(jù)暴露風(fēng)險(xiǎn)"被14個(gè)威脅中提及風(fēng)險(xiǎn)2:"數(shù)據(jù)完整性受損"被6個(gè)威脅中提及IT服務(wù)不可用"被11個(gè)威脅中提及模型/模板數(shù)量為20個(gè)，整個(gè)項(xiàng)目的采用率為70%。表明有6個(gè)模式/模板需要修改或刪除。事件響應(yīng)的可觀察性提供了對警報(bào)和檢測的洞察力，進(jìn)而可進(jìn)行更詳細(xì)、更翔實(shí)的事件后審查。平均檢測時(shí)間(MTTD)、平均遏制時(shí)間(MTTC)和平均恢復(fù)時(shí)間(MTTRN)是關(guān)鍵指標(biāo)，可讓企業(yè)在安全漏洞導(dǎo)致故障發(fā)生時(shí)迅速采取行動(dòng)。對IT產(chǎn)業(yè)的安全監(jiān)控可以讓企業(yè)捕捉到這些指標(biāo)，讓運(yùn)營團(tuán)隊(duì)在事故期間獲得必要的數(shù)據(jù)。MTTD是指團(tuán)隊(duì)發(fā)現(xiàn)潛在安全事件所需的時(shí)間。MTD高的組織由于不能及早發(fā)現(xiàn)事件，會(huì)帶來額外的不必要風(fēng)險(xiǎn)。早期檢測(識(shí)別)意味著團(tuán)隊(duì)可以盡早專注于響應(yīng)和恢復(fù)工作，減少對生產(chǎn)的影響。在圖表7中，檢測(識(shí)別)時(shí)間為暴露窗口的開始日期(12月31日)和確定所述事件的日期(1月1日),因此識(shí)別時(shí)間為兩天。在數(shù)百個(gè)事件中，識(shí)別/檢測時(shí)間會(huì)有所不同，MTTD是所有事件檢測值的平均值。MTTC指跟蹤控制安全漏洞/事件所需的時(shí)間。這有助于了解應(yīng)對安全事件的速度。遏制是指團(tuán)隊(duì)可以開始限制和減少事件的影響；避免對依賴服務(wù)造成影響或避免漏洞的橫向移動(dòng)。在圖表7中，遏制時(shí)間是從檢測日期(1月1日)到遏制日期(1月6日),因此遏制時(shí)間為6天。在數(shù)百起事件中，遏制時(shí)間會(huì)有所不同，MTTC是所有事件控制值的平均值。MTTRN表示事件修復(fù)過程中恢復(fù)正常所需的平均時(shí)間。較慢的MTTRN會(huì)導(dǎo)致服務(wù)中斷，影響組織的運(yùn)作能力或產(chǎn)品的有效工作能在圖表7中，恢復(fù)正常所需的時(shí)間從檢測日期(1月1日)開始，到補(bǔ)救所述事件的日期(1月25日)結(jié)束，因此恢復(fù)正常所需的時(shí)間為25天。在許多事件中，恢復(fù)正常的時(shí)間會(huì)有所不同；MTT◎2025云安全聯(lián)盟大中華區(qū)版權(quán)所有團(tuán)隊(duì)間的成熟度比較理解DevSecOps實(shí)踐對團(tuán)隊(duì)效能的影響，需要一種全面的方法來衡量、監(jiān)控、報(bào)告以及根據(jù)指標(biāo)采取行動(dòng)。為了提供不同實(shí)踐成熟度和效能的概覽，描述了三個(gè)在不同組織中處于不同成熟度水平的團(tuán)隊(duì)及其對指標(biāo)影響的示例情景。情景對比采用了OWASP的DevSecOps成熟度模型(DSOMM)。團(tuán)隊(duì)分別被標(biāo)記為Alpha、Beta和Charlie,對應(yīng)低、中、高成熟度及效能水平。通過情景對比，我們獲得了這些實(shí)踐在實(shí)際應(yīng)用中的洞見，以及它們對DevSecOps實(shí)踐的影響。關(guān)注點(diǎn)并不在于將團(tuán)隊(duì)標(biāo)定為‘好’或‘壞’,而是突出這些實(shí)踐在可觀察指標(biāo)以及整體成熟度和效能上的不同影響。Alpha團(tuán)隊(duì)在DevSecOps實(shí)踐方面處于較低的成熟度水平。這個(gè)團(tuán)隊(duì)在DSOMM的第1至第2級之間運(yùn)作，對相關(guān)的DevSecOps實(shí)踐具有基礎(chǔ)的理解和采納。Alpha團(tuán)隊(duì)仍處在適應(yīng)DevSecOps的早期階段。團(tuán)隊(duì)在修復(fù)可被利用的漏洞方面反應(yīng)遲緩，并且在確保設(shè)計(jì)中內(nèi)置安全性的方法上缺乏一致性。延遲的事件處理凸顯了對更好安全實(shí)踐和培訓(xùn)的需求。Beta團(tuán)隊(duì)在DSOMM的第2至第3級之間運(yùn)作，展現(xiàn)了他們在DevSecOps實(shí)踐中的中等成熟度。盡管他們已經(jīng)超越了DevSecOps的基礎(chǔ)階段，但他們處理漏洞的方式可以被描述為適度的反應(yīng)式，而非主動(dòng)式。在設(shè)計(jì)階段嵌入安全性的承諾顯示出一定程度的不一致性，偶爾會(huì)導(dǎo)致潛在威脅被忽視。此外，雖然他們對事件的響應(yīng)速度明顯快于該領(lǐng)域中成熟度較低的團(tuán)隊(duì)，但仍存在改進(jìn)的空間。Charlie團(tuán)隊(duì)在其DevSecOps實(shí)踐方面展現(xiàn)出高級別成熟度和效能，達(dá)到了DSOMM的第3和第4級。各項(xiàng)指標(biāo)體現(xiàn)出高度的DevSecOps成熟度。Charlie團(tuán)隊(duì)的實(shí)踐與指標(biāo)不僅反映出高水平的技術(shù)專業(yè)能力，還體現(xiàn)了一種將安全放在首位并在每一個(gè)步驟中加以整合的文化。這使得安全性得以在所有階段中持續(xù)嵌入，從而減小了攻擊面并提升了安全姿態(tài)。盡管事件響應(yīng)既高效又及時(shí)，Charlie團(tuán)隊(duì)仍然保持著持續(xù)改進(jìn)的心態(tài)。這保證了事件響應(yīng)能夠適應(yīng)不斷變化的安全威脅。通過對比場景，性能成熟度的影響變得顯而易見。這些場景強(qiáng)調(diào)了持續(xù)測量的重要性，它為明智的決策、成功復(fù)制實(shí)踐以及識(shí)別需要改進(jìn)的領(lǐng)域奠定了基礎(chǔ)。它們最終成為組織提升其DevSecOps實(shí)踐和文化的指南。圖8證實(shí)了使用經(jīng)過的天數(shù)對MTTI和MTTR進(jìn)行平均和評分的概念，展示了隨著時(shí)間的推移而取得的改進(jìn)。圖9代表隨時(shí)間變化的團(tuán)隊(duì)間比較，顯示了團(tuán)隊(duì)表現(xiàn)的高低。Alpha團(tuán)隊(duì)的低成熟度實(shí)踐導(dǎo)致大量漏洞被利用，而Beta團(tuán)隊(duì)的中等成熟度實(shí)踐使漏洞數(shù)量減少。Charlie團(tuán)隊(duì)?wèi){借其高成熟度實(shí)踐，擁有最少的可利用漏洞。MTTI:在新漏洞出現(xiàn)后，Alpha團(tuán)隊(duì)平均需要20天才能識(shí)別出一個(gè)新漏洞。由于建立了每周定期的漏洞掃描，Beta團(tuán)隊(duì)將識(shí)別新漏洞的時(shí)間縮短到了15天。然而，Beta團(tuán)隊(duì)實(shí)時(shí)掃描生產(chǎn)代碼庫，不會(huì)讓相應(yīng)的漏洞出現(xiàn)在生產(chǎn)環(huán)境中。由于持續(xù)集成和持續(xù)部署(CI/CD)實(shí)踐，在開發(fā)測試環(huán)境的源代碼庫中使用自動(dòng)化安全掃描，Charlie團(tuán)隊(duì)能夠在幾天內(nèi)以較低的MTTI檢測到漏洞。會(huì)隨著時(shí)間的推移而增加。Beta團(tuán)隊(duì)已經(jīng)建立了一個(gè)緩解流程，由于難以及時(shí)解MTTI:TheMTTI:Thetimetakentovulnerabilityscanningtools,techniques,andfrequencMTTR:Thetimetakentoremedreducedfrom25daysto17days.ThiscouldphigherprioritisationofremedFigure8:Conceptualobservabilit圖10證明了通過平均深度防御和控制重用得分的概念，并展示了隨時(shí)間的改進(jìn)。圖11和圖12代表了跨團(tuán)隊(duì)隨時(shí)間的比較，為實(shí)施和威脅消減提供了高和低表現(xiàn)的指示。Alpha團(tuán)隊(duì)缺乏正式的安全架構(gòu)實(shí)踐，導(dǎo)致控制措施難以落實(shí)，而Beta團(tuán)隊(duì)的中等實(shí)踐顯示出逐漸改進(jìn)。Charlie團(tuán)隊(duì)的最佳實(shí)踐使安全架構(gòu)可觀測性水平高，控制措施在短時(shí)期內(nèi)落實(shí)到位。防御深度和控制復(fù)用：Alpha團(tuán)隊(duì)在多次風(fēng)險(xiǎn)評估中經(jīng)常發(fā)現(xiàn)相同的威脅，這表明重復(fù)的安全威脅沒有策略進(jìn)行有效緩解。雖然Beta團(tuán)隊(duì)在評估期間在識(shí)別各種威脅方面取得了進(jìn)展，但他們威脅建模練習(xí)的延遲有時(shí)會(huì)導(dǎo)致漏洞被忽視。Charlie團(tuán)隊(duì)利用一個(gè)明確的威脅建模過程來預(yù)測和緩解各種威脅，該過程可以在其他開發(fā)團(tuán)隊(duì)中推廣使用，并且定期的回顧會(huì)議確保團(tuán)隊(duì)從過去的威脅場景中學(xué)習(xí)并增強(qiáng)其威脅緩解策略。威脅和控制量：Alpha團(tuán)隊(duì)在設(shè)計(jì)階段確定了必要的安全控制，但在生產(chǎn)過程中只實(shí)施了其中的一小部分。例如，雖然他們認(rèn)識(shí)到加密的必要性，但只在存儲(chǔ)過程中實(shí)現(xiàn)加密，在數(shù)據(jù)傳輸過程中卻沒有實(shí)現(xiàn)。Beta團(tuán)隊(duì)經(jīng)常意識(shí)到集成安全控制的重要性，例如在存儲(chǔ)和傳輸級別都進(jìn)行加密。然而，識(shí)別和實(shí)施之間的延遲，意味著并非所有已識(shí)別的控制措施都會(huì)立即嵌入到應(yīng)用程序中。Charlie的安全控制得到了迅速實(shí)施。例如，在確定端到端加密的需求后，團(tuán)隊(duì)通過自動(dòng)化部署腳本來管理、強(qiáng)制執(zhí)行安全配置，確保它在存儲(chǔ)、傳輸和處理過程中都得到應(yīng)addressthreatshasinereasedfromanaverageof1controladdressing2threatsecureproduct,andpotentialcosteffi一一Alpha團(tuán)隊(duì)缺乏正式的事件響應(yīng)計(jì)劃，導(dǎo)致事件響應(yīng)行動(dòng)的可觀察性較差。Beta團(tuán)隊(duì)的基本計(jì)劃提高了可觀察性，而Charlie團(tuán)隊(duì)定義明確且定期更新的計(jì)劃帶來了出色的事件響應(yīng)可觀察性。平均故障發(fā)現(xiàn)時(shí)間(MTTD):Alpha團(tuán)隊(duì)缺乏有效的監(jiān)控工具和實(shí)踐，導(dǎo)致平均故障發(fā)現(xiàn)時(shí)間(MTTD)延長，平均為19天，并且隨著時(shí)間的推移而增加?；谝延斜O(jiān)控能力，Beta團(tuán)隊(duì)將這一時(shí)間縮短到15天，并隨著時(shí)間的推移顯示出改進(jìn)的跡象。然而，由于流程和人員配備不足，出現(xiàn)了改進(jìn)停滯不前的情況。Charlie團(tuán)隊(duì)擁有一套強(qiáng)大的檢測和響應(yīng)能力以及穩(wěn)健的流程，這意味著它能夠在幾天內(nèi)發(fā)現(xiàn)并解決故障，維持較低的MTTD。平均故障確認(rèn)時(shí)間(MTTC)+平均故障解決時(shí)間(MTTRN):對于Alpha來--Meantimetofrom10daysto4days.ThisprioritisationonresponseMTTRN:Thetimetaketorestorenormality◎2025云安全聯(lián)盟大中華區(qū)版權(quán)所有Figure14:ComparisonbetweenFigure15:Comparisonbetweenteams-MTTCandMTTRN報(bào)告是組織在嵌入安全性時(shí)應(yīng)該考慮的一個(gè)關(guān)鍵方面，因?yàn)樗粌H提供了當(dāng)前安全狀況的視圖，還為高層領(lǐng)導(dǎo)提供了評估和管理風(fēng)險(xiǎn)、安全預(yù)算和資源的能力。通過報(bào)告實(shí)現(xiàn)持續(xù)改進(jìn)，關(guān)鍵在于確定哪些信息對項(xiàng)目團(tuán)隊(duì)來說是相關(guān)的，哪些應(yīng)該報(bào)告給高層管理。這遠(yuǎn)不止是簡單地分享由安全解決方案提供的漏洞報(bào)告那么簡單。這里描述了四個(gè)原則及其應(yīng)用，在構(gòu)建報(bào)告以為組織帶來最大收益時(shí)應(yīng)該考慮這些原則，并提供了一條通往報(bào)告成功的路線圖。原則-使數(shù)據(jù)可訪問和可觀察通過收集和表達(dá)有意義的數(shù)據(jù)，組織能夠評估當(dāng)前的安全狀況，并進(jìn)行趨勢分析和風(fēng)險(xiǎn)緩解?？赡塬@得的好處包括：團(tuán)隊(duì)能更好地識(shí)別潛在的風(fēng)險(xiǎn)和漏洞，從而采取主動(dòng)的風(fēng)險(xiǎn)緩解策略。額外安全措施的領(lǐng)域。這會(huì)導(dǎo)致對安全的投資增加，特別是通過持續(xù)改進(jìn)的舉措。夠?yàn)槲磥淼陌踩魬?zhàn)做好準(zhǔn)備。它使組織能夠適應(yīng)和響應(yīng)新興的威脅。生時(shí)，可快速獲取數(shù)據(jù)，縮短檢測、控制和恢復(fù)正常業(yè)務(wù)運(yùn)營的時(shí)間。原則-突出改進(jìn)機(jī)會(huì)這一原則在報(bào)告領(lǐng)域扮演著關(guān)鍵角色，它著眼于確定DevSecOps實(shí)踐中需要改進(jìn)的領(lǐng)域。它為提升創(chuàng)造了機(jī)會(huì)。這些機(jī)會(huì)并不局限于技術(shù)層面，還可能涉及改善事故響應(yīng)計(jì)劃、員工培訓(xùn)或采用新的安全工具和實(shí)踐等更廣泛的范疇。從這種報(bào)告中可獲得的好處包括但不限于：·增強(qiáng)安全狀況：直接識(shí)別并解決改進(jìn)領(lǐng)域可以提高安全狀況的穩(wěn)健性。通過主動(dòng)解決漏洞和弱點(diǎn)，組織可以更好地防御潛在威脅?！癯掷m(xù)改進(jìn)：識(shí)別和解決改進(jìn)機(jī)會(huì)，培養(yǎng)組織內(nèi)部的持續(xù)改進(jìn)文化。團(tuán)隊(duì)可以從過·量身定制的解決方案：報(bào)告使組織能夠針對具體挑戰(zhàn)和弱點(diǎn)量身定制解決方案。例如，如果發(fā)現(xiàn)培訓(xùn)存在差距，可以開發(fā)針對性的培訓(xùn)計(jì)劃來解決這些具體需求。持超越新興威脅的能力。原則-突出變化，推動(dòng)持續(xù)改進(jìn)這一原則強(qiáng)調(diào)了報(bào)告作為推動(dòng)組織持續(xù)改進(jìn)的重要機(jī)制。它強(qiáng)調(diào)需要通過學(xué)習(xí)和發(fā)展計(jì)劃來提高安全意識(shí)和文化。實(shí)施這一原則通常表現(xiàn)為為員工制定全面的學(xué)習(xí)和發(fā)展(L&D)計(jì)劃，旨在提升組織的整體安全意識(shí)。應(yīng)用這一原則可帶來以●增強(qiáng)學(xué)習(xí)文化：通過報(bào)告突出變化，增強(qiáng)了組織重和采取報(bào)告洞見，員工被鼓勵(lì)不斷學(xué)習(xí)新的技能和知識(shí)?！?dòng)態(tài)適應(yīng)安全需求：隨著報(bào)告突出組織安全狀況的不斷變化需求，態(tài)適應(yīng)。這意味著，當(dāng)發(fā)現(xiàn)新的漏洞時(shí)，組織能夠快速調(diào)整其策略和培訓(xùn)計(jì)劃來解決這些具體領(lǐng)域。中吸取教訓(xùn)并實(shí)施變革，可降低重復(fù)事故的可能性，從而提高處理安全事故的總體響應(yīng)能力，包括平均修復(fù)時(shí)間(MTTR)、平均檢測時(shí)間(MTTD)和平均恢復(fù)時(shí)間(MTTRN)?！裰鲃?dòng)風(fēng)險(xiǎn)管理：由報(bào)告驅(qū)動(dòng)的持續(xù)改進(jìn)使組織從被動(dòng)轉(zhuǎn)向主動(dòng)。通過模式，組織可以預(yù)測并減輕風(fēng)險(xiǎn)，在其變成安全漏洞之前就得到緩解。原則一鼓勵(lì)溝通和協(xié)作鼓勵(lì)通過報(bào)告進(jìn)行溝通和協(xié)作的原則是構(gòu)建統(tǒng)一方法的核心。通過提供組織安全實(shí)踐和DevSecOps活動(dòng)的概覽，報(bào)告可以增強(qiáng)理解和合作。這不僅支持當(dāng)前的安全需求，還為組織未來應(yīng)對和管理安全挑戰(zhàn)做好準(zhǔn)備。這種協(xié)作性報(bào)告方法帶來的好處包括：出明智決策。這種參與對于獲得必要的資源和關(guān)注安全相關(guān)事項(xiàng)至關(guān)重要。●意識(shí)和風(fēng)險(xiǎn)識(shí)別：通過持續(xù)報(bào)告，可以促于及早發(fā)現(xiàn)和管理組織內(nèi)部的潛在安全威脅至關(guān)重要。明安全問題及其管理情況，它增強(qiáng)了一種安全成為組織文化組成部分的思維方式。當(dāng)這些團(tuán)隊(duì)在安全目標(biāo)和實(shí)踐方面保持一致時(shí)，組織就能更有效地應(yīng)對這些挑戰(zhàn)。施。這種"向左轉(zhuǎn)移"的方法確保在開發(fā)過程的早期就考慮安全因素，從而減少潛在漏洞并簡化補(bǔ)救工作。使數(shù)據(jù)可訪問、突出機(jī)遇、推動(dòng)持續(xù)改進(jìn)以及鼓勵(lì)溝通和協(xié)作的這四項(xiàng)原則，對于推動(dòng)通過報(bào)告實(shí)現(xiàn)改進(jìn)至關(guān)重要。這些原則共同構(gòu)成了一個(gè)全面的方法，用于測量和改善DevSecOps生命周期中的安全性。當(dāng)這些原則融入報(bào)告過程時(shí)，組織可將其安全指標(biāo)從被動(dòng)數(shù)據(jù)點(diǎn)轉(zhuǎn)變?yōu)橹鲃?dòng)的安全治理和戰(zhàn)略決策工具。您的旅程指南我們?nèi)绾尾拍軐⑺季S轉(zhuǎn)變?yōu)椤鞍踩?績效=價(jià)值”的思維模式?3確定項(xiàng)目/活動(dòng)的優(yōu)先級并有效分配預(yù)算。確保您能夠持續(xù)收集數(shù)據(jù)。您已配備好數(shù)據(jù)點(diǎn)/工進(jìn)行了威脅建模。23不要各自為政。不要各自為政。安全利益相關(guān)者。導(dǎo)支持，就可以橫向擴(kuò)展多個(gè)項(xiàng)目。4◎2025云安全聯(lián)盟大中華區(qū)版權(quán)所有在任何數(shù)字項(xiàng)目或組織中實(shí)施安全性絕非易事。為了獲利，企業(yè)往往會(huì)加快發(fā)布功能的速度，以搶占市場份額。基基礎(chǔ)設(shè)施和應(yīng)用程序的設(shè)計(jì)和構(gòu)建是根據(jù)績效指標(biāo)(即部署速度、創(chuàng)建功能所需的時(shí)間、測試時(shí)間)來衡量，其也非常適合衡量業(yè)務(wù)目標(biāo)。相比之下，安全性非常有效地通過合規(guī)性而非績效來衡量成功。改進(jìn)安全功能的能力往往會(huì)使團(tuán)隊(duì)/產(chǎn)品變得更加合規(guī)。合規(guī)性和績效有時(shí)可能是對立的力量，需要微妙的平衡，以避免人們認(rèn)為“安全是阻礙因素”。本文提供了實(shí)證證據(jù)，表明使用績效指標(biāo)可以有效評估安全性和DevSecOps的三個(gè)關(guān)鍵方面。我們計(jì)算項(xiàng)目/組織在管理漏洞、構(gòu)建安全服務(wù)和響應(yīng)事件方面的表現(xiàn)，從而提供安全可觀測性。安全可觀測性為企業(yè)領(lǐng)導(dǎo)者提供了有效的衡量標(biāo)準(zhǔn)，讓他們了解安全效率和性能，最重要的是，還了解了需要進(jìn)一步投資和變革的地方。CSADevSecOps工作組將繼續(xù)研究提供安全可觀測性見解，并擴(kuò)展附錄B中的用例范圍。在將安全性納入軟件開發(fā)生命周期(SDLC)時(shí)，組織有多種工具和解決方案可供選擇。在“支柱3:務(wù)實(shí)的實(shí)現(xiàn)”中，我們探討了將安全融入軟件開發(fā)生命周期(SDLC)的設(shè)計(jì)、編碼、測試、部署和監(jiān)控階段的不同安全活動(dòng)。使用專注于應(yīng)用程序開發(fā)和平臺(tái)安全的與框架無關(guān)的DevSecOps模型，我們分解了圖1中的各個(gè)階段，其中可以識(shí)別指標(biāo)以提供數(shù)據(jù)(參見附錄B)。雖然不同定義中的SDLC有差異性階段劃分，但五階段SDLC(參見圖1:設(shè)計(jì)、編碼、集成和測試、部署和監(jiān)控)提供了軟件開發(fā)的通用視圖。我們認(rèn)識(shí)到，工具和解決方案可能難以部署和實(shí)施，而且難以擴(kuò)展。當(dāng)前人們的普遍看法是，現(xiàn)有解決方案可能無法提供有助于降低安全風(fēng)險(xiǎn)。我們挖掘如何使用DevSecOps階段的度量指標(biāo)來評價(jià)DevSecOps相關(guān)活動(dòng)中的安全性能。安全設(shè)計(jì)與架構(gòu)交安全編碼庫代碼檢杏GitOps護(hù)欄運(yùn)行時(shí)防御與監(jiān)控觸發(fā)條件從表1中的每個(gè)階段，我們已經(jīng)確定了一份可能的度量標(biāo)準(zhǔn)的廣泛列表，以鼓勵(lì)整體決策。每個(gè)度量標(biāo)準(zhǔn)反映了各行業(yè)的產(chǎn)品和安全團(tuán)隊(duì)的常見●每個(gè)組件，功能和特征的威脅向量●完成威脅建模演練的時(shí)間●應(yīng)對威脅的成本和時(shí)間●安全控制/威脅比率●重復(fù)使用(現(xiàn)有)安全控制的占比●產(chǎn)品功能的安全控制占比●涉及安全要求和驗(yàn)收標(biāo)準(zhǔn)的公開占比●安全故事集●安全故事與功能故事的占比●完成安全用戶故事所需的時(shí)間●安全工作的平均交付周期●開發(fā)過程中發(fā)現(xiàn)并修復(fù)的問題占比●測試過程中發(fā)現(xiàn)并修復(fù)的問題占比●設(shè)計(jì)過程中的風(fēng)險(xiǎn)識(shí)別量●設(shè)計(jì)變更帶來的風(fēng)險(xiǎn)緩解量●設(shè)計(jì)過程中風(fēng)險(xiǎn)解決(減輕，轉(zhuǎn)移，接受，避免)的占比●在設(shè)計(jì)過程中識(shí)別和記錄風(fēng)險(xiǎn)所需的平均時(shí)間●架構(gòu)原則工作量●產(chǎn)品團(tuán)隊(duì)在設(shè)計(jì)過程中符合架構(gòu)原則的占比●安全架構(gòu)審查量編碼●開發(fā)人員/工程師參與安全和隱私培訓(xùn)的占比●一段時(shí)間內(nèi)的經(jīng)驗(yàn)教訓(xùn)數(shù)量●在預(yù)提交時(shí)被拒絕的代碼更改占比●在提交后通知的占比●在合并前同行評審的代碼更改的占比●已進(jìn)行代碼審查的占比●總代碼靜態(tài)檢查錯(cuò)誤的數(shù)量●修復(fù)靜態(tài)檢查錯(cuò)誤所需的時(shí)間●符合組織許可/通過SCA掃描的開源組件占比●發(fā)現(xiàn)的許可問題數(shù)量●生產(chǎn)中使用的產(chǎn)品未解決的許可問題數(shù)量●最新依賴項(xiàng)的占比●具有已知漏洞的依賴項(xiàng)數(shù)量●更新依賴項(xiàng)所需的平均時(shí)間●已掃描的IAC代碼占比●已掃描的源代碼占比●跨代碼庫的檢查量(按語言分類)●由于安全配置錯(cuò)誤被拒絕的IAC部署量●發(fā)現(xiàn)的安全問題數(shù)量●SAST誤報(bào)率的占比●處理從SAST/IAC掃描中發(fā)現(xiàn)的安全問題的安全票據(jù)數(shù)量●在生產(chǎn)中使用的加固容器的占比●加固容器更新的平均頻率●容器不合規(guī)覆蓋的數(shù)量(根據(jù)CIS基準(zhǔn)或其他標(biāo)準(zhǔn))●與安全相關(guān)的單元測試結(jié)果的占比●安全單元測試的吞吐時(shí)間●成功和失敗測試的通過率●進(jìn)行同行評審的安全漏洞代碼和架構(gòu)更改的占比部署●部署頻率和成功率●將基礎(chǔ)設(shè)施部署到生產(chǎn)環(huán)境所需的平均時(shí)間●識(shí)別配置偏差所需的平均時(shí)間●修正配置偏差所需的平均時(shí)間●修復(fù)配置偏差所需的手動(dòng)干預(yù)步驟平均數(shù)·轉(zhuǎn)換