《云安全聯盟：2025年DevSecOps六大支柱：測量、監控、報告和行動報告（43頁）.pdf》由會員分享，可在線閱讀，更多相關《云安全聯盟：2025年DevSecOps六大支柱：測量、監控、報告和行動報告（43頁）.pdf（43頁珍藏版）》請在三個皮匠報告上搜索。

1、 2025 云安全聯盟大中華區版權所有1 2025 云安全聯盟大中華區版權所有2DevSecOps 工作組的官網地址是https:/cloudsecurityalliance.org/research/working-groups/devsecops/2025 云安全聯盟 保留所有權利。您可以下載、存儲、在計算機上顯、查看、打印并鏈接到云安全聯盟 https:/cloudsecurityalliance.org 但須遵守以下規定：(a)草案僅可于個、信息、商業途；(b)不得以任何式修改或更改草案；(c)不得重新分發草案；(d)不得刪除商標、版權或其他聲明。在遵循中華人民共和國著作權法相關條款情

2、況下合理使用本文內容，使用時請注明引用于云安全聯盟大中華區。2025 云安全聯盟大中華區版權所有4致致謝謝中中文文版版翻翻譯譯專專家家翻翻譯譯組組成成員員：高亞楠伏偉任卜宋博賀志生江澎林藝芳謝紹志王彪審審校校組組成成員員：李巖王彪（以上排名不分先后）2025 云安全聯盟大中華區版權所有5英英文文版版編編寫寫專專家家主主要要作作者者：Dan GoraRoupe Sahans貢貢獻獻者者：Alex BrownDaniel ParkinMichael Roca審審閱閱者者：Roland MJulianna TchebotarevaTimothy ThatcherUdith WCSA 分分析析師師：J

3、osh BukerCSA 全全球球員員工工：Claire Lehnert在此感謝以上專家及單位。如譯文有不妥當之處，敬請讀者聯系CSA GCR秘書處給予雅正！聯系郵箱researchc-；國際云安全聯盟CSA公眾號。2025 云安全聯盟大中華區版權所有6目錄致謝.4前言.8介紹.8目標.9目標讀者.9使數據可觀察.9脆弱性的可觀測性.101.平均識別時間.102.平均補救時間.113.發展速度與脆弱性趨勢相對應.11安全架構觀察.124.威脅量.125.計量控制.136.計量安全措施.137.威脅模型燃盡.138.采用安全模型.149.威脅場景與網絡風險映射.14事件響應的可觀察性.1710.

4、平均檢測時間（Mean time to detectMTTD）.1711.平均遏制時間（Mean time to containMTTC）.1712.平均恢復時間（Mean time to restore normality MTTRN）.18團隊間的成熟度比較.19團隊“Alpha”-低成熟度和效能.19團隊“Beta”-中等成熟度和效能.19團隊“Charlie”-高成熟度和效能.20三個團隊之間的安全可觀察性.20 2025 云安全聯盟大中華區版權所有7跨團隊的漏洞可觀察性.20跨團隊的安全架構可觀察性.22跨團隊的事件響應可觀測性.25通過報告提高.28原則-使數據可訪問和可觀察.28

5、原則-突出改進機會.29原則-突出變化,推動持續改進.30原則-鼓勵溝通和協作.30應用這些報告原則.31報告路線圖.31結論.33附錄 A：軟件生命周期分解.33附錄 B:衡量.35參考資料.40 2025 云安全聯盟大中華區版權所有8前前言言云安全聯盟和 SAFECode 都致力于改善軟件安全成狀況。2019 年 8 月發表的論文DevSecOps 的六個支柱提供了高端方法論和成功實施解決方案，作者們使用這些方法和解決方案可以快速構建軟件，并最小化安全相關錯誤數量。這六個支柱是:支柱 1：集體責任（2020 年 2 月 20 日發布）支柱 2：協作與集成（2024 年 2 月 21 日發布

6、）支柱 3：務實的實現（2022 年 12 月 14 日發布）支柱 4：建立合規與發展的橋梁（2022 年 2 月 8 日發布）支柱 5：自動化（2020 年 7 月 6 日發布）支柱 6：測量、監控、報告和行動（2024 年 5 月發布）支撐這些支柱的成功解決方案是云安全聯盟和 SAFECode 一系列更詳細的聯合出版物。本文是六個后續出版物的最后一篇。介介紹紹DevSecOps 舉措的實施和維護可能需要幾個月到幾年的時間。在考慮人員、流程和工具的大規模變化時，持續測量 DevSecOps 的成功和失敗是關鍵的差異化因素?！澳銦o法管理你不能測量的事物”這句話十分正確，沒有可操作的測量標準和可

7、觀察性去測量績效，就無法理解進步，無法復制成功，也無法意識到失敗。測量、監測、報告和行動的能力是任何成功的安全計劃的基本特征，以支持有效的決策。在本文中，我們探討:2025 云安全聯盟大中華區版權所有9使使數數據據可可觀觀察察:將安全數據和指標轉化為可觀察的數據基基于于場場景景的的修修正正:安全可觀察性概念應用于高績效和低績效場景案例通通過過報報告告改改進進:安全可觀察性報告的起點目目標標云安全聯盟的 DevSecOps 工作組(WG)在“DevSecOps 的六個支柱”1 中發布了高級別指南，倡導采用新的安全方法。這六個支柱被認為是任何希望實施DevSecOps 的組織需要重點關注的領域，其

8、中一個支柱是支柱 6:測量、監測、報告和行動。支柱 6 的目標是促進和展示 DevSecOps 安全狀況的確切測量。這將使安全和數字領導者能夠確定其安全實踐的有效性，以及安全如何融入軟件開發生命周期。目目標標讀讀者者本文件的目標讀者包括從事信息安全和信息技術管理和業務職能的人員。其中包括 CISO、CIO、CTO 以及參與以下職能領域的個人:平臺工程、DevOps、產品團隊、架構、信息安全、治理和合規。使使數數據據可可觀觀察察如果一個系統具備有效且可見的系統狀態數據，那么它就是可觀察的，這對于追根溯源至關重要。一個系統現狀的可觀察性測量基于其生生成的數據，如日志、指標和跟蹤狀態?？捎^測性旨在了

9、解整體環境中發生的情況，以便檢測和解決問題，從而保持系統的高效和可靠性。組織采用可觀察性來幫助檢測和分析運營、軟件開發生命周期、應用程序安全和最終用戶體驗中事件的影響程度。日志、指標、分布式跟蹤和用戶體驗的測量是實現可觀測性成功的關鍵支柱:2025 云安全聯盟大中華區版權所有10日日志志:特定時間發生的離散事件的結構化或非結構化文本記錄指指標標:是指計數或度量的值，通常在一段時間內進行計算或聚合。指標可以來自各種來源，包括基礎設施、主機、服務、云平臺和外部來源分分布布式式跟跟蹤蹤:事務或請求在應用程序中流動的活動，并顯示服務如何連接，包括代碼級別的詳細信息用用戶戶體體驗驗:在應用程序上，甚至在

10、生產前環境中，添加具體的、由外向內用戶視角的數字化體驗，擴展傳統的遠程可觀測性。脆脆弱弱性性的的可可觀觀測測性性一旦產品團隊具備基于正確工具和工作流程的掃描機制，如靜態應用程序安全測試(SAST)、動態應用程序安全檢測(DAST)和軟件組成分析(SCA)等，識別脆弱性將十分簡單。而挑戰始于團隊持續性開展掃描、修正和報告。隨著時間的推移，脆弱性積壓可能會增加，在某些情況下甚至會增加到數以萬計，直到變得難以管理和補救。有效的脆弱性管理程序應該在開發生命周期的早期發現并修復漏洞，以減少其平臺/產品的總體風險暴露。脆弱性的可觀察性要求識別以下三個屬性。1 1.平平均均識識別別時時間間MTTI 是識別脆

11、弱性所花費的時間。較高的 MTTI 表明，在開發生命周期后期發現的脆弱性，將增加補救成本和將問題引入生產環境的風險。通過及早識別脆弱性，開發人員可以防止可利用脆弱性引入生產環境。在圖 2 中，識別時間為脆弱性暴露窗口的開始日期(1 月 10 日)和識別所述脆弱性的日期(1 月 16 日)，因此，識別所需時間為 7 天。對數百個脆弱性進行識別的時間會有所不同，MTTL 是所有漏洞識別值的平均值。2025 云安全聯盟大中華區版權所有112 2.平平均均補補救救時時間間MTTR 指示識別后修復脆弱性所花費的平均時間。MTTR 有助于跟蹤脆弱性是否被識別，是否被解析器團隊“遺忘”。與 MTTI 一樣，

12、MTTR 可以根據嚴重性和接受風險的脆弱性數量進行跟蹤圖 2 中，補救時間是識別日期(1 月 16 日)和補救日期(2 月 10 日)的差值，因此，補救所需時間為 26 天。與 MTTI 一樣，對數百個脆弱性進行補救的時間不同，MTTR是所有漏洞補救值的平均值。3 3.發發展展速速度度與與脆脆弱弱性性趨趨勢勢相相對對應應開發速度是否超過了修復脆弱性的能力?跟蹤這一趨勢有助于確定開發團隊是否在開發和運營過程中難以跟上脆弱性補救的步伐，以及補救是否與發展速度保持同步。MTTI/MTTR 可以根據發展速度和嚴重程度評分進行跟蹤。這可以幫助確定開發團隊和安全團隊在脆弱性管理中是否存在脫節。在圖 2 中

13、，脆弱性暴露窗口(1 月 10 日-2 月 10 日)跨越了兩個發布窗口。此值將有助于提供上下文信息，以幫助證明 MTTI 和 MTTR 值的正確性。2025 云安全聯盟大中華區版權所有12安安全全架架構構觀觀察察以下可觀察因素旨在指導開發團隊開展可接受程度威脅建模工作及其補救活動。組織可以利用這些改進他們的威脅建模模式和形式。4 4.威威脅脅量量跟蹤從威脅建模工作中識別出的威脅數量、威脅類型和相應的控制。將有助于了解是否采用了縱深防御方法。圖 3 演示了對 STRIDE(欺騙、篡改、抵賴、信息泄露、拒絕服務、特權提升)應用于每個威脅主題的控制量。深度防御平均值是每個 STRIDE 威脅類型的

14、控制覆蓋率平均值?？梢杂^察到，本例中的信息披露是最普遍的威脅，因為它所映射的控制量最高。2025 云安全聯盟大中華區版權所有135 5.計計量量控控制制針對從威脅建模工作中識別到的威脅，跟蹤相應的控制措施。這有助于了解補救活動是否按規模進行了優化。例如，單個控件具有多個用途。圖 4 演示了通常從威脅模型中識別出的控件的示例集，以及每個控制用于解決威脅的用法。這衡量了每個控件的投資回報率(ROI)。在本例中，基于角色的訪問控制(RBAC)和安全監控這兩項控制所能處理的威脅最多，投資回報率最高，這提示了應該優先考慮相關控制措施。而每個控制措施可平均處理 5 到 6 個威脅用例。6 6.計計量量安安

15、全全措措施施為應對已識別的脆弱性/威脅而轉換為安全措施的控制量。這有助于了解環境是否得到了保護，以防止風險、威脅或脆弱性發生。圖 5 顯示了隨著時間推移的安全措施的實施情況，強調了針對威脅狀況采取預防性安全措施的重要性。7 7.威威脅脅模模型型燃燃盡盡衡量對威脅的控制狀況是威脅建模的一項關鍵輸出。通過跟蹤已識別狀況與當前實施狀況，團隊可以評估威脅建模的有效性，驗證威脅建模對開發過程的價值賦能狀況。圖 5 顯示了威脅模型的燃盡情況，通過實施控制，在 5 個沖刺階段(10 周)內將 25 個未解決的威脅減少到 10 個。這種類型的衡量將證明威脅模型實施是否成功。在這個例子中，在 10 周內實施的控

16、制措施中，有 60%是良好的做法。2025 云安全聯盟大中華區版權所有148 8.采采用用安安全全模模型型分析安全設計模型的實施情況是評價安全架構成熟度的衡量方法。安全模式是一種可重用的解決方案，可解決軟件或系統設計中的常見安全挑戰和漏洞。它可以是一份工作文檔，也可以是一段可重復使用的代碼(模板)。通常情況下，一個更成熟的組織會有更多的模型和模板，以確保遵循一致的設計/工程實踐。完善的模型有助于提高重復性和一致性，減少重復出現的弱點和漏洞的數量。缺乏采用可能表明團隊沒有意識到這些模型的存在，或者模型并不有效。圖表 6 中，模型/模板數量為 20 個，采用率僅為 70%，表明六種模型存在效率低下

17、的問題。9 9.威威脅脅場場景景與與網網絡絡風風險險映映射射計量威脅，為風險聲明提供說明，即有多少威脅與某個風險聲明相對應。與風險不同，威脅是無法緩解的；但是，威脅是可以應對的，并可用于提供風險信息。圖表 6 展示了這一指標。在該示例中，敏感數據暴露風險與 14 個威脅有關；所以，從理論上講，處理這 14 個威脅能降低敏感數據暴露的風險分數。2025 云安全聯盟大中華區版權所有15 2025 云安全聯盟大中華區版權所有16其其他他指指標標：共有 31/34 個威脅與 3 個風險聲明有關聯，平均每個風險有 11.3 個威脅。3個威脅因不屬于業務風險而未被計算。風險 1：敏感數據暴露風險被 14

18、個威脅中提及風險 2：數據完整性受損被 6 個威脅中提及風險 3：關鍵 IT 服務不可用被 11 個威脅中提及模型/模板數量為 20 個，整個項目的采用率為 70%。表明有 6 個模式/模板需要修改或刪除。2025 云安全聯盟大中華區版權所有17事事件件響響應應的的可可觀觀察察性性事件響應的可觀察性提供了對警報和檢測的洞察力，進而可進行更詳細、更翔實的事件后審查。平均檢測時間（MTTD）、平均遏制時間（MTTC）和平均恢復時間（MTTRN）是關鍵指標，可讓企業在安全漏洞導致故障發生時迅速采取行動。對 IT 產業的安全監控可以讓企業捕捉到這些指標，讓運營團隊在事故期間獲得必要的數據。1 10 0

19、.平平均均檢檢測測時時間間（M Me ea an n t ti im me e t to o d de et te ec ct tM MT TT TD D）MTTD 是指團隊發現潛在安全事件所需的時間。MTTD 高的組織由于不能及早發現事件，會帶來額外的不必要風險。早期檢測（識別）意味著團隊可以盡早專注于響應和恢復工作，減少對生產的影響。在圖表 7 中，檢測（識別）時間為暴露窗口的開始日期（12 月 31 日）和確定所述事件的日期（1 月 1 日），因此識別時間為兩天。在數百個事件中，識別/檢測時間會有所不同，MTTD 是所有事件檢測值的平均值。1 11 1.平平均均遏遏制制時時間間（M Me

20、 ea an n t ti im me e t to o c co on nt ta ai in nM MT TT TC C）MTTC 指跟蹤控制安全漏洞/事件所需的時間。這有助于了解應對安全事件的速度。遏制是指團隊可以開始限制和減少事件的影響；避免對依賴服務造成影響或避免漏洞的橫向移動。在圖表 7 中，遏制時間是從檢測日期（1 月 1 日）到遏制日期（1 月 6 日），因此遏制時間為 6 天。在數百起事件中，遏制時間會有所不同，MTTC 是所有事件控制值的平均值。2025 云安全聯盟大中華區版權所有181 12 2.平平均均恢恢復復時時間間（M Me ea an n t ti im me e

21、 t to o r re es st to or re e n no or rm ma al li it ty y M MT TT TR RN N）MTTRN 表示事件修復過程中恢復正常所需的平均時間。較慢的 MTTRN 會導致服務中斷，影響組織的運作能力或產品的有效工作能力。在某些情況下，較長的 MTTRN 意味著，在恢復帶有敏感數據服務時出現了疏忽。在圖表 7 中，恢復正常所需的時間從檢測日期（1 月 1 日）開始，到補救所述事件的日期（1 月 25 日）結束，因此恢復正常所需的時間為 25 天。在許多事件中，恢復正常的時間會有所不同；MTTRN 是所有恢復值的平均值。2025 云安全聯盟

22、大中華區版權所有19團團隊隊間間的的成成熟熟度度比比較較理解 DevSecOps 實踐對團隊效能的影響，需要一種全面的方法來衡量、監控、報告以及根據指標采取行動。為了提供不同實踐成熟度和效能的概覽，描述了三個在不同組織中處于不同成熟度水平的團隊及其對指標影響的示例情景。情景對比采用了 OWASP 的DevSecOps 成熟度模型（DSOMM）。團隊分別被標記為 Alpha、Beta 和 Charlie，對應低、中、高成熟度及效能水平。通過情景對比，我們獲得了這些實踐在實際應用中的洞見，以及它們對 DevSecOps 實踐的影響。關注點并不在于將團隊標定為好或壞，而是突出這些實踐在可觀察指標以及

23、整體成熟度和效能上的不同影響。團團隊隊“A Al lp ph ha a”-低低成成熟熟度度和和效效能能Alpha 團隊在 DevSecOps 實踐方面處于較低的成熟度水平。這個團隊在DSOMM 的第 1 至第 2 級之間運作，對相關的 DevSecOps 實踐具有基礎的理解和采納。Alpha 團隊仍處在適應 DevSecOps 的早期階段。團隊在修復可被利用的漏洞方面反應遲緩，并且在確保設計中內置安全性的方法上缺乏一致性。延遲的事件處理凸顯了對更好安全實踐和培訓的需求。團團隊隊“B Be et ta a”-中中等等成成熟熟度度和和效效能能Beta 團隊在 DSOMM 的第 2 至第 3 級之間

24、運作，展現了他們在 DevSecOps 實踐中的中等成熟度。盡管他們已經超越了 DevSecOps 的基礎階段，但他們處理漏洞的方式可以被描述為適度的反應式，而非主動式。在設計階段嵌入安全性的承諾顯示出一定程度的不一致性，偶爾會導致潛在威脅被忽視。此外，雖然他們對事件的響應速度明顯快于該領域中成熟度較低的團隊，但仍存在改進的空間。2025 云安全聯盟大中華區版權所有20團團隊隊“C Ch ha ar rl li ie e”-高高成成熟熟度度和和效效能能Charlie 團隊在其 DevSecOps 實踐方面展現出高級別成熟度和效能，達到了DSOMM 的第 3 和第 4 級。各項指標體現出高度的

25、DevSecOps 成熟度。Charlie 團隊的實踐與指標不僅反映出高水平的技術專業能力，還體現了一種將安全放在首位并在每一個步驟中加以整合的文化。這使得安全性得以在所有階段中持續嵌入，從而減小了攻擊面并提升了安全姿態。盡管事件響應既高效又及時，Charlie 團隊仍然保持著持續改進的心態。這保證了事件響應能夠適應不斷變化的安全威脅。三三個個團團隊隊之之間間的的安安全全可可觀觀察察性性通過對比場景，性能成熟度的影響變得顯而易見。這些場景強調了持續測量的重要性，它為明智的決策、成功復制實踐以及識別需要改進的領域奠定了基礎。它們最終成為組織提升其 DevSecOps 實踐和文化的指南?？缈鐖F團隊

26、隊的的漏漏洞洞可可觀觀察察性性圖圖 8 證實了使用經過的天數對 MTTI 和 MTTR 進行平均和評分的概念，展示了隨著時間的推移而取得的改進。圖圖 9 代表隨時間變化的團隊間比較，顯示了團隊表現的高低。Alpha 團隊的低成熟度實踐導致大量漏洞被利用，而 Beta 團隊的中等成熟度實踐使漏洞數量減少。Charlie 團隊憑借其高成熟度實踐，擁有最少的可利用漏洞。MTTI：在新漏洞出現后，Alpha 團隊平均需要 20 天才能識別出一個新漏洞。由于建立了每周定期的漏洞掃描，Beta 團隊將識別新漏洞的時間縮短到了 15 天。然而，Beta 團隊實時掃描生產代碼庫，不會讓相應的漏洞出現在生產環境

27、中。由于持續集成和持續部署（CI/CD）實踐，在開發測試環境的源代碼庫中使用自動化安全掃描，Charlie 團隊能夠在幾天內以較低的 MTTI 檢測到漏洞。2025 云安全聯盟大中華區版權所有21MTTR：一旦漏洞被識別出來，Alpha 團隊的漏洞往往得不到解決，因此 MTTR會隨著時間的推移而增加。Beta 團隊已經建立了一個緩解流程，由于難以及時解決已識別的漏洞，MTTR 降低并穩定在 15 天。在采取有效的補救措施，如開發人員會專門花時間進行漏洞加固，Charlie 團隊的 MTTR 隨著時間的推移而持續下降。2025 云安全聯盟大中華區版權所有22 2025 云安全聯盟大中華區版權所有

28、23跨跨團團隊隊的的安安全全架架構構可可觀觀察察性性圖圖 10 證明了通過平均深度防御和控制重用得分的概念，并展示了隨時間的改進。圖圖 11 和和圖圖 12 代表了跨團隊隨時間的比較，為實施和威脅消減提供了高和低表現的指示。Alpha 團隊缺乏正式的安全架構實踐，導致控制措施難以落實，而 Beta 團隊的中等實踐顯示出逐漸改進。Charlie團隊的最佳實踐使安全架構可觀測性水平高，控制措施在短時期內落實到位。防防御御深深度度和和控控制制復復用用：Alpha 團隊在多次風險評估中經常發現相同的威脅，這表明重復的安全威脅沒有策略進行有效緩解。雖然 Beta 團隊在評估期間在識別各種威脅方面取得了進

29、展，但他們威脅建模練習的延遲有時會導致漏洞被忽視。Charlie 團隊利用一個明確的威脅建模過程來預測和緩解各種威脅，該過程可以在其他開發團隊中推廣使用，并且定期的回顧會議確保團隊從過去的威脅場景中學習并增強其威脅緩解策略。威威脅脅和和控控制制量量：Alpha 團隊在設計階段確定了必要的安全控制，但在生產過程中只實施了其中的一小部分。例如，雖然他們認識到加密的必要性，但只在存儲過程中實現加密，在數據傳輸過程中卻沒有實現。Beta 團隊經常意識到集成安全控制的重要性，例如在存儲和傳輸級別都進行加密。然而，識別和實施之間的延遲，意味著并非所有已識別的控制措施都會立即嵌入到應用程序中。Charlie

30、 的安全控制得到了迅速實施。例如，在確定端到端加密的需求后，團隊通過自動化部署腳本來管理、強制執行安全配置，確保它在存儲、傳輸和處理過程中都得到應用。2025 云安全聯盟大中華區版權所有24 2025 云安全聯盟大中華區版權所有25跨跨團團隊隊的的事事件件響響應應可可觀觀測測性性Alpha 團隊缺乏正式的事件響應計劃，導致事件響應行動的可觀察性較差。Beta 團隊的基本計劃提高了可觀察性，而 Charlie 團隊定義明確且定期更新的計劃帶來了出色的事件響應可觀察性。平平均均故故障障發發現現時時間間（MTTD）：Alpha 團隊缺乏有效的監控工具和實踐，導致平均故障發現時間（MTTD）延長，平均

31、為 19 天，并且隨著時間的推移而增加?；谝延斜O控能力，Beta 團隊將這一時間縮短到 15 天，并隨著時間的推移顯示出改進的跡象。然而，由于流程和人員配備不足，出現了改進停滯不前的情況。Charlie 團隊擁有一套強大的檢測和響應能力以及穩健的流程，這意味著它能夠在幾天內發現并解決故障，維持較低的 MTTD。平平均均故故障障確確認認時時間間（MTTC）+平平均均故故障障解解決決時時間間（MTTRN）：對于 Alpha 來 2025 云安全聯盟大中華區版權所有26說，事件通常需要時間來解決，積壓的工作造成了超負荷，導致 MTTC 和 MTTRN數值隨時間增加。Beta 已經建立了支持分類的工

32、具，但受限于隨時間持續改進的能力。Charlie 由于有效地使用了工具、人員和流程，能夠靈活調整并重新優先處理遏制和恢復活動，持續降低了 MTTC 和 MTTRN。2025 云安全聯盟大中華區版權所有27 2025 云安全聯盟大中華區版權所有28通通過過報報告告提提高高報告是組織在嵌入安全性時應該考慮的一個關鍵方面,因為它不僅提供了當前安全狀況的視圖,還為高層領導提供了評估和管理風險、安全預算和資源的能力。通過報告實現持續改進,關鍵在于確定哪些信息對項目團隊來說是相關的,哪些應該報告給高層管理。這遠不止是簡單地分享由安全解決方案提供的漏洞報告那么簡單。這里描述了四個原則及其應用,在構建報告以為

33、組織帶來最大收益時應該考慮這些原則,并提供了一條通往報告成功的路線圖。原原則則-使使數數據據可可訪訪問問和和可可觀觀察察通過收集和表達有意義的數據,組織能夠評估當前的安全狀況,并進行趨勢分 2025 云安全聯盟大中華區版權所有29析和風險緩解?？赡塬@得的好處包括:提提高高風風險險意意識識:可訪問和可觀察的數據能直接提高風險意識。當數據易于獲取時,團隊能更好地識別潛在的風險和漏洞,從而采取主動的風險緩解策略。增增加加對對安安全全的的投投資資:可訪問的數據使組織能夠更有效地分配資源,識別需要采取額外安全措施的領域。這會導致對安全的投資增加,特別是通過持續改進的舉措。了了解解威威脅脅格格局局和和未未

34、來來規規劃劃:數據的可訪問性提供了對威脅格局的洞見,使組織能夠為未來的安全挑戰做好準備。它使組織能夠適應和響應新興的威脅。加加快快事事故故響響應應活活動動:可訪問和可觀察的數據有助于加快事故響應。當安全事故發生時,可快速獲取數據,縮短檢測、控制和恢復正常業務運營的時間。原原則則-突突出出改改進進機機會會這一原則在報告領域扮演著關鍵角色,它著眼于確定 DevSecOps 實踐中需要改進的領域。它為提升創造了機會。這些機會并不局限于技術層面,還可能涉及改善事故響應計劃、員工培訓或采用新的安全工具和實踐等更廣泛的范疇。從這種報告中可獲得的好處包括但不限于:增增強強安安全全狀狀況況：直接識別并解決改進

35、領域可以提高安全狀況的穩健性。通過主動解決漏洞和弱點,組織可以更好地防御潛在威脅。持持續續改改進進：識別和解決改進機會,培養組織內部的持續改進文化。團隊可以從過去的缺陷中吸取教訓,不斷改善實踐。量量身身定定制制的的解解決決方方案案：報告使組織能夠針對具體挑戰和弱點量身定制解決方案。例如,如果發現培訓存在差距,可以開發針對性的培訓計劃來解決這些具體需求。適適應應變變化化的的威威脅脅:隨著威脅環境的演變,報告使組織能夠及時調整安全實踐,保持超越新興威脅的能力。2025 云安全聯盟大中華區版權所有30原原則則-突突出出變變化化,推推動動持持續續改改進進這一原則強調了報告作為推動組織持續改進的重要機制

36、。它強調需要通過學習和發展計劃來提高安全意識和文化。實施這一原則通常表現為為員工制定全面的學習和發展(L&D)計劃,旨在提升組織的整體安全意識。應用這一原則可帶來以下好處:增增強強學學習習文文化化:通過報告突出變化,增強了組織重視學習的文化。通過定期審查和采取報告洞見,員工被鼓勵不斷學習新的技能和知識。動動態態適適應應安安全全需需求求:隨著報告突出組織安全狀況的不斷變化需求,它能夠實現動態適應。這意味著,當發現新的漏洞時,組織能夠快速調整其策略和培訓計劃來解決這些具體領域。提提高高安安全全響響應應能能力力:以持續改進為重點,組織變得更敏捷,更能響應威脅。從報告中吸取教訓并實施變革,可降低重復事

37、故的可能性,從而提高處理安全事故的總體響應能力,包括平均修復時間(MTTR)、平均檢測時間(MTTD)和平均恢復時間(MTTRN)。主主動動風風險險管管理理:由報告驅動的持續改進使組織從被動轉向主動。通過分析趨勢和模式,組織可以預測并減輕風險,在其變成安全漏洞之前就得到緩解。原原則則-鼓鼓勵勵溝溝通通和和協協作作鼓勵通過報告進行溝通和協作的原則是構建統一方法的核心。通過提供組織安全實踐和 DevSecOps 活動的概覽,報告可以增強理解和合作。這不僅支持當前的安全需求,還為組織未來應對和管理安全挑戰做好準備。這種協作性報告方法帶來的好處包括:高高級級領領導導參參與與:傳達組織安全狀況的報告,使

38、高級領導能夠就安全投資和舉措做出明智決策。這種參與對于獲得必要的資源和關注安全相關事項至關重要。意意識識和和風風險險識識別別:通過持續報告,可以促進對安全風險的廣泛理解。這種意識對于及早發現和管理組織內部的潛在安全威脅至關重要。2025 云安全聯盟大中華區版權所有31安安全全文文化化的的發發展展:提高溝通交流會自然促進安全文化和意識的提升。隨著報告闡明安全問題及其管理情況,它增強了一種安全成為組織文化組成部分的思維方式。團團隊隊關關系系的的加加強強:報告彌合了開發和安全團隊之間的差距,促進了更好的協作。當這些團隊在安全目標和實踐方面保持一致時,組織就能更有效地應對這些挑戰。主主動動安安全全措措

39、施施:將安全專家納入開發團隊,如報告所述,有利于采取主動安全措施。這種向左轉移的方法確保在開發過程的早期就考慮安全因素,從而減少潛在漏洞并簡化補救工作。應應用用這這些些報報告告原原則則使數據可訪問、突出機遇、推動持續改進以及鼓勵溝通和協作的這四項原則,對于推動通過報告實現改進至關重要。這些原則共同構成了一個全面的方法,用于測量和改善 DevSecOps 生命周期中的安全性。當這些原則融入報告過程時,組織可將其安全指標從被動數據點轉變為主動的安全治理和戰略決策工具。2025 云安全聯盟大中華區版權所有32報報告告路路線線圖圖您您的的旅旅程程指指南南我們如何才能將思維轉變為“安全+績效=價值”的思

40、維模式？未未來來終終極極目目標標登登山山裝裝備備通過整個組織的績效衡量安全性，并使用安全可觀測性來管理風險，在開始之前，請確保確定項目/活動的優先級并有效分配預算。您已配備好數據點/工具，以便為您提供數當當今今的的挑挑戰戰據。您需要漏洞掃描了解您的項目和整個組織面臨的挑戰-低績效的根本原因可能不是安全團隊。程序的數據，事件需確保您能夠持續收集數據。要記錄在 IT 服務管理系統中，并且您的項項目目目目標標安全架構師應該已經沒有一種獨立的工具可以為您提供安全可觀測性，因此請將其視為自己的項目。進行了威脅建模。建立成功標準。如果您的項目旨在快速構建產品，需要平衡其與網絡風險（例如數據泄露）的成本，并

41、適當設置您的安全可觀測性目標。工工作作方方式式安安全全可可觀觀測測性性里里程程碑碑不要各自為政。首先通過一個項目建立概念驗證以贏得人心。如果您能夠展示漏洞管理的可觀測性，讓組織內部和外部的那么接下來的問題將是我們還能在哪里應用這種方法。根據組織的數據點進行垂直領導和倡導者都參與擴展，并利用現有資源（不要只為了展示可觀測性而采購工具）。一旦獲得倡導和領進來，包括安全和非導支持，就可以橫向擴展多個項目。安全利益相關者。2025 云安全聯盟大中華區版權所有33結結論論在任何數字項目或組織中實施安全性絕非易事。為了獲利，企業往往會加快發布功能的速度，以搶占市場份額?；A設施和應用程序的設計和構建是根

42、據績效指標（即部署速度、創建功能所需的時間、測試時間）來衡量，其也非常適合衡量業務目標。相比之下，安全性非常有效地通過合規性而非績效來衡量成功。改進安全功能的能力往往會使團隊/產品變得更加合規。合規性和績效有時可能是對立的力量，需要微妙的平衡，以避免人們認為“安全是阻礙因素”。本文提供了實證證據，表明使用績效指標可以有效評估安全性和 DevSecOps 的三個關鍵方面。我們計算項目/組織在管理漏洞、構建安全服務和響應事件方面的表現，從而提供安全可觀測性。安全可觀測性為企業領導者提供了有效的衡量標準，讓他們了解安全效率和性能，最重要的是，還了解了需要進一步投資和變革的地方。CSA DevSecO

43、ps 工作組將繼續研究提供安全可觀測性見解，并擴展附錄 B 中的用例范圍。附附錄錄 A：軟軟件件生生命命周周期期分分解解在將安全性納入軟件開發生命周期(SDLC)時，組織有多種工具和解決方案可供選擇。在“支柱 3：務實的實現”中，我們探討了將安全融入軟件開發生命周期(SDLC)的設計、編碼、測試、部署和監控階段的不同安全活動。使用專注于應用程序開發和平臺安全的與框架無關的 DevSecOps 模型，我們分解了圖 1 中的各個階段，其中可以識別指標以提供數據（參見附錄 B）。雖然不同定義中的 SDLC 有差異性階段劃分，但五階段 SDLC（參見圖 1：設計、編碼、集成和測試、部署和監控）提供了軟

44、件開發的通用視圖。2025 云安全聯盟大中華區版權所有34我們認識到，工具和解決方案可能難以部署和實施，而且難以擴展。當前人們的普遍看法是，現有解決方案可能無法提供有助于降低安全風險。我們挖掘如何使用DevSecOps 階段的度量指標來評價 DevSecOps 相關活動中的安全性能。2025 云安全聯盟大中華區版權所有35附附錄錄 B:衡衡量量從表 1 中的每個階段，我們已經確定了一份可能的度量標準的廣泛列表，以鼓勵整體決策。每個度量標準反映了各行業的產品和安全團隊的常見用法。雖然表 1 并不是對最佳實踐的比較或反映，但這些是團隊在 SDLC 每個階段可以收集的數據類型。階階段段衡衡量量標標準

45、準設設計計每個組件，功能和特征的威脅向量完成威脅建模演練的時間應對威脅的成本和時間安全控制/威脅比率重復使用（現有）安全控制的占比產品功能的安全控制占比涉及安全要求和驗收標準的公開占比安全故事集安全故事與功能故事的占比完成安全用戶故事所需的時間安全工作的平均交付周期開發過程中發現并修復的問題占比測試過程中發現并修復的問題占比設計過程中的風險識別量 2025 云安全聯盟大中華區版權所有36設計變更帶來的風險緩解量設計過程中風險解決（減輕，轉移，接受，避免）的占比在設計過程中識別和記錄風險所需的平均時間架構原則工作量產品團隊在設計過程中符合架構原則的占比安全架構審查量編編碼碼開發人員/工程師參與安

46、全和隱私培訓的占比一段時間內的經驗教訓數量在預提交時被拒絕的代碼更改占比在提交后通知的占比在合并前同行評審的代碼更改的占比已進行代碼審查的占比已進行代碼靜態檢查的代碼量總代碼靜態檢查錯誤的數量修復靜態檢查錯誤所需的時間符合組織許可/通過 SCA 掃描的開源組件占比發現的許可問題數量生產中使用的產品未解決的許可問題數量 2025 云安全聯盟大中華區版權所有37最新依賴項的占比具有已知漏洞的依賴項數量更新依賴項所需的平均時間已掃描的 IAC 代碼占比已掃描的源代碼占比跨代碼庫的檢查量（按語言分類）由于安全配置錯誤被拒絕的 IAC 部署量發現的安全問題數量SAST 誤報率的占比處理從 SAST/IA

47、C 掃描中發現的安全問題的安全票據數量加固的容器數量在生產中使用的加固容器的占比加固容器更新的平均頻率容器不合規覆蓋的數量（根據 CIS 基準或其他標準）與安全相關的單元測試結果的占比安全單元測試的吞吐時間成功和失敗測試的通過率進行同行評審的安全漏洞代碼和架構更改的占比 2025 云安全聯盟大中華區版權所有38測測試試通過 DAST、IAST 或持續滲透測試在運行時檢測到的漏洞數量進行不同類型的運行時測試（如 DAST、IAST 或連續滲透測試）的平均前置時間檢測到的高/嚴重漏洞的數量DAST/IAST 誤報率的占比DAST/IAST 對應用功能測試覆蓋的平均值完成 DAST、IAST 和滲透

48、測試等各自運行時測試所需的時間高/嚴重運行時漏洞與中、低和信息性漏洞的比例響應無效、意外或格式錯誤的測試數量安全運行時測試期間 API 覆蓋的占比容器鏡像中的漏洞數量涉及容器的安全事件數量應用于容器的安全控制數量完整性檢查的通過率占比部部署署部署頻率和成功率將基礎設施部署到生產環境所需的平均時間識別配置偏差所需的平均時間修正配置偏差所需的平均時間 2025 云安全聯盟大中華區版權所有39修復配置偏差所需的手動干預步驟平均數應用于云資源的護欄數量轉換為護欄的策略聲明數量（例如，訪問控制和資源管理）每個環境的安全事件數量環境隔離測試的數量機密輪換前的平均生命周期存儲在 CI/CD 管道中的機密數量

49、管道上觸發安全掃描所用的平均時間部署到生產環境所用的平均時間管道部署失敗的占比使用的加固/批準鏡像的占比鏡像上安全配置覆蓋的占比（例如，CIS 基準第 1 級 vs.第 2級）監監控控平均恢復（Recover）時間（MTTR）變更失敗率用戶服務正常運行時間發布后識別的安全改進機會數量檢測入侵的平均時間響應入侵的平均時間 2025 云安全聯盟大中華區版權所有40根據 STRIDE 用例記錄的資源占比來自攻擊模擬（ATT&CK）的攻擊向量數量符合組織安全策略的外部端點數量生產相關事件與非生產相關事件的占比識別、調查和解決漏洞的平均時間按產品分類的事件數量平均修復（Remediate）時間（MTTR

50、）在生產中修復的漏洞占比修復或補丁的平均工作量（t-shirt 大?。┡c威脅模型直接相關的已修復漏洞占比參參考考資資料料Sources:5 6Cloud Security Alliance,The Six Pillars of DevSecOps:Pillar 1,Collective Responsibility,February 2020,Availablehttps:/cloudsecurityalliance.org/artifacts/devsecops-collective-responsibility/Cloud Security Alliance,The Six Pillars

51、 of DevSecOps:Pillar 2,Collaboration and Integration,February 2024,Available https:/cloudsecurityalliance.org/artifacts/devsecops-automation/2025 云安全聯盟大中華區版權所有41Cloud Security Alliance,The Six Pillars of DevSecOps:Pillar 3,Pragmatic Implementation,September 2022,Availablehttps:/cloudsecurityalliance

52、.org/artifacts/devsecops-automation/Cloud Security Alliance,The Six Pillars of DevSecOps:Pillar 4,Bridging Compliance andDevelopment,February 2022,Availablehttps:/cloudsecurityalliance.org/artifacts/devsecops-pillar-4-bridging-compliance-and-development/Cloud Security Alliance,The Six Pillars of Dev

53、SecOps:Pillar 5,Automation,July 2020,Available https:/cloudsecurityalliance.org/artifacts/devsecops-automation/Cloud Security Alliance,Information Security Management through Reflexive Security:SixPillars in the Integration of Security,Development and Operations,August 2019,Available https:/cloudsec

54、urityalliance.org/artifacts/information-security-management-through-reflexive-security/Cloud Security Alliance,The Six Pillars of DevSecOps,Achieving Reflexive Security ThroughIntegration of Security,Development and Operations,August 2019,Availablehttps:/cloudsecurityalliance.org/artifacts/six-pilla

55、rs-of-devsecops/The Forrester New Wave:Cybersecurity Risk Rating Solutions,Q4 2018,Available 2025 云安全聯盟大中華區版權所有42https:/ Research on DevOps Quality Metrics that Matter,Tricentis Sponsored 75 CommonMetrics Ranked by Industry Experts,2021 Available,https:/ Measurement Companion to the CIS Critical Sec

56、urity Controls(Version 6)October 2015,Available https:/CIS-Critical-Security-Controls-VER-6.0-10.15.2015.pdfMeasures and Metrics in Corporate Security,Security Executive Council,2011,Availablehttp:/ Mellon University,Software Engineering Institute:The Current State of DevSecOpsMetrics,March 29,2021,

57、Availablehttps:/insights.sei.cmu.edu/blog/the-current-state-ofdevsecops-metrics/GSA Tech Guides,DevSecOps Guide,July 2021,Available https:/tech.gsa.gov/guides/dev_sec_ ops_guide/2025 云安全聯盟大中華區版權所有43Information Technology Laboratory/Software and Systems Division,Software Quality Group,Metrics and Measures,available https:/www.nist.gov/itl/ssd/software-quality-group/metrics-and-measuresOWASP DevSecOps Maturity Model DSOMM,DSOMM(owasp.org)Model,Governance,Education and Guidance,Training and Awareness,Training andAwareness(owaspsamm.org)2025 云安全聯盟大中華區版權所有44