《云計算開源產業聯盟：2023年TSM可信研發運營安全能力成熟度水位圖報告（52頁）.pdf》由會員分享，可在線閱讀，更多相關《云計算開源產業聯盟：2023年TSM可信研發運營安全能力成熟度水位圖報告（52頁）.pdf（52頁珍藏版）》請在三個皮匠報告上搜索。

1、 TSM可信研發運營安全能力成熟度可信研發運營安全能力成熟度水位圖水位圖報告報告（2023年年）云計算開源產業聯盟云計算開源產業聯盟 OpenSource Cloud Alliance for industry，OSCAR 2023年年12月月 版權聲明 本報告版權屬于云計算開源產業聯盟，并受法律保護。轉載、摘編或利用其它方式使用本報告文字或者觀點的，應注明“來源：云計算開源產業聯盟”。違反上述聲明者，本聯盟將追究其相關法律責任。報告在編寫過程中，歷經概念策劃、提綱設計、內容起草、征求意見等階段，得到了中國信息通信研究院云計算與大數據研究所和華為技術有限公司的大力支持，在此一并致謝。引引 言言

2、“安全左移”理念已誕生多年，安全左移強調進行安全早期介入，貫穿軟件服務全生命周期，一方面將實現風險安全可控，做到風險漏洞早發現、早修復，降低成本，提高收益；另一方面將反向推動企業建立安全文化，提升研發、運營、安全團隊協作意識。中國信息通信研究院自 2019 年起，牽頭推進 可信研發運營安全能力成熟度模型標準制定，并依據標準開展評估測試，目前已有包括金融、汽車、互聯網、運營商、軟件廠商、安全廠商在內的 30 余家企業通過評估。本次相關團隊分析評估細節，整理形成 TSM 可信研發運營安全能力成熟度水位圖報告，旨在繪制 TSM 整體評估水位圖，為企業提供參考，同時幫助企業對標業界優秀實踐，將自身安全

3、能力量化，探索構筑符合企業自身情況的全生命周期研發運營安全體系，提升企業產品市場競爭力。本報告首先明確 TSM（全稱：Trustworthy evaluation of Security maturity Model）可信研發運營安全能力成熟度工作背景，梳理國內外研發運營安全現狀并介紹中國信息通信研究院可信研發運營安全能力成熟度工作概況。其次，從五大領域十七類子項詳細介紹 TSM 水位圖構成，明確水位圖繪制依據。此外，報告團隊對 30 余家企業 TSM評估情況進行分析，指出目前企業研發運營安全體系建設短板與優勢并給出關注重點。最后，指出 TSM 水位圖助力企業明確安全現狀，完善改進計劃。報告團

4、隊也將從完善 TSM 評估細節、優化報告內容、豐富行業數據、建立用戶反饋機制四方面持續完善TSM 可信研發運營安全能力成熟度水位圖報告，助力業界可信安全生態建設。目目 錄錄 一、整體概述.1（一）安全研發態勢嚴峻，影響深遠.1（二）安全左移成為業界常態.3（三）研發運營安全能力成為企業核心競爭力之一.4（四）中國信通院建立研發運營安全標準體系，持續開展評估工作.5 二、TSM 可信研發運營安全能力成熟度水位圖.8（一）TSM 水位圖要素分為五大領域十七類子項.8（二）開源治理與安全數據管理為目前企業安全體系建設短板 10（三）企業安全管理工作推進應關注四方面重點.16（四）TSM 水位圖助力企

5、業明確安全現狀，完善改進計劃.20 三、TSM 水位圖子項活動詳解.25（一）體系（System）.25（二）要求（Requirements）.29（三）設計（Design）.34（四）控制（Control）.36（五）數據（Data）.42 四、下一步工作計劃.44 圖圖 目目 錄錄 圖 1 2022 年漏洞影響對象占比圖.2 圖 2 新型研發運營安全體系.4 圖 3 不同修復階段的修復成本.5 圖 4 可信研發運營安全能力模型.6 圖 5 TSM 可信研發運營安全能力成熟度水位模型圖.10 圖 6 TSM 可信研發運營安全能力成熟度水位圖.14 圖 7 示例企業 TSM 可信研發運營安全能

6、力成熟度水位對比圖.21 表表 目目 錄錄 表 1 TSM 可信研發運營安全能力成熟度水位圖要素.8 表 2 TSM 可信研發運營安全能力成熟度企業總體得分.11 表 3 TSM 可信研發運營安全能力成熟度示例企業得分.22 1 1/4545 一、整體概述（一）（一）安全研發態勢嚴峻，影響深遠安全研發態勢嚴峻，影響深遠 數字化時代，軟件已經成為日常生產生活必備要素之一，滲透到各個重要行業和領域。隨著數字化轉型進程的推進，容器、中間件、微服務、DevOps 等新技術理念的演進。軟件行業在快速發展的同時，軟件安全事件發生次數也呈逐年上升趨勢。根據 Splunk2022 年全球網絡安全態勢報告，65

7、%的受訪者表示攻擊者試圖進行安全攻擊的頻率逐漸增多，64%的受訪者表示近年的安全要求越來越高，難以達到，整體安全形勢未有明顯改善。全球軟件漏洞安全事件頻發，對國家社會安全構成嚴峻挑戰。2022 年，HP 發現其 OMEN 驅動程序軟件中存在一個嚴重漏洞（CVE-2021-3437），允許威脅行為者在不需要管理員權限的情況下將權限提升到內核模式，從而進行禁用安全產品、覆蓋系統組件，甚至執行破壞操作系統的操作，影響全球數百萬臺游戲計算機。Wormhole 于 2022年發現平臺中存在一個安全漏洞，攻擊者利用該漏洞成功竊取了價值3260 萬美元的加密貨幣。企業軟件產品漏洞安全事件頻發，軟件安全問題層

8、出不窮，嚴重危害國家、社會、個人信息安全。軟件應用服務自身安全漏洞被黑客利用攻擊是是安全事件頻發的關鍵誘因之一。根據 Gartner 統計數據顯示，超過 75%的安全攻擊發生在代碼應用層面。美國國家標準技術研究院（NIST）的統計數據顯示 92%的漏洞屬于應用層而非網絡層。在云原生應用導致的安全事 2 2/4545 件中，利用內部開發代碼中的已知漏洞進行的攻擊占比 37%，而未知的零日漏洞攻擊占比 27%。Verizon 2023 年的研究報告Data Breach Investigations Report總結了從 2021 年 11 月至 2022 年 11 月近 6000起安全事件，結果

9、顯示漏洞利用是造成安全事件的前三途徑之一。在所有調研的安全事件中，有關 Web 應用程序的事件占比 80%，其中50%的 Web 應用程序安全事件是由未修補的漏洞造成的。2022 年網絡安全漏洞態勢報告中將 2022 年漏洞按照影響對象進行統計，Web 應用類漏洞占比最高，達到 41.6%，其次是應用軟件漏洞，占比22.3%，如圖 1 所示。二者相加占比超過 73%，充分說明安全漏洞大多存在于軟件應用服務本身。來源：H3C，2022 年網絡安全漏洞態勢報告，2023 年 3 月 圖 1 2022 年漏洞影響對象占比圖 企業研發運營安全能力不足，是導致漏洞引入的關鍵痛點。根據2022 年 8 月

10、 Synopsys 針對美國企業 350 名 IT 與網絡安全人員的調研結果發現，45%的軟件發布前未經過安全檢查與測試，36%的開發 3 3/4545 團隊缺乏一致性安全流程，35%的版本部署到生產環境時存在漏洞，甚至有 32%的開發人員直接跳過安全流程。此外，部分企業由于安全研發流程管控不足，代碼包甚至未經測試就直接上線。由此可見，在業界研發能力不斷增強的同時，研發運營安全能力的相對落后帶來的安全隱患問題依然存在。（二二）安全左移成為業界常態安全左移成為業界常態 傳統研發運營安全模式中，安全介入相對滯后。傳統研發運營安全，針對服務應用自身的安全漏洞檢測修復，通常是在系統搭建或者功能模塊構建

11、完成以及服務應用上線運營之后，安全介入，進行安全掃描，威脅漏洞修復。如當前的大多安全手段，防病毒、防火墻、入侵檢測等，都是關注軟件交付運行之后的安全問題，屬于被動防御性手段。這種模式便于軟件應用服務的快速研發部署，但安全介入相對滯后，并無法覆蓋研發階段代碼層面的安全，安全測試范圍相對有限，安全漏洞修復成本也更大。降低潛在的安全風險，進行安全左移已成行業共識。新型研發運營安全體系強調安全左移，暨在軟件開發生命周期的早期階段就引入安全，這并不意味著安全合規只是早期嵌入到研發流程中，而是始終存在于研發流程的每個步驟，以確保在整個開發過程中安全性得到充分考慮和實現，如圖 2 所示。這種方式可以大大減少

12、在軟件開發后期或發布后發現安全漏洞和風險的可能性，從而降低成本和風險，全方面提升服務應用安全?，F階段安全左移工作投入不足，企業研發運營安全體系建設緩慢。根據 Deep Instinct 網絡 4 4/4545 安全生命周期中預防的經濟價值研究顯示，安全左移這項動作的價值凸顯，但總體投入不足，以網絡釣魚攻擊為例，企業平均總投入成本為 832,500 美元，其中 82%用于檢測、遏制、恢復和補救，只有 18%用于預防該類安全攻擊。造成該類結果的核心因素是企業未完全將安全左移作為組織級策略、安全投入與重視度不足、安全類人才緊缺等。來源：中國信息通信研究院 圖 2 新型研發運營安全體系（三）（三）研發

13、運營研發運營安全能力成為企業核心競爭力之一安全能力成為企業核心競爭力之一 企業建設研發運營安全體系進行安全左移，有助于降低安全問題修復成本。代碼是軟件應用服務開發的最初形態，其缺陷或漏洞是導致安全問題的直接根源，盡早發現源碼缺陷能夠大大降低安全問題的修復成本。根據美國國家標準與技術研究所（NIST）統計，在發布后執行代碼修復，其修復成本相當于在設計階段執行修復的 30 倍。具體數據如圖 3 所示。IBM 和 HP 研究數據顯示成本相差在 30 到 50 倍之間，而 Fortify 認為在軟件需求分析階段就開始避免漏洞的成本比發布后修復成本低 100 倍。安全左移助力企業排除安全隱患、減少安全事

14、故發生率、提升交付效率。企業通過前置安全工作使得在設計開發階段就關注安全問題，能夠節約大量資源，同時避免上線部署發現 5 5/4545 問題后付出高昂的修復成本。建設研發運營安全體系可加速項目的交付效率，通過早期發現安全問題，避免后期的返工與修改。較高的研發安全運營水平可幫助企業提升市場競爭力與信任度?，F階段，軟件需求方不僅會驗證交付物的安全，更會優先選擇研發運營安全能力優秀的企業作為其供應商，軟件供應商建設自身研發運營安全能力、實踐安全左移逐步成為提高市場認可的必經之路。來源：美國國家標準與技術研究所（NIST）圖 3 不同修復階段的修復成本（四）中國信通院建立（四）中國信通院建立研發運營安

15、全研發運營安全標準體系，持續開展標準體系，持續開展評估評估工作工作 中國信通院牽頭制定研發運營安全標準體系，構建可信研發運營安全能力成熟度模型?？尚叛邪l運營安全是指在涉及需求、設計、研發、驗證、發布、運營、下線的軟件應用服務全生命周期之中，從初期便引入安全，采取相關技術與管理手段，避免漏洞與威脅的產生，加固應用服務安全，提升軟件質量安全。中國信通院自 2019 年起，牽頭推進可信研發運營安全能力成熟度模型標準制定，廣泛邀請 6 6/4545 包括金融、互聯網、運營商、軟件廠商、安全廠商、工具廠商等各行業領域專家參與，調研參考業界優秀實踐經驗，覆蓋應用服務全生命周期，搭建通用可信研發運營安全體系

16、架構，抽取關鍵安全要素，建立可信研發運營安全能力成熟度模型，見圖 4。來源：中國信息通信研究院 圖 4 可信研發運營安全能力模型 標準覆蓋應用服務全生命周期安全，強調安全左移。標準結合人員管理體系和制度流程，從需求分析設計、編碼階段便引入安全，覆蓋軟件應用服務全生命周期，整體提升安全性?？尚叛邪l運營安全體系具有四大特點，一是覆蓋范圍更廣，延伸至下線停用階段，覆蓋軟件應用服務全生命周期。二是更具普適性，抽取關鍵要素，不依托于任何開發模式與體系。三是不止強調安全工具，同樣注重安全管理，強化人員安全能力。四是進行運營安全數據反饋，形成安全閉環，不斷優化流程實踐。7 7/4545 中國信通院依據標準開

17、展測試評估工作，目前已有多家企業通過相關評估。TSM 評估依據 可信研發運營安全能力成熟度模型 標準展開，劃分為管理制度以及要求階段、安全需求分析階段、設計階段、開發階段、驗證階段、發布階段、運營階段、停用下線階段 9 個子域，具體指標項包括組織架構、制度流程、安全培訓、第三方管理、安全門限要求、項目角色及權限管理、安全審計、環境管理、配置管理、變更管理等 38 大子項，根據各領域指標項分級能力要求，將企業整體研發運營安全能力劃分為基礎級、增強級、先進級三個級別。目前已有包括金融、汽車、互聯網、運營商、軟件廠商、安全廠商在內的30 余家企業通過評估。企業可通過參與評估，從三大角度助力企業建設可

18、信研發運營安全體系，提升企業安全管理水平。一是對標業界優秀實踐，幫助企業構筑全生命周期安全體系。標準制定過程參考調研大量業界已有優秀實踐，通過參評對標業界優秀實踐，同時與同行業企業對比，探索構筑符合企業自身情況的全生命周期安全體系，提升企業自身市場競爭力。二是量化企業安全水平，明確企業安全現狀和后續改進計劃。企業通過參與評估將自身安全水平進行量化，明確企業在同行業中安全所處水平和現狀，幫助企業明確后續改進方向和實施計劃。三是建立行業互信機制，構建安全可信生態，助力企業業務發展。通過中國信通院組織的相關評估，意味企業組織內部已建立研發運營安全體系，實現安全全流程覆蓋。企業可向客戶呈現評估結果，證

19、明軟件生產過 8 8/4545 程的安全性、透明性，從而建立互信機制，構建安全可信生態，進一步助力企業業務發展。二、TSM 可信研發運營安全能力成熟度水位圖（一）（一）TSM 水位圖水位圖要素要素分為五大領域十七類子項分為五大領域十七類子項 在本報告中，測評團隊梳理標準測試要求，整理分析已有評估記錄，最終形成 TSM 可信研發運營安全能力成熟度水位圖。水位圖要素由報告團隊依據可信研發運營安全能力成熟度模型標準和企業評估情況提煉得出，分為 5 大領域 17 類子項。5 大領域分別為體系、要求、設計、控制和數據，17 類子項分別為 1）安全組織、2）制度流程、3）培訓賦能、4）標準規范、5）安全門

20、限要求、6）身份與訪問管理、7）安全審計、8）環境安全、9）變更升級和配置管理、10）安全需求分析、11）安全設計、12）開源治理、13）安全編碼、14）安全測試、15）安全發布、16）安全監控運營、17）安全數據管理，具體如表 1 所示。表 1 TSM 可信研發運營安全能力成熟度水位圖要素 領域領域 序號序號 指標指標 英文縮寫英文縮寫 體系（System）1 安全組織 SO 2 制度流程 RP 3 培訓賦能 TE 4 標準規范 SS 要求（Requirements）5 安全門限要求 STR 6 身份與訪問管理 IAM 7 安全審計 SA 9 9/4545 8 環境安全 ES 9 變更升級和

21、配置管理 CCM 設計（Design）10 安全需求分析 SRA 11 安全設計 SD 控制（Control）12 開源治理 OG 13 安全編碼 SC 14 安全測試 ST 15 安全發布 SR 16 安全監控運營 SMO 數據（Data）17 安全數據管理 SDM 來源：中國信息通信研究院 其中體系代表企業建設研發運營安全體系的整體結構和框架，包括組織的安全架構、整體安全管理流程、培訓賦能、標準規范等。要求代表企業針對研發運營全流程通用的安全要求，包括安全門限、身份與訪問控制、安全審計、環境安全、變更升級等。設計代表企業在研發和運營過程中，在設計階段充分考慮安全性，包括進行安全需求分析、安

22、全架構設計、安全功能設計等方面?？刂拼砥髽I在研發運營安全實踐中實施的各種安全控制措施，包括開源治理、安全編碼、安全測試、安全發布、安全監控運營等。數據代表企業針對研發運營過程中涉及的各類安全數據進行統一收集管理，包括對安全事件日志、威脅情報、身份認證數據、訪問控制數據等多種安全相關數據的整合和管理。關于 17 類子項活動在本報告第三章進行完整介紹，在此不做過多贅述。目前企業評估水位圖情況結果使用蛛網圖進行表示，具有 17 根 1010/4545 軸線，由內到外劃分為 5 個圈層。如下圖 5 所示。17 根軸線代表 TSM活動的 17 類子項，蛛網圖由內到外分為 5 層，代表 0-10 分，用

23、來表示企業在特定維度的得分情況。來源：中國信息通信研究院 圖 5 TSM 可信研發運營安全能力成熟度水位模型圖（二）（二）開源治理與安全數據管理為目前企業安全體系建設開源治理與安全數據管理為目前企業安全體系建設短板短板 本報告中，我們針對包括金融、汽車、互聯網、運營商、軟件廠商、安全廠商在內的 26 家企業的 TSM 可信研發運營安全能力成熟度測評情況進行了分析，總體情況如表 2 所示。1111/4545 表 2 TSM 可信研發運營安全能力成熟度企業總體得分 體系體系（System）安全組織 考察項 企業得分 考察項 企業得分 SO 1.1-26 SO 1.2-16 SO 1.3-16 SO

24、 1.4-16 SO 1.5-16 制度流程 RP 2.1-18 RP 2.2-22 RP 2.3-26 RP 2.4-23 RP 2.5-25 RP 2.6-16 RP 2.7-15 培訓賦能 TE 3.1-26 TE 3.2-26 TE 3.3-26 TE 3.4-26 TE 3.5-14 TE 3.6-16 TE 3.7-13 標準規范 SS 4.1-26 SS 4.2-25 SS 4.3-26 SS 4.4-14 SS 4.5-16 SS 4.6-15 SS 4.7-26 要求要求（Requirements）安全門限要求 STR 5.1-22 STR 5.2-14 STR 5.3-16

25、 身份與訪問管理 IAM 6.1-26 IAM 6.2-26 IAM 6.3-26 IAM 6.4-25 IAM 6.5-26 IAM 6.6-15 IAM 6.7-12 安全審計 SA 7.1-26 SA 7.1-26 SA 7.3-12 SA 7.4-15 SA 7.5-15 1212/4545 環境安全 ES 8.1-25 ES 8.2-23 ES 8.3-26 ES 8.4-25 ES 8.5-26 ES 8.6-15 ES 8.7-15 ES 8.8-13 變更升級和配置管理 CCM 9.1-26 CCM 9.2-26 CCM 9.3-24 CCM 9.4-26 CCM 9.5-24

26、 CCM 9.6-24 CCM 9.7-24 CCM 9.8-23 CCM 9.9-16 CCM 9.10-14 CCM 9.11-16 CCM 9.12-15 CCM 9.13-7 CCM 9.14-12 設計設計（Design）安全需求分析 SRA 10.1-21 SRA 10.2-22 SRA 10.3-14 SRA 10.4-16 SRA 10.5-23 安全設計 SD 11.1-25 SD 11.2-24 SD 11.3-23 SD 11.4-24 SD 11.5-24 SD 11.6-14 SD 11.7-13 SD 11.8-14 SD 11.9-15 SD 11.10-15 S

27、D 11.11-11 SD 11.12-11 控制控制（Control）開源治理 OG 12.1-22 OG 12.2-24 OG 12.3-17 OG 12.4-11 OG 12.5-13 OG 12.6-13 OG 12.7-15 OG 12.8-8 OG 12.9-15 OG 12.10-14 OG 12.11-14 OG 12.12-16 1313/4545 安全編碼 SC 13.1-26 SC 13.2-24 SC 13.3-26 SC 13.4-26 SC 13.5-25 SC 13.6-11 SC 13.7-13 SxC 13.8-15 安全測試 ST 14.1-26 ST 14

28、.2-24 ST 14.3-24 ST 14.4-23 ST 14.5-26 ST 14.6-25 ST 14.7-15 ST 14.8-14 ST 14.9-16 ST 14.10-9 ST 14.11-15 安全發布 SR 15.1-24 SR 15.2-26 SR 15.3-26 SR 15.4-26 SR 15.5-16 SR 15.6-12 SR 15.7-13 SR 15.8-13 SR 15.9-12 安全監控運營 SMO 16.1-17 SMO 16.2-19 SMO 16.3-24 SMO 16.4-23 SMO 16.5-26 SMO 16.6-24 SMO 16.7-26

29、 SMO 16.8-13 SMO 16.9-10 SMO 16.10-10 數據數據（Data）安全數據管理 SDM 17.1-22 SDM 17.2-25 SDM 17.3-20 SDM 17.4-14 SDM 17.5-11 SDM 17.6-12 SDM 17.7-15 SDM 17.8-14 SDM 17.9-9 SDM 17.10-6 來源：中國信息通信研究院 報告團隊整理分析原始記錄，通過加權歸一化等方式對于整體結 1414/4545 果在蛛網圖中進行表示，最終形成目前 TSM 可信研發運營安全能力成熟度評估整體水位圖，如下圖 6 所示。來源：中國信息通信研究院 圖 6 TSM 可

30、信研發運營安全能力成熟度水位圖 從當前 TSM 可信研發運營安全能力成熟度評估整體水位圖中可以看出，開源治理和安全數據管理平均得分最低，為目前企業安全建設短板。滿分 10 分，開源治理和安全數據管理得分分別為 5.83 和5.69。開源治理重點關注開源軟件的統一管理、使用，以及對于開源安全問題的認知程度和處置能力。盡管開源軟件的使用為企業在成本效益方面提供了優勢，但其廣泛使用也引發了一系列的安全挑戰。首先，開源軟件通常由社區維護，缺乏明確的責任方，企業往往難以及時獲取關鍵安全更新，使得系統容易受到已知漏洞的攻擊。其次，開源軟件的生態系統復雜，存在各種依賴關系，一旦其中的某個組件存在漏洞，整個系

31、統的安全性都可能受到威脅。企業在處理開源組件時缺乏全面的治理策略，容易忽視對依賴關系的有效管控，從而形成了 1515/4545 安全上的短板。最后，開源軟件的使用往往超出了企業內部的直接控制范圍，企業難以確保從開源社區到內部開發過程的每個環節都經過了充分的安全審查，這使得潛在的威脅在不為人察覺的情況下滲透到企業系統中。安全數據管理重點關注研發運營過程中產生的安全相關數據的統一管理以及利用數據實現安全流程優化閉環。在當前企業中，安全數據通常分散存儲于不同的系統、平臺和應用中，導致了安全數據管理的碎片化和混亂。其次，分散的數據降低了對整體數據安全性的掌控，增加了潛在的數據泄漏和濫用的風險。同時分散

32、的數據管理使得對數據訪問和控制變得更加困難。企業需要在不同系統中維護各自的用戶訪問權限，增加了管理的復雜性，也為內部和外部威脅創造了漏洞。缺乏統一的安全數據管理策略，企業很難實現對安全數據的有效利用，優化從研發運營全安全流程。身份與訪問管理和環境安全平均得分最高，業界相關技術已發展相對成熟。滿分 10 分，身份與訪問管理和環境安全得分分別為 8.57和 8.08。身份與訪問管理關注在研發運營流程中，通過人員、角色等方式，針對系統、平臺和應用進行權限劃分，確保只有授權用戶能夠訪問企業資源，提升系統安全性。首先，IAM 系統在企業中已經廣泛應用，通過集中管理和監控員工的身份認證和訪問權限，有效地降

33、低了潛在的安全風險。企業能夠實現對員工的精確識別，確保只有授權人員能夠獲取敏感信息和關鍵系統。其次，IAM 系統基本功能完善，使得企業能夠根據具體業務需求和角色分配進行權限管理。通過建立 1616/4545 角色模型和權限策略，企業能確保員工在其工作范圍內獲取必要的訪問權限，同時避免了過度授權導致的潛在風險。最后，IAM 系統通常支持多因素身份驗證（MFA），進一步提升了身份驗證的安全性。通過結合密碼、生物特征、智能卡等多種因素，企業能夠加強對員工身份的驗證，降低被惡意入侵的可能性，提高整體安全性。（三三）企業安全管理工作推進應關注四方面重點企業安全管理工作推進應關注四方面重點 在整理 26

34、家企業 TSM 研發運營安全能力成熟度評估結果，形成水位圖的同時，報告團隊發現，在安全體系相對完善，安全工作落地相對充分的企業，有四方面顯著特征，對于企業落地研發運營安全工作至關重要，同時可作為企業建設研發運營安全體系的參考，分別為：1.自上而下推動安全工作 領導層的支持是構建可信研發運營安全體系的基石。只有領導層對安全工作的高度重視，才能夠確保安全理念貫穿于整個組織。領導層的明確表態和資源投入能夠為安全體系建設提供堅實的支持，鼓勵員工積極參與和配合安全措施的實施。其次，上層的決策和規劃對安全政策和流程的制定至關重要。通過制定明確的安全政策，能夠為企業提供具體的指導方針，確保安全工作與企業戰略

35、目標相一致。合理的規劃能夠為安全體系提供長遠的方向，使其與企業的發展相互促進，形成良性循環。同時，領導層的示范效應對企業文化的塑造有著深遠的影響。當領導層本身對安全意識和實踐具有鮮明的標桿作用時，員工更容易將安全融入到其日常工作中。領導層的積極參與安全培訓和 1717/4545 實踐活動有助于樹立安全文化，形成整體組織對安全的共同認知和價值觀。最后，有效的溝通和反饋渠道是確保安全政策貫徹執行的關鍵。領導層應當建立暢通的溝通渠道，鼓勵員工提出安全問題、建議和反饋。通過上層的敏銳感知和及時響應，可以更加迅速、準確地解決潛在的安全隱患，提高整個研發運營安全體系的落地性。2.建立調度及協作流程，協調人

36、員與資源，規范人員操作 建立調度及協作流程是確保安全體系高效運轉的基礎。在研發運營安全環節中，往往涉及多部門、多任務，如果沒有清晰的工作流程，容易導致信息混亂、任務交叉和責任不明。通過建立調度流程，能夠明確每個任務的責任人、執行步驟以及所需資源，確保每個環節都能夠按照規定的程序進行，減少操作失誤和安全隱患。其次，不同的任務和項目需要不同專業背景和技能的人員參與，通過建立協作機制，確保相關人員在合適的時間、地點參與工作，并明確資源的分配和使用計劃。這樣可以最大限度地發揮團隊協同效應，提高整個體系的安全性和高效性。同時建立調度及協作流程、協調人員與資源、規范人員操作還能夠幫助企業更好地應對突發事件

37、。在安全體系中，對于潛在威脅的迅速響應至關重要。通過有序的流程和協作機制，企業能夠更迅速、有效地應對安全事件，減輕潛在損失。最后，建立這些機制也有助于持續的改進。通過不斷的調度和協作流程的執行，企業能夠及時發現問題、總結經驗，不斷優化流程和提高運營效率。這種持續 1818/4545 改進的機制是安全體系長期穩定運行的基礎。3.構建研發運營安全工具平臺與工具鏈，無縫嵌入現有研發流程 構建研發運營安全工具平臺與工具鏈是可信研發運營安全體系落地的保障?？尚叛邪l運營安全體系落地的很大阻礙是企業研發人員與安全人員存在部門壁壘，安全工作參與意愿不高。構建安全工具平臺，企業能夠為研發人員提供安全解決方案。包

38、括集成各種安全工具，如靜態代碼分析（SAST）、軟件組成分析（SCA）、容器安全掃描等。通過一個統一的平臺，研發人員能夠更方便地獲取安全檢測結果、漏洞修復建議等信息，降低了使用門檻，提高了參與度。其次，建立工具鏈使得安全工作能夠更好地融入到研發流程中。通過將安全工具嵌入到研發工具鏈中，如代碼管理工具、持續集成/持續部署（CI/CD）工具等，能夠實現在代碼編寫、提交、構建等各個環節實時進行安全檢測。這種無縫集成的方式使得研發人員能夠在熟悉的工作環境中直接獲取安全反饋，加快漏洞修復的速度，降低了因漏洞滯留而帶來的風險。第三，企業可以為研發人員針對工具平臺和工具鏈，提供安全培訓和知識分享，幫助研發人

39、員不斷提升安全意識和技能。最終建立一個學習型的安全文化，使得研發人員更主動地參與到安全工作中。另外，安全工具平臺和工具鏈還能夠提供實時的安全數據分析和報告，為研發人員提供直觀的安全狀況。通過可視化的報告，研發人員能夠清晰了解項目的安全狀況、風險點和改進方向。這種數據驅動的方式 1919/4545 有助于激發研發人員對安全問題的關注和解決欲望。最后，通過構建統一的工具平臺和工具鏈，企業能夠更好地滿足研發人員的多樣性和分散性需求，確保研發和安全人員能夠高效地落地安全工作。4.進行數據反饋，形成安全閉環，不斷優化流程實踐 數據反饋是實現可信研發運營安全體系閉環的關鍵。通過在研發和運營過程中收集、分析

40、和反饋安全數據，企業能夠更全面地了解安全狀況，及時發現和糾正潛在的風險。這包括漏洞掃描結果、安全事件日志、用戶行為數據等多方面的信息，為企業提供了一個全景視圖，有助于深入理解安全問題的本質。其次，形成安全閉環意味著將數據反饋納入研發運營安全的持續改進過程中。當安全數據指示出潛在問題或改進的空間時，企業應該采取相應的措施來解決這些問題。這可能包括修改安全策略、調整安全流程、加強培訓，甚至優化已有的工具和平臺。通過將反饋數據納入決策和實踐，企業能夠更加靈活地應對安全挑戰，不斷提升安全水平。第三，安全數據反饋的關鍵在于及時性和準確性。通過實時監控和分析安全數據，企業能夠更早地發現潛在威脅，迅速做出反

41、應，從而降低潛在的損失。準確的數據反饋有助于避免誤報和漏報，確保企業做出的決策基于真實的安全狀況，提高了決策的準確性和針對性。另外，數據反饋也有助于形成安全文化。通過及時共享安全數據，企業能夠讓所有涉及到安全的團隊和個體了解安全狀況，增強安全意識。這有助于建立一種全員參與、全員負責的安全文化，使得安全不再是獨立團隊的責任，而是貫穿于整個組織 2020/4545 的核心價值。最后，通過不斷優化流程實踐，企業能夠更好地適應不斷變化的威脅環境。安全體系的優化不應僅停留在技術層面，還需要涵蓋流程和實踐。通過分析數據反饋，企業能夠發現現有流程中的瓶頸和不足，進而調整和優化流程，以提高效率和適應性。這種持

42、續的流程優化是安全體系不斷演進的關鍵推動力。（四四）TSM 水位圖助力企業明確安全現狀，完善改進計劃水位圖助力企業明確安全現狀，完善改進計劃 TSM 可信研發運營安全能力成熟水位圖作為一種直觀有效的可視化工具，可在企業安全管理中發揮重要作用。水位圖是 TSM 可信研發運營安全能力成熟度評估的最終產物之一，通過結合 TSM 評估原始記錄，水位圖可成為企業管理者了解安全現狀、制定改進計劃的有效手段之一。水位圖提供了對企業安全現狀的清晰認知。在可信研發運營安全能力成熟度模型中，涉及到諸多子域和具體指標，這些指標反映了企業在不同階段的安全表現。水位圖將這些指標以直觀的方式呈現，通過得分高低，清晰地展示

43、了各個子項在安全成熟度上的水平。管理者通過一張水位圖即可全面把握企業在安全管理方面的強項和薄弱點，有助于形成整體認知。水位圖為企業管理者提供明確的改進計劃。通過對比不同子項的水位高低，管理者可以迅速識別出相對薄弱的子項，發現潛在的安全風險。一旦管理者了解了企業在各個安全子項的實際表現，就能有針對性地制定改進計劃。水位圖上低水位的子域和指標為改進的重點，2121/4545 相對高水位的則為優勢領域?；趯嶋H得分的定向改進計劃，能夠更有效地推動企業安全能力的提升。水位圖有助于為改進計劃設立明確優先級。企業在制定改進計劃時，往往會面臨資源和時間有限的情況。水位圖的呈現方式能夠幫助企業管理者根據各個子

44、域和指標的重要性，確定改進計劃的優先級。這種有序的改進計劃能夠更好地適應企業的實際情況，最大程度地提高改進效益。水位圖具有持續改進的特性。企業的安全狀況和威脅環境都在不斷變化，水位圖的制定和更新是一個動態的過程。通過定期更新水位圖，企業能夠隨時掌握自身的安全現狀，及時調整改進計劃，以適應新的挑戰和威脅。這種持續改進的機制使得企業能夠更加靈活地維護和提升安全能力。來源：中國信息通信研究院 圖 7 示例企業 TSM 可信研發運營安全能力成熟度水位對比圖 圖 7 為一個示例企業與增強級平均水位圖的對比，從圖中我們可 2222/4545 以看出，示例企業在安全需求分析、安全設計、安全數據管理方面相對薄

45、弱，在安全編碼和安全監控運營方面安全工作相對充分。后續可重點針對安全需求分析、安全設計、安全數據管理三方面進行工作完善，安全數據管理和安全需求分析優先級可相對靠前。同時，示例企業得分情況分布見表 3，供讀者參考。表 3 TSM 可信研發運營安全能力成熟度示例企業得分 體系體系（System）安全組織 考察項 企業 得分 示例企業 考察項 企業 得分 示例企業 SO 1.1-26 1 SO 1.2-16 1 SO 1.3-16 1 SO 1.4-16 1 SO 1.5-16 1 制度流程 RP 2.1-18 1 RP 2.2-22 1 RP 2.3-26 1 RP 2.4-23 1 RP 2.5

46、-25 0 RP 2.6-16 1 RP 2.7-15 1 培訓賦能 TE 3.1-26 1 TE 3.2-26 1 TE 3.3-26 1 TE 3.4-26 1 TE 3.5-14 1 TE 3.6-16 1 TE 3.7-13 0 標準規范 SS 4.1-26 1 SS 4.2-25 1 SS 4.3-26 1 SS 4.4-14 0 SS 4.5-16 1 SS 4.6-15 1 SS 4.7-26 1 1 要求要求（Requirements）安全門限STR 5.1-22 1 STR 5.2-14 1 2323/4545 要求 STR 5.3-16 1 身份與訪問管理 IAM 6.1-

47、26 1 IAM 6.2-26 1 IAM 6.3-26 1 IAM 6.4-25 1 IAM 6.5-26 1 IAM 6.6-15 1 IAM 6.7-12 1 安全審計 SA 7.1-26 1 SA 7.1-26 1 SA 7.3-12 1 SA 7.4-15 1 SA 7.5-15 1 環境安全 ES 8.1-25 1 ES 8.2-23 1 ES 8.3-26 1 ES 8.4-25 1 ES 8.5-26 1 ES 8.6-15 1 ES 8.7-15 1 ES 8.8-13 1 變更升級和配置管理 CCM 9.1-26 1 CCM 9.2-26 1 CCM 9.3-24 1 CC

48、M 9.4-26 0 CCM 9.5-24 0 CCM 9.6-24 1 CCM 9.7-24 1 CCM 9.8-23 1 CCM 9.9-16 1 CCM 9.10-14 1 CCM 9.11-16 0 CCM 9.12-15 1 CCM 9.13-7 0 CCM 9.14-12 1 設計設計（Design）安全需求分析 SRA 10.1-21 1 SRA 10.2-22 1 SRA 10.3-14 0 SRA 10.4-16 1 SRA 10.5-23 1 安全設計 SD 11.1-25 1 SD 11.2-24 1 SD 11.3-23 1 SD 11.4-24 0 SD 11.5-2

49、4 0 SD 11.6-14 0 SD 11.7-13 1 SD 11.8-14 1 SD 11.9-15 1 SD 11.10-15 1 2424/4545 SD 11.11-11 1 SD 11.12-11 1 控制控制（Control）開源治理 OG 12.1-22 1 OG 12.2-24 1 OG 12.3-17 1 OG 12.4-11 1 OG 12.5-13 1 OG 12.6-13 0 OG 12.7-15 1 OG 12.8-8 1 OG 12.9-15 1 OG 12.10-14 1 OG 12.11-14 1 OG 12.12-16 1 安全編碼 SC 13.1-26

50、1 SC 13.2-24 1 SC 13.3-26 1 SC 13.4-26 1 SC 13.5-25 1 SC 13.6-11 1 SC 13.7-13 1 SC 13.8-15 1 安全測試 ST 14.1-26 1 ST 14.2-24 1 ST 14.3-24 1 ST 14.4-23 1 ST 14.5-26 1 ST 14.6-25 1 ST 14.7-15 1 ST 14.8-14 1 ST 14.9-16 1 ST 14.10-9 0 ST 14.11-15 1 安全發布 SR 15.1-24 1 SR 15.2-26 1 SR 15.3-26 1 SR 15.4-26 1 S

51、R 15.5-16 1 SR 15.6-12 1 SR 15.7-13 1 SR 15.8-13 1 SR 15.9-12 1 安全監控運營 SMO 16.1-17 1 SMO 16.2-19 1 SMO 16.3-24 1 SMO 16.4-23 1 SMO 16.5-26 1 SMO 16.6-24 1 SMO 16.7-26 1 SMO 16.8-13 1 SMO 16.9-10 1 SMO 16.10-10 1 2525/4545 數據數據（Data）安全數據管理 SDM 17.1-22 1 SDM 17.2-25 1 SDM 17.3-20 1 SDM 17.4-14 0 SDM 1

52、7.5-11 1 SDM 17.6-12 0 SDM 17.7-15 1 SDM 17.8-14 1 SDM 17.9-9 0 SDM 17.10-6 0 來源：中國信息通信研究院 三、TSM 水位圖子項活動詳解（一一）體系體系（System）1.安全組織（SO,Security Organization）安全組織主要考察企業在研發運營安全實踐中，建立并明確多層級安全管理組織架構，協調組織級的跨部門安全工作。同時明晰人員和團隊權責劃分，明確安全工作目標、原則、范圍，建立常態化安全工作機制并持續更新完善，推動研發運營安全的落地實施?？疾熘笜司唧w包括：考察指標具體包括：SO 1.1-有基本的安全管

53、理組織，具有專職的安全人員與安全管理崗位。SO 1.2-制定組織層面的網絡安全策略，并定義網絡安全目標、原則、范圍。SO 1.3-建立組織層面的安全組織，有明確的安全人員角色劃分，清晰的崗位職責、權利以及義務。SO 1.4-有高級別的安全管理組織架構，協調組織級的跨部 2626/4545 門安全工作，包括但不限于首席安全官、產品安全應急響應團隊、安全研發團隊、環境安全管理組織等。SO 1.5-具有安全管理架構、安全人員管理的持續更新完善機制。2.制度流程（RP,Regulations and Process）制度流程主要考察企業在研發運營安全實踐中，制定相關的管理制度和操作流程，并具有相應的平

54、臺化的流程管理能力，保障各個環節都能夠被及時響應，各項任務能夠被順利傳遞、銜接?？疾熘笜司唧w包括：考察指標具體包括：RP 2.1-有明確的管理制度和操作流程規范，包括但不限于：賬號和密碼管理、故障流程管理辦法、應急事件分級處理措施、人員行為安全規范、變更管理制度、團隊間安全協作流程和規范、第三方系統安全基線要求、升級與變更操作流程等。RP 2.2-有明確的第三方管理制度與安全規范，包括但不限于第三方人員賬號分配與使用規范、安全培訓與考核制度、安全保密協議的簽署、敏感數據的安全訪問與操作、機房與辦公場所出入規則等。2.4 RP 2.3-具有明確的應急事件響應流程和預先的事件響應計劃，包括但不限于

55、安全事件應急響應流程、安全負責人與聯系方式等。2.5 RP 2.4-制定和實施安全風險評估計劃，定期進行安全測試與 2727/4545 評估。2.6 RP 2.5-制定服務下線方案與計劃，明確隱私保護合規方案，確保數據留存符合最小化原則。2.7 RP 2.6-具有統一的制度管理平臺和平臺化的流程管理系統。2.2 RP 2.7-對于操作流程，根據業務場景、緊急程度等具有自定義的能力，同時具有持續更新制度流程的機制。2.3 3.培訓賦能（TE,Training and Empower）培訓賦能主要考察企業具備明確的安全相關培訓管理辦法與實施計劃，針對研發、測試、運營相關人員，組織安全相關安全培訓，

56、提供平臺進行安全知識持續學習，提升員工安全意識，增強員工研發運營安全能力，并進行相應的考核管理?？疾熘笜司唧w包括：考察指標具體包括：TE 3.1-有明確的安全相關培訓管理辦法與實施計劃。TE 3.2-對于研發、測試、運營人員進行相關安全培訓，包括但不限于安全管理制度、安全意識培訓、安全設計培訓、安全開發流程、安全編碼規范、安全測試培訓、安全運維培訓。TE 3.3-對于員工安全培訓結果進行考核登記。TE 3.4-具有組織級層面安全考核，范圍包括但不限于新員工入職。TE 3.5-定期對于研發、測試、運營人員進行相關安全培訓。2828/4545 TE 3.6-按需提供個人培訓，提供平臺進行安全知識持

57、續學習。TE 3.7-安全考核范圍應包括人員安全事故維度。4.標準規范（SS,Standard and Specifications）標準規范主要考察企業有明確的安全研發全生命周期的制度文件，規范化研發流程，把控研發流程中關鍵動作，指導安全研發流程的落地，包括但不限于開源治理、安全需求分析、安全設計、安全編碼、安全測試、安全發布、安全運維等。同時具備標準化的知識庫，通過統一的平臺進行管理?？疾熘笜司唧w包括：考察指標具體包括：SS 4.1-有明確的安全研發流程，明確研發各個階段的安全控制措施，包括但不限于安全需求分析、安全設計，包括威脅分析、安全架構設計等、安全編碼、安全測試、安全運維。SS 4

58、.2-有明確的開源及依賴組件管理要求，包括但不限于開源及依賴組件的選型、使用以及生命周期管理要求。SS 4.3-具有安全設計規范、安全編碼規范、安全測試規范及策略，規范包括但不限于禁用的函數、API、安全編碼指南等。SS 4.4-具有標準化的安全知識庫，包括但不限于不同類型編碼語言的安全編碼指南、通用弱點枚舉、常用攻擊模式枚舉和分類、安全設計和實現規范、安全驗證規范及用例等。SS 4.5-具有統一的平臺對于研發測試規范進行管理。2929/4545 SS 4.6-有明確的滲透測試計劃與管理機制，建立滲透測試流程。SS 4.7-有相應的發布安全流程與規范。（二）要求（二）要求（Requiremen

59、ts）5.安全門限要求（STR,Security Treshold Requirements）安全門限要求主要考察在開發流程之中設置門限卡點要求，明確介質傳遞條件，可根據業務場景、產品類型、語言類型等制定不同的安全門限要求，作為研發運營實踐中安全檢查關鍵節點，將安全工作前置?？疾熘笜司唧w包括：考察指標具體包括：STR 5.1-具有組織級或項目級安全門限要求。STR 5.2-根據業務場景、產品類型設立安全門限要求。STR 5.3-根據語言類型劃分安全門限要求。6.身 份 與 訪 問 管 理（IAM,Identity and Access Management）身份與訪問管理主要考察在企業研發運營

60、實踐過程中，根據人員進行項目角色以及權限管理，針對不用業務系統及操作有明確的權限管控及審批授權機制，同時通過技術平臺對于第三方合作進行管理監控，確保人員以及研發運營資源的安全性?？疾熘笜司唧w包括：考察指標具體包括：3030/4545 IAM 6.1-依據最小權限原則，通過用戶、角色、用戶組，建立資源、行為操作權限管控。IAM 6.2-采用認證機制保證訪問安全，包括但不限于配置強密碼策略等，同時及時為不需要權限的用戶或用戶組移除權限。IAM 6.3-針對研發、測試環境具有明確的權限管控機制。IAM 6.4-針對不同系統及操作有明確的權限管控機制，包括但不限于配置庫、版本控制系統、測試環境、數據及

61、用例管理系統、發布系統等。IAM 6.5-升級變更操作有明確的審批授權機制。IAM 6.6-支持多因素認證，保證訪問安全。IAM 6.7-通過技術平臺對于第三方合作進行管理監控，包括但不限于第三方合作人員的統一管理、統一的安全培訓與考核、辦公場所與機房人員出入、訪問控制與操作行為的監控等。7.安全審計（SA,Security Audit）安全審計主要考察企業在研發運營安全實踐中，對于研發、測試、運營人員以及第三方合作商以及第三方合作人員的相關操作行為進行監控審計，同時對高危操作進行重點審計，將審計記錄形成報表，方便查詢、統計與分析，確保相關人員的操作行為的安全性以及可追溯性?？疾熘笜司唧w包括：

62、考察指標具體包括：SA 7.1-審計范圍應包括安全管理要求的落地情況以及研發、3131/4545 測試、運營相關人員的所有操作行為。SA 7.2-安全審計日志完整詳細，同時對于審計記錄進行保護，有效期內避免非授權的訪問、篡改、覆蓋及刪除。SA 7.3-定期對于第三方合作商以及第三方合作人員進行安全審計。SA 7.4-針對審計日志進行自動化與人工審計，對于審計記錄形成報表，方便查詢、統計與分析。SA 7.5-對于高危操作進行重點審計，進行告警通知。8.環境安全（ES,Environment Safety）環境安全主要考察針對研發、測試、發布、生產環境進行統一的安全管理，降低安全風險，并對不同環境

63、上的數據進行定期離線備份，確保數據安全。同時針對各類環境的操作進行詳細記錄，并具備相應的安全基線要求，定期執行安全基線掃描保障環境的安全?？疾熘笜司唧w包括：考察指標具體包括：ES 8.1-研發、測試、生產環境隔離。ES 8.2-生產環境具有安全基線要求，保障環境的安全，如生產環境上的服務器及電腦使用非 EOS（停止提供服務）操作系統并升級到最新補丁等。ES 8.3-針對各類環境的操作進行詳細記錄，具有可追溯性。ES 8.4-具備限制人員直接操作相關環境的能力，具體實現方式包括但不限于通過堡壘機對系統進行訪問，記錄并限制相關風險操 3232/4545 作。ES 8.5-研發、測試、生產環境上的數

64、據具備定期離線備份的能力。ES 8.6-定期執行生產環境的安全基線掃描，及時發現和處理安全風險。ES 8.7-研發、生產環境具有良好的抗攻擊與災備容錯能力。ES 8.8-針對不同的業務場景以及架構，對于發布環境進行分類管理，安全加固。9.變更升級和配置管理（CCM,Change and Configuration Management）變更升級和配置管理主要考察企業對于變更進行統一規范、管理、分析、執行、記錄，便于審計回溯。同時管理產品信息，針對產品信息進行規劃、標識、控制變更、發布、審核等一系列活動和實踐，并在軟件研發運營全生命周期各階段針對系統中的配置項進行審計確認，確保產品交付信息的安全

65、性、完整性、一致性及可追溯性?？疾熘笜司唧w包括：CCM 9.1-具有明確的進行變更條件與變更執行機制，變更包括但不限于功能變更、缺陷修補。CCM 9.2-對于升級變更操作進行統一管理，明確記錄操作信息，包括但不限于升級變更人員、升級變更時間、升級變更內容。CCM 9.3-升級變更操作可以實現自動化回滾，同時與版本 3333/4545 系統同步，確保版本信息一致。CCM 9.4-變更升級操作對于用戶無感知，對于用戶有影響的，需要提前告知溝通。CCM 9.5-有明確的配置管理策略，包括但不限于配置項標識、配置庫命名規范及配置庫結構、權限控制原則、基線及變更控制、配置審計等。CCM 9.6-需求分析

66、文檔、設計文檔、源代碼、測試文檔、軟件包等識別為配置項并建立配置庫進行配置管理。CCM 9.7-對各配置項建立配置基線，對基線后的配置項變更有明確的變更控制。CCM 9.8-具有明確的配置審計機制，包括但不限于配置項是否完備、配置項與前期需求的一致性、配置項版本的描述精確，與相關版本一致、配置項的每次變更有記錄，可以追溯到具體修改時間和修改人等。CCM 9.9-對于變更請求進行統一分析、整理，確定變更方案。CCM 9.10-重大變更操作具有分級評審機制。CCM 9.11-配置項具有回滾機制，所有的配置項都能通過回滾的方式還原到變更之前的狀態。CCM 9.12-構建要素、測試環境要素識別為配置項

67、納入配置管理。CCM 9.13-支持進行自動化配置審計。3434/4545 CCM 9.14-項目依賴的自研模塊、平臺組件、開源源碼、開源二進制、第三方軟件被準確的定義和記錄。（三）（三）設計（設計（Design）10.安全需求分析（SRA,Security Requirements Analysis）安全需求分析指在系統或軟件的開發過程中明確定義和識別與安全相關的需求，主要考察企業在設計和開發階段充分考慮和集成安全性，有明確的安全需求要求，如客戶安全要求、安全合規需求、用戶隱私需求、行業安全標準、內部安全標準等?？疾熘笜司唧w包括：SRA 10.1-安全需求分析包括客戶安全要求、安全合規需求、

68、用戶隱私需求、行業安全標準、內部安全標準以及安全功能需求，并納入整體的需求清單，針對安全合規需求，分析涉及的法律法規、行業監管等要求，制定合規和安全需求基線，針對安全功能需求根據業務場景、技術，具備相應的測試用例。SRA 10.2-針對涉及個人數據處理的服務產品及相關業務活動梳理個人數據清單，開展隱私風險評估。SRA 10.3-持續更新完善安全需求清單，依據包括但不限于法律法規、行業監管要求、行業安全標準、公司安全策略、業界最佳實踐、客戶安全需求。SRA 10.4-安全功能需求與其他功能性需求同步開展，具有明確的安全需求管理流程，能夠對安全需求的分析、評審、決策等環 3535/4545 節進行

69、有效管理，需求分解分配可追溯，形成閉環。SRA 10.5-具有公司級的統一的安全需求知識庫，可依據具體安全需求，查找相應安全解決方案，并具有持續更新機制。11.安全設計（SD,Security Design）安全設計指對系統架構、數據流、身份認證、授權、通信和其他關鍵組件進行分析和設計，以確保系統對各種攻擊和安全威脅具有抵御能力，目的是確保系統在設計階段就具備足夠的安全性。主要考察企業有統一的安全設計原則，通過受攻擊面分析、威脅建模等方式進行安全設計，并執行風險消減設計?？疾熘笜司唧w包括：SD 11.1-有明確的安全設計原則，指導后續安全設計工作的開展。SD11.2-針對安全需求分析階段識別的

70、安全需求進行設計。SD 11.3-有攻擊面分析過程，識別關鍵攻擊面。SD 11.4-具備威脅分析過程，識別關鍵風險點。SD 11.5-針對識別出的關鍵攻擊面和關鍵風險點進行分析設計并輸出消減措施。SD 11.6-可根據行業特點、業務場景、技術棧特點制定安全設計原則。SD 11.7-可根據安全設計原則構建安全設計方案庫，助力團隊實踐安全設計。3636/4545 SD 11.8-可依據風險識別模型確定風險點，進行受攻擊面分析，同時有明確的受攻擊面分析過程，包括但不限于系統各個模塊的重要程度、系統各個模塊接口分析、攻擊者視角分析攻擊手段、方式、攻擊路徑、權限設置是否合理和攻擊難度分析 SD 11.9

71、-可根據業務場景，識別攻擊者意圖，并針對攻擊者意圖有效識別價值資產。SD 11.10-有明確的威脅建模流程，包括但不限于確定安全目標、分解應用程序、確定威脅列表。SD 11.11-具有標準化、平臺化的威脅建模方法和工具，實踐威脅建模流程。SD 11.12-基于產品領域初始架構和產品領域高危暴露面，輸出針對價值資產的攻擊路徑，基于架構元素識別脆弱性、威脅并進行分析設計，輸出消減措施。（四四）控制（控制（Control）12.開源治理（OG,Opensource Governance）開源治理指針對開源軟件的引入、使用、退出全生命周期進行統一管理，明確開源引入使用規則。主要考察企業有明確的高風險開

72、源軟件禁用和檢測機制，建立統一的開源組件倉庫，軟件項目服務所使用的開源組件只能從可信開源組件倉庫獲取?？疾熘笜司唧w包括：OG 12.1-對于開源組件進行風險評估，明確組件風險，對于 3737/4545 開源組件漏洞進行跟蹤并及時修復。OG 12.2-具有明確的開源組件確認機制，確保待發布的軟件產品服務不包含高危組件。OG 12.3-開源組件來源可追溯，明確組件版本和來源地址。OG 12.4-制定明確的開源組件選型規范，明確禁用開源組件的基線，開源組件引入應遵循最小化引入原則，具有公司級的開源組件庫，明確優選、可用、禁用的開源組件列表。OG 12.5-開源組件庫信息包括但不限于許可證信息、版本信

73、息、組件漏洞信息、來源信息。OG 12.6-項目服務所利用的開源組件只能從唯一的可信開源組件倉庫獲取。OG 12.7-制定明確的開源組件入庫審批機制。OG 12.8-開源組件的引入、評估、評審、使用和淘汰過程進行全生命周期的審計，通過自動化工具及時向使用產品進行通知預警。OG 12.9-開源組件與自研代碼獨立存放、目錄隔離 OG 12.10-代碼提交前采用自動化掃描工具進行開源組件安全檢測，管理項目中的開源安全風險，包括但不限于許可證合規風險和開源組件安全風險。OG 12.11-采用工具與人工核驗的方式確認開源及依賴組件的安全性、一致性。OG 12.12-根據許可證信息、安全漏洞等綜合考慮法律

74、、安 3838/4545 全風險。13.安全編碼（SC,Secure Coding）安全編碼指在編寫源代碼的過程中，通過自動化安全工具、人工審查等方式，盡早發現安全缺陷，以減少潛在的安全風險。主要考察企業有統一的安全編碼規范，并通過工具進行落地實現。同時有相應的代碼審查和卡點機制，避免高風險源碼的合入?？疾熘笜司唧w包括：SC 13.1-根據安全編碼規范進行編碼，并具有代碼審查機制，確保代碼符合安全編碼規范。SC 13.2-維護獲得安全認可的工具、框架列表，使用獲得認可的工具、框架進行編碼實現。SC 13.3-使用靜態應用程序安全測試工具對代碼進行掃描，具備對構建中的告警進行分析、消除的能力。S

75、C 13.4-具有統一的版本控制系統，將全部源代碼納入版本控制系統管理。SC 13.5-制定明確的源代碼安全檢視方法，開展源代碼安全審計活動，采用工具與人工核驗相結合的方式進行代碼安全審計，對于威脅代碼通知研發人員進行修復。SC 13.6-根據安全編碼規范制定自定義安全策略，使用靜態應用程序安全測試工具進行自動化安全掃描，同時采用集成于 IDE 或其他形式提供的自動化測試工具定時進行代碼安全檢測，對于不安全 3939/4545 編碼行為進行識別，告警。SC 13.7-制定代碼審核及代碼合入門禁機制，如分級審核機制，確保代碼合入質量。SC 13.8-構建時開啟安全選項，從構建啟動開始到構建結束過

76、程自動化，中間過程不手工干預；版本重復構建結果一致。14.安全測試（ST,Security Testing）安全測試指通過人工和自動化安全工具，發現并修復軟件系統中可能存在的安全漏洞、弱點和潛在的威脅，以確保系統能夠有效地抵御惡意攻擊和安全威脅。主要考察企業有統一的安全測試原則與執行規范，有明確的測試評估模型，對于測試結果可實現 IT 化管理，測試問題有記錄可查詢?？疾熘笜司唧w包括：ST 14.1-采用主流的安全工具進行漏洞掃描，掃描類型包括但不限于代碼掃描、主機掃描、Web 應用掃描、容器掃描、App 掃描、端口掃描。ST 14.2-企業在研發流程中，有明確的安全隱私測試要求，作為發布部署的

77、前置條件。ST 14.3-測試數據不包含未經清洗的敏感數據，單個測試用例的執行不受其他測試用例結果的影響。ST 14.4-基于安全隱私要求，有相應的安全隱私測試用例，并進行驗證測試。4040/4545 ST 14.5-測試過程有記錄可查詢，測試設計、執行端到端可追溯，對測試過程發現的問題可進行跟蹤、閉環。ST 14.6-具有明確的測試評估模型，對被測對象進行測試評估，并在測試報告中進行結果展示。ST 14.7-測試用例、測試數據定期更新，滿足不同階段、環境的測試要求。ST 14.8-具備自動化安全測試能力，對于測試結果集中匯總與展示，實現對被測對象的評估依據，包括測試用例執行率/通過率、遺留問

78、題等，和評估結果的 IT 化管理，測試問題有記錄可查詢。ST 14.9-針對漏洞掃描結果可以自動通知研發人員，根據安全門限要求和企業管理要求，對于漏洞進行跟蹤修復。ST 14.10-采用主流的模糊測試工具，自動化進行模糊測試。ST 14.11-基于滲透測試工具針對系統架構、應用程序、網絡層面漏洞進行滲透測試。15.安全發布（SR,Security Release）安全發布指軟件或系統發布新版本或更新時，采取安全卡點措施以確保新版本不會引入安全漏洞。主要考察企業有統一的發布流程規范，有明確的安全發布檢查節點，并具有完整性、安全性校驗機制，同時可實現發布流程自動化，有相應的安全備份機制?？疾熘笜司?/p>

79、體包括：SR 15.1-發布應具有明確的安全檢查節點，包括但不限于漏 4141/4545 洞掃描報告、病毒掃描報告、代碼審計相關報告、安全測試報告，并根據相應的安全檢查節點，有提示或阻斷操作。SR 15.2-針對軟件具有完整性保護措施，如數字簽名等。SR 15.3-對外發布的軟件使用安全可靠的傳輸鏈路、協議和工具，防止軟件包被劫持和篡改，發布的過程和內容可追溯。SR 15.4-軟件發布之前具有明確的病毒掃描、完整性檢查要求，支持發布前手動進行完整性校驗。SR 15.5-針對發布流程具有安全回退、備份機制。SR 15.6-制定發布策略，通過低風險的發布策略進行發布，如灰度發布或者藍綠發布等方式。

80、SR 15.7-發布流程可以實現自動化，一鍵發布。SR 15.8-根據安全節點檢查結果，發現高危安全問題，自動阻斷發布流程。SR 15.9-支持自動化進行病毒掃描以及數字簽名驗證等完整性校驗，校驗結果作為發布的前置條件。16.安全監控運營（SMO,Security Monitoring Operations）安全監控運營指通過實時監測、分析和響應安全事件，保障信息系統或網絡的安全性，并確保系統的連續穩定運行。主要考察企業有相應的安全監控運營能力，可抵御常見安全攻擊，并具有明確的安全事件處置流程和手段，針對安全事件可復盤形成知識庫?？疾熘笜司唧w包括：4242/4545 SMO 16.1-運營階段

81、具有安全監控機制，覆蓋全部業務場景。SMO 16.2-具有抵御常見威脅攻擊的能力，包括但不限于DDoS 攻擊、暴力破解、病毒攻擊、注入攻擊、網頁篡改，并對于安全事件具有多種方式的告警機制。SMO 16.3-定期進行常規安全檢查與改進。SMO 16.4-通過統一平臺對于安全事件處置全流程進行跟蹤。SMO 16.5-具備從外部接收相關漏洞通告和安全情報的能力。SMO 16.6-安全風險評估、測試范圍覆蓋重要業務系統、應用。SMO 16.7-基于應急事件進行分級、分類處理。SMO 16.8-針對敏感數據泄露具備事件溯源追責的相關能力。SMO 16.9-制定漏洞獎勵計劃，鼓勵第三方滲透測試，同時根據滲

82、透測試流程，針對系統架構、應用程序、網絡層面漏洞進行安全測試。SMO 16.10-對于應急響應事件可以實現一定程度上的自動化處理。（五五）數據（數據（Data）17.安全數據管理（SDM,Security Data Management）安全數據管理指對企業內涉及安全的各類數據進行統一收集管理。包括對安全事件日志、威脅情報、身份認證數據、訪問控制數據等多種安全相關數據的整合和管理。主要考察企業有明確的安全數據 4343/4545 統一管理原則，通過統一管理安全數據，進行安全數據反饋分析，企業可以更有效地檢測威脅、發現潛在安全風險，提高對整體安全狀況的洞察力，同時也可完善研發運營全流程，并有相應

83、的反饋優化管理流程與度量機制?？疾熘笜司唧w包括：SDM 17.1-漏洞掃描結果有統一管理與展示平臺。SDM 17.2-針對整體研發運營流程有明確安全反饋機制。SDM 17.3-定期收集運營過程中的安全問題，進行反饋，對于反饋安全問題分類、分級處理，完善前期安全需求設計、安全研發等流程。SDM 17.4-通過平臺對于第三方系統進行統一管理，包括但不限于漏洞管理、安全風險管理、統一修復加固。SDM 17.5-有統一的安全監控平臺，對于威脅攻擊處理能夠統一監控并可視化展示，支持對于監控安全事件進行分級展示，可視化展示內容包括但不限于安全事件數、攻擊類型、攻擊來源、嚴重程度分級、影響范圍。SDM 17

84、.6-有統一的技術平臺，對于監控數據進行統計、展示，對于運營過程中的安全日志等數據進行自動化分析，發現安全風險有告警機制。SDM 17.7-有統一的技術平臺，對于應急事件進行全流程跟蹤與可視化展示，對于應急事件處理具有具體的量化指標，包括但不 4444/4545 限于威脅處理時間、響應時間。SDM 17.8-對于應急事件及時復盤，形成相關處理知識庫。SDM 17.9-針對安全反饋，有明確的反饋優化管理流程與度量機制。SDM 17.10-有統一的運營安全問題反饋平臺，統一收集反饋的安全問題，分類、分級處理，反饋全流程跟蹤。對于收集的安全問題自動化實現匯總分析，優化從需求設計到研發運營整個流程。四

85、、下一步工作計劃 本報告中，相關團隊依據可信研發運營安全能力成熟度模型標準和評估實踐，提煉 5 大領域 17 類關鍵要素，形成 TSM 可信研發運營安全能力成熟度水位圖，旨在助力企業管理者了解研發運營安全現狀，有目的地制定改進提升計劃，完善企業研發運營安全體系。中國信通院自 2019 年起牽頭推進可信研發運營安全能力成熟度模型標準，并開展相關評估工作。在積累一定樣本量之后，今年首次編寫輸出 TSM 可信研發運營安全能力成熟度水位圖，仍存在許多待完善的工作。未來，中國信通院將繼續依托 3S-Lab 軟件供應鏈安全實驗室，深化與業界合作，持續開展 TSM 評估，從四方面完善 TSM可信研發運營安全

86、能力成熟度水位圖報告，一是完善 TSM 評估細節，進一步細化問題的定位，以更精確地了解安全體系中的弱點和風險點。二是優化報告內容，增加案例分析部分內容，同時引入更多直觀、清晰的圖表和圖形，以更好地呈現數據和結論。三是豐富行業數據，加 4545/4545 深與業界合作，針對重點行業持續推動 TSM 評估，引入同行業其他企業的安全數據，進行比較分析，幫助企業更全面地了解自身在行業中的地位，激發其提升安全水平的積極性。四是建立用戶反饋機制，加強與用戶的溝通，收集用戶對報告的意見和建議，以持續改進和優化報告的內容和形式。同時可考慮根據企業的具體需求，定制化部分報告內容，使之更符合特定企業的實際情況和關注點。4646/4545