YD-T 3763.6-2021 研发运营一体化 DevOps 能力成熟度模型 第6部分 安全及风险管理

研发运营一体化(DevOps)能力成熟度模型第6部分：安全及风险管理

1 范围

本部分规定了IT软件或相关服务在采用研发运营一体化 (DevOps)统一开发模式下，如何保障IT软件和相关服务的安全，进行风险管理。

本部分适用于具备IT软件研发交付运营能力的组织实施IT软件开发和服务过程的能力进行评价和指导；可供其他相关行业或组织进行参考；也可作为第三方权威评估机构衡量软件开发交付成熟的标准依据。

2 规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用千本文件。

[1]GB/T 25069-2010 信息安全技术术语

[2]GB/T 37988-2019 信息安全技术数据安全能力成熟度模型

3 术语、定义及缩略语

3.1 术语及定义

下列术语和定义适用于本文件。

3.1.1 安全基线security baseline

为了明确应用需要满足的最基本的安全防护能力而制定的一系列安全配置基准。

3.1.2 安全门限 security threshold

用千确定安全质冕的最低可接受风险级别。

3.1.3 安全态势感知 security situation awareness

基于环境的、动态、整体地洞悉安全风险的能力，是以安全大数据为基础，从全局视角提升对安全威胁的发现识别、分析、响应处置能力的一种方式。

3.1.4 安全需求基线 security requirements baseline

经过攻击面分析及威胁建模，确定的满足软件安全风险管理的基本安全需求消单。

3.1.5 安全需求标准库 security requirements standard library

基于信息安全相关的国家法律、法规，行业监管要求，公司的策略与实践，以及信息安全业界的最佳实践，形成的安全的功能需求、功能性的安全需求以及非功能性安全需求的标准集合。

3.1.6 暴力破解brute force attack

攻击者通过系统地组合所有可能性（例如登录时用到的账户名、密码），尝试所有的可能性破解用户的账户名、密码等敏感信息。

3.1.7 分布式拒绝服务攻击 distributed denial of service;DDoS

处于不同位置的多个攻击者问时向一个或数个目标发动攻击，或者一个攻击者控制了位千不同位置的多台机器并利用这些机器对受害者同时实施攻击。由千攻击的发出点是分布在不同地方的，这类攻击称为分布式拒绝服务攻击，其中的攻击者可以有多个＾拒绝服务指一种系统失去可用性的攻击。 [GB/T 25069-2010] 3..1.8. 攻击面分析attack surface analysis 程序任何能被用户或者其它程序所访问到的部分，这些暴露给用户的地方往往也是最可能被恶意攻击者攻击的地方。攻击面分析就是枚举所有访问入库、接口、协议以及可执行代码等的过程。 3. 1.9 工作项work item

项目研发过程中的需求、任务、缺陷等。 3..1..10. 黑盒安全测试black-box security test 也称为动态应用安全测试，在测试或运行阶段分析应用程序的动态运行状态。模拟黑客行为对应用程序进行动态攻击，分析应用程序的反应，从而确定该应用是否易受攻击。 3..1..11. 红蓝对抗reds vs. blues 攻守双方在实际环境中进行网络进攻和防御的一种网络安全攻防演练。 3..1..12. 基础设施即代码infrastructure as code 基于软件开发实践的基础设施自动化方法，强调系统及其配置的日常置备和变更具有一致性和可重复性。 3. 1. 13 金丝雀发布canary release 可以降低在生产环境中引入新软件版本的风险的技术，先将新版本发布给小部分用户，逐渐发布到整体基础设施并且将新版本发布给所有用户。 3. 1.14 蓝绿部署blue-green deployment 可以保证系统在不间断提供服务的情况不上线的部署方式。 3. 1. 15 逆向攻击reverse attack

对软件等进行逆向破解以进行黑客攻击的一种手段。 3. 1. 16 渗透测试penetration test 以未经授权的动作绕过某一系统的安全机制的方式，检查数据处理系统的安全功能，以发行信息系统安全问题的手段。也成渗透性测试或逆向测试。 [GB/T25069-2010信息安全技术术语］ 3. 1. 17 威胁建模 threat mode Iing 通过结构化的方法，系统的识别、评估产品的安全风险和威胁，并针对这些风险、威胁制定消减措施的一个过程。 3. 1. 18 研发安全运营一体化 DevSecOps 全新的安全及风险管理理念与模式，是指将安全内嵌到应用的全生命周期中，在这种模式下安全是每个人的责任。 3. 1. 19 资产 asset

对组织具有价值的任何东西。 [GB/T 25069-2010] 3.1. 20 资产动态感知 asset dynamic awareness 基于资产探测、自动化关联分析等手段，实现对资产变化的动态检测，实时感知设备、端口、服务等资产的变化。 3. 1. 21 资产风险管理 asset risk management 通过全面识别企业it资产，通过漏洞扫描、漏洞情报等手段及时识别资产的安全风险，并进行响应，实现资产风险的有效管理。 3. 1. 22 注入攻击 inject ion attacks 将不受信任的数据作为命令或查询的一部分发送到解析器时攻击手段，其本质是把用户输入的数据当做代码执行，如：SQL注入、XML注入、命令注入、CRLF注入等。 3. 2 缩略语 下列缩略语适用于本文件。

APl 应用程序编程接口 Application Programming Interface
CD 持续交付 Continuous Delivery
CI 持续栠成 Continuous Integration
CSRF 跨站点请求伪造 Cross Site Request Forgery
IDE 集成开发环境 Integrated Development Environment
MTTR 平均修复时长 Mean Time To Repair
RASP 应用运行时自我保护 Runtime Application Self-Protection
SDK 软件开发工具包 Software Development Kit
xss. 跨站点脚本 Cross-Site Scripting

4.安全及风险管理

本标准规定了IT软件或相关服务在采用研发安全运营一体化 (DevSecOps)的开发模式下，相比千传统开发模型发生变化，安全融入每个阶段过程，开发、安全、运营各部门紧密合作。DevSecOps强调在安全风险可控的前提下，帮助企业提升 IT效能，更好地实现研发运营一体化。

安全及风险管理分级技术要求包括：控制通用风险、控制开发过程风险、控制交付过程风险、控制运营过程风险，如表1所示。 表1安全及风险管理分级技术要求 ＼ 安全及风险管理 控制通用风险 控制开发过程风险 控制交付过程风险 控制运营过程风险 组织建设和人员管理 需求管理 配置管理 监控管理 安全工具链 设计管理 构建管理 运营安全 基础设施管理 开发过程管理 测试管理 应急响应 第三方管理 部署与发布管理 b 运营反馈 数据管理

度量与反馈改进

5 研发运营一体化控制通用风险

在DevOps模式下，安全内建千开发、交付、运营过程中，通用风险覆盖三个过程中的共性安全要求，包括：组织建设和人员管理、安全工具链、基础设施管理、第三方管理、数据管理、度罹与反馈改进，具体要求如表 2所示。

5.1 组织建设和人员管理

组织建设和人员管理指组织在将安全内建到DevOps过程中时，需要建设对应的组织负责不同的安全职责与工作，需要建设组织级的安全文化以及对研发人员、测试人员、技术运营人员等进行安全管理，包括第三方机构和人员，实现每个人都为安全负责。

5.2 安全工具链

安全工具链，关注研发运营一体化过程中与应用相关的安全工具。安全工具链建设过程中，一方面，将安全左移研发过程 (DevSec)，并强化运营过程安全 (SecOps)，实现将安全工具内嵌到DevOps全生命周期；另一方面，安全工具由人工化、单一化向自动化、多元化及智能化方向发展。

5.3 基础设施管理

基础设施作为应用的载体，包括基础资源层、操作系统层、应用中间件层等，基础设施的安全性、一致性、可靠性与稳定性为应用的安全及风险管理提供基础支撑。

5.4 第三方管理

第三方管理是指围绕应用安全对合作的第三方机构、人员、软件、服务进行安全管理，包括：接入控制、日常管理与监控、安全风险评估等，第三方机构包括：监管机构、供应商、合作伙伴等。

5.5 数据管理

数据管理是指在研发运营一体化过程中，对从采集、存储、传输、处理、交换到销毁的整个数据生命周期过程中涉及的各类数据进行安全及合规管理，利用制度、流程及工具等手段保护数据的机密性、完整性和可用性。 [GB/T 37988-2019 5.46.1]

注：关干数据安全生命周期及数据分类分级可以参考《信息安全技术数据安全能力成熟度极型》。

5.6 度量与反馈改进

度量与反馈改进是指通过对应用的研发、交付、运营过程的安全风险进行度量、展示并反馈给团队处理和改进的机制。设立清晰可益化的安全度痲指标模型并可视化展示度篮数据，有助于团队共享信息、识别改进方向并衡量改进效果。另外，设立及时有效的反馈机制，可以加快信息传递速率与准确性，有助于尽早地发现问题、分析问题、反馈问题、解决问题。度量与反馈改进可以保证整个团队内部安全信息获取的及时性和一致性，实现基于度量的持续改进。如表2所示：

表2研发运营一体化控制通用风险要求 级别 1组织建设和人 1安全工具链 1基础设施管理 1第三方管理如居管理1度量与反馈改员管理进 1.I有专职的安全具有漏洞扫描 l)生产环境具有第三方管数据管理具有安全问题统计 工具，如：的管理有安全理的安全规范基本的安全管管理岗位及人与报告以手工 理要求。员。 Web安全扫描管理规范与流与制度，明确方式为主。

工具、App安程；人员管理、数 全扫描工具、据安全、服务 2)生产环境主机安全扫描器运维等安全

具有安全基工具等。要求。

线。 I l) 有专门的 l)确保安全 l)基础设施 l)数据管理 1)仅在局部l)具有完善

工具的有效性安全管理团队的管理有安全的第三方管理具有安全管理领域定义部分 与安全主管，及安全性，具规范与流程，安全规范与制要求，覆盖运安全度量指

有一定的安全如：安全部门如：云平台安度，如：明确营过程，如：标； 全管理、中间制度、规范 等；规范和要求，的第三方人员2)安全度量如：定期规则引入和办公场等；件安全漏洞管

2)有明确的报告以自动化理等；所出入规则、升级、软件补

组织内各角色 2)具有明确方式生成和展丁升级、工具第三方服务的

的安全职责、 2)基础设施的数据分类分示，团队成员版本升级等；访问控制等；

权利和义务；的管理有安全级方法，对生可查看报告；

2)第三方合2)具有应用

的工具系统； 成或收集的数 3)研发人 3)基千度谎

作须签署相应 据进行分类分

安全自动化测 3)具有基础员、测试人员 识别的安全问

试工具及安全 的安全协议； 级标识，如： 和技术运营人设施的安全基题纳入系统管

配置加固工 通过打标签的 员的安全职责线； 3)控制第三理，并定期反具，包括但不

分离；限于源代码－方软件的接入方式等；馈团队； . 4)定期执行风险包括但3)对千不同 4)团队定期 4)有明确的安全检测工基础设施安全不限，于．第环境、类别及团队间安全协具测试、工黑盒具安、全安基线扫描，及方开源软件三级别的数据具 实施改进并取 范。全基线检查工安全风险。第＝方商业软有安全管控机每月／季度一作流程和规时发现和处理一得效果，如： 具、主机安全件等制如访问 0 ' :

次、应用上线 扫描工具等；控制、数据加前后等 解密、数据脱

3)具有自动敏等。 11 化漏洞扫描平 4)

l) l) l) l) 2) 2) 2) 3) 2) 3) 2) i) 5) 4)

3) 4) 6) 4)

1. 4 5)针对研发的管理，实现具备良好的抗人员、测试人自动化涌洞扫攻击与灾备容 员和技术运营描、漏洞修复错能力，能有人员开展专项通知推送、提效地实现多方的安全技能培供漏洞验证，联防联控；训；支持漏洞按照6)基础设施种类与风险级 6)在IT组支持低风险的别等维度进行织内进行安全应用发布方统计、分析、意识教育和培式。展示；训，提升团队成员安全能 7)具有统一力，建立安全的资产风险管文化。理平台，能对应用相关的资产进行风险监控及管理；8)具有自动化的安全测试平台；9)具备自主集成外部安全工具的能力，如：安全自动化测试平台集成多种黑盒安全扫描工具等。 l)同上，且 l)同上，且 1)同上，且 l)同上，且 需达到以下要需达到以下要需达到以下要需达到以下要求：求：求：求：2)有高级别 2)应用集成 2)具有统一 2)追过自动 的安全管理组安全SDK，具的基础设施管化的技术平台织，履行组织有包括但不限理平台；对第三方进行级的安全治理千密钥安全、安全管理、监3)基础设施职责，如：重资源操作安 控和应急响的管理具有部大风险的审阅全、运行时自应，如：第三 分智能化安全和处置策略的我防护能力方安全评级与能力，如：支决策等等，同时具备风险监控系统待秒级容灾容 计机制。上；4)基于度量识别的安全问题可自动化反馈给团队的工作项管理平台；5)度噩反馈的安全问题纳入研发迭代的待办事项列表；6)基千度虽分析安全问题库，反馈针对 性的安全建议，如：历史共性安全缺陷等。 l)同上，且 l)同上，且需达到以下要需达到以下要求：求： 2)具备数据 2)建立基于流转的自动化分级评价的完追踪和溯源能整安全度量体力；系，如：能力成熟度模型3)具备数据等；安全风险监控系统，对数据 3)具有安全使用过程中的度址平台，支 5 一3)有完善的统安全管控错切换、安全等；安全专家团平台；风险问题自动3)通过自动队，如：数据处置等。 3)具备全网化方式对第三安全、网络安 资产动态感知方进行实时的全等；平台，构建资安全风险评估4)有常态化产安全风险画与审计。的安全文化建像，实时感知设，如：完善企业资产的风 的培训机制险变化；等。4)具备自主研发安全工具的能力，如：自研基千流虽的web安全扫描器等 5)待续运营和改进安全工具，提升安全工具效能，包括但不限于安全策略持续调优、安全工具的能力提升等。 l)同上，且 l)同上，且 l)同上，且 l)同上，且 需达到以下要需达到以下要需达到以下要需达到以下要求：求：求：求：2)具有行业 2)具备智能 2)基础设施 2)通过智能 影响力的安全化软件安全开管理具备全面化的技术平台专家团队，能发全生命周期的智能化安全对第三方进行有效对行业进管理平台，智能力，能够自安全管理、监行贡献；能化威胁建动化发现、分控和应急响模、智能化安析和修复环境应；3)具有安全全测试及智能问题，及时发组织建设与安3)通过智能化的安全风险现并处置安全 全人员管理的化方式对第三评估；威胁。持续改进机方进行实时的制。 3)具备智能安全风险评估化应用安全态 风险进行自动持成熟度展化的识别、监刀；控、告警和处4)团队持续置。 改进，提升安全能力的成熟 度；5)团队基于度量反馈主动持续改进，全 面提升安全效能，如：涌洞修复率、误报率等指标的改善等；6)识别有效 改进，并作为企业级安全知识扩展到整个组织。l)同上，且 1)同上，且需达到以下要需达到以下要求：求： 2)具备智能 2)待续改进化数据安全风安全指标体系险管理能力，与安全度量平实现对数据安台，支持深度全风险的态势智能化、支持 感知，实现数业务决策等。据安全风险的智能化预测和处置。

势感知平台，智能化资产安全风险感知及处置，智能化应用安全威胁感知及防护。 与审计。

6.研发运营一体化控制开发过程风险

从应用的开发过程开始实施安全风险管理工作，可以保障进入交付过程的代码是安全的，降低后续交付、运营中的安全风险，保障研发运营一体化的整体安全，包括：需求管理、设计管理和开发过程管理，具体要求如表3所示。

6.1 需求管理

需求管理是指将安全工作左移到应用生命周期的源头，在应用的需求阶段即进行安全风险控制，定义安全需求并采取有效的措施和手段，从而控制开发过程的安全风险。安全需求既要包括功能性的安全需求，如：认证、授权、安全日志与审计等；又要包括非功能性安全需求，如：健壮性、可用性、可靠性等。

6.2 设计管理

设计管理关注开发过程中应用架构与设计过程中的安全风险控制。通过攻击面分析、威胁建模等手段，识别应用潜在的安全风险和威胁，制定措施消除或减少威胁、规避风险，确保应用的安全性。

6.3 开发过程管理

开发过程管理指对编码过程中的安全风险进行管理，通过引入安全编码规范与检测机制降低源代码中的安全风险。如表3所示：

表3研发运营一体化控制开发过程风险要求 级别 需求管理 I 设计管理 开发过程管理
1 需求包含基本的安全内容。 具有基础的安全设计规范，包括但不限千：身份认证、访问控制、加密等。 具有项目级安全编码规范。 2 l).需求包含安全内容，并纳 入团队整体的摇求消单；2)分析项目涉及的法律法规 和行业规范要求，并制定合规 1)同上，且需达到以下要求：2)基于风险级别及业务优先 具有团队级安全编码规范，对千不同类型编码语言具有相应 的安全编码指南。

和安全需求基线，如：个人隐 1级等对应用进行分级；私风险等； 3)制定和发布标准化的安全 3)针对安全需求具有相应的性功能，如：统一认证接入 用例，并明确验收标准，如：等；安全衙求清单等； 4)安全设计中具有基础的威 4)针对不同技术栈，制定相1胁建模的分析方法； 应的安全需求。

5)基于应用分级，针对应用 开展安全设计评审，并交付安全设计方案。 l)同上，且需达到以下要 l)具备完善的安全设计规 l)具有组织级安全编码规 求：范，如：标准化AP!接口安全范，并持续更新，规范包括但规范、标准化互联网应用安全不限千：安全编码指南、安全 2)具有持续更新的安全需求架构等示例代码、不推荐的函数列 标准库和管理平台，包括但不表、安全门限等； 限千：法律法规、行业监管要 2)具备标准化且安全的技术 求、公司的安全策略以及业界栈，如：中间件、框架和公共 2)代码提交前，进行源代码 最佳实践等；库等；安全检测，如：采用 IDE安全 检测插件等；

3)针对应用场景特点，制定 3)安全设计中具有完善的威相应的安全需求与用例，如：胁建模的分析方法； 13)代码提交前，对开源组件 Web应用安全、移动应用安全的安全风险及合规进行检测。等 4)针对高风险应用，开展安 全设计、攻击面分析与威胁建 4)安全需求与其他功能性需模，交付安全设计方案； 求同步开展测试，由测试团队和安全团队联合负责。 5)在安全设计过程中，对共 性安全解决方案进行持续积 5)安全衙求既要包括功能性累，促进形成标准化的安全设需求，如：认证、授权、安全计规范。 日志与审计等，又要包括非功 能性悔求，如：健壮性、可用 性、可靠性等。

； 1； 同上，且需达到以下要同上，且需达到以下要 |;同上，且需达到以下要 2)针对具体的业务逻辑风2)具备标准化的威胁建模方险，制定相应的安全需求与用2)IDE其成源代码安全检测法和工具；插件，实现安全编码规范的自 例；动化检查。 3)具备标准化的安全功能组 3)具有自动化的安全需求管1件，如：安全加固SDK、安全 理平台，如：基千业务场景自动推荐安全彻求等。 软键盘、 CSRF-token组件、XSS过滤器等。
5 1)同上，且需达到以下要 求：2)具有智能化的安全需求管 理平台，包括：多渠道需求自动化收集与分析等；3)具有完善的安全需求自动化验证能力。 l)同上，且需达到以下要 求：2)具备智能化的威胁建模平 台，智能化进行威胁建模并输出安全设计方案。 l)同上，且需达到以下要求： 2)编码工具具有智能化识别安全问题并提供解决方案的能力。

7 研发运营一体化控制交付过程风险

交付过程是指从代码提交到应用发布给用户使用，安全交付是将安全内建到交付过程中，包括：配置管理、构建管理、测试管理、部署与发布管理，具体要求如表4所示。

7.1 配置管理

配置管理是指在持续交付过程中，所有与项目相关的产物，以及它们之间的关系都被定义、修改、存储和检索的过程。配置管理保证了应用交付过程中所有交付产物的完整性，一致性和可追溯性。安全的配置管理是控制交付过程风险的基础，是保障持续交付正确性的前提，主要包括：源代码及相关脚本、依赖组件、发布制品、应用配置、环境配置等的安全管理。

7.2 构建管理

构建管理是指从软件代码到可运行程序之间的过程管理，安全的构建过程管理可提升应用的发布制品安全性，可靠且可重复的构建过程有利于安全问题的避免和版本变更追溯，构建的安全管理主要包括构建工具、构建环境、构建脚本等的安全。

7.3 测试管理

测试管理在应用投入生产运行之前，对安全需求进行验证，尽可能地发现并排除应用中的安全缺陷，从而提高软件的安全质觉。安全需求既要包括功能性的安全需求，如：认证、授权、安全日志与审计等；又要包括非功能性安全需求，如：健壮性、可用性、可靠性等

7.4 部署与发布管理

部署与发布管理是指在实现软件价值向最终用户的交付的同时，通过安全的流程与规范、设置安全检查点等方式保证部署与发布过程的安全，如表4所示：

表 4研发运营一体化控制交付过程风险要求 级别配置管理构建管理测试管理部署与发布管理 l 配置管理具有项目级构建管理有安全检查安全测试以手工为应用的部署与发布具安全管理规范。 主。清单。有基础的安全检查 点 l)构建管理有安全l)在交付过程中，l)应用的部署与发2 I1)配置管理具有团

队级安全管理规范，管理规范；有明确的安全测试的布有安全流程与规 如：配置管理安全检要求，安全测试结果汃I巳I； 2)具有安全的构建查消单等作为发布的前置条2)应用的部署与发工具；件； 2)对源代码、依赖布有明确的安全检查

3)构建脚本与配置组件、发布制品、数2)采用主流的安全点，如：漏洞扫描报

内容的变更有审核机据库变更脚本、应用工具进行安全测试和告等。 制。配置进行安全管理并合规扫描，如：黑盒 有源代码提交安全门安全测试工具、静态 限，如：定期的源代代码安全扫描工具 码安全扫描、开源组等； 件的引入规范、代码3)开发测试环境不访问授权控制等。直接使用生产数据， 采用公开数据、构造 出的测试数据或经过 脱敏后的生产数据； 4)基于安全需求，制定相应的安全测试用例，并进行验证测 试； 5)安全测试用例和非安全性测试用例进 行统一管理。 l)同上，且锦达到

3 I1)配置管理有组织 1)具有完善的安全

l)应用的部署与发 级全面的安全管理规 以下要求： 测试流程和规范，安

布有完备的安全流程 与规范，如：安全回 范，如：配置数据访 全测试结果作为发布 2)具有安全的构建问策略、工具平台备的前置条件；退、备份机制、应用

工具平台与环境，包发布安全指南等； 份恢复方案、开源管 2)安全测试结果具括但不限千：环境一 理规范等； 2)应用的部署与发致性、环境隔离、数有明确的质量门限， 2)对源代码、依赖据隔离等； 如：高危漏洞数量不

布过程采用自动化的 组件、发布制品、数 能大于0等；

安全控制方式，并嵌 3)提交构建中集成入到DevOps流水线 据库变更脚本、环境 配置脚本等进行安全 管理和统一变更管 理，并有自动化安全 管理机制，如：开源 组件的自动化安全扫 描、源代码安全规 范、源代码与制品可 追溯等； 3)对高风险代码进行人工代码安全评审，并有自动化机制辅助评审； 4)制品及相关配置 有安全检查以及相应的防篡改机制； 5)使用代码保护机制保护知识产权和关键信息及算法，提升逆向攻击和漏洞发现难度，如：互联网应用等 6)制品入库前进行自动化安全检查。 1)同上，且徐达到 以下要求： 2)对千配置管理内 容变更进行自动化的 安全管理； 3)建立软件资产安全风险库，如：源代码、开源组件、配置库、发布版本等的安全风险。轻量级代码及依赖组件安全扫描； 4)具有安全可靠的构建工具平台与运维保障机制。 3)具备完善的端到端安全测试工具链进行安全测试和合规扫描，覆盖主要的安全测试类型，包括但不限千：黑盒安全测试工具、静态代码安全扫描工具、开源组件安全扫描工具、容器安全扫描工具等安全测试工具； 4)在流水线中集成自动化安全测试，安全测试结果自动化反馈研发处理； 5)引入人工渗透测试，如：针对业务逻 辑、越权等漏洞进行 人工测试； 6)具备自动化安全测试结果汇总展示能 力； 7)持续优化安全测试策略，具备机制待中，如：自动检查漏洞扫描报告、自动化SQL执行等

3)应用在各个环境中的部署与发布过程采用统一且安全的自动化工具与过程； 4)应用的部署与发布具备强制的安全质量门限机制，阻断不安全应用发布上线： 5)应用的部署与发布具有低风险发布机制，如：蓝绿部署、金丝雀发布等。 续降低误报率与漏报 率。

l) 同上，月袖达到1l) 同上，且衙达到 1l) 同上，且袖达到 以下要求： 2)构建过程可自动识别安全风险并推荐可执行的策略。 以下要求： 2)具有集中的漏洞聚合及答理平台，对不同的安全测试结果进行聚合及关联分析，如：源代码安全漏洞和黑盒安全测试 漏洞进行上下文关联 分析等； 3)可以基千不同应 以下要求：

2)应用的部署与发布有完备的安全流程与规范，可以针对不同的业务或场景进行分类分级管理； 3)应用的部署与发布的安全管理流程、工具进行待续改进。8 研发运营一体化控制技术运营过程的安全风险 用场景进行智能化安全风险决策；4)定制化安全测试工具和脚本进行深度安全测试，如：对 API进行定制化的安全测试、修改开源工具提高渗透测试效率等；5)定期进行高阶安全评估，如：引入红蓝对抗机制等。
5 l)同上，且需达到 以下要求：2)具有智能化的配置管理平台，可智能修复代码等配置内容的安全问题。 l)同上，且需达到 以下要求：2)具有智能化识别安全风险的构建工具平台。 l)同上，且需达到 以下要求：2)安全测试完全自动化与智能化，并内嵌到开发与交付过程中，无需人工干预；3)智能化优化安全测试策略。 l)同上，且需达到以下要求：2)应用的部署与发布风险控制全面实现自动化和智能化，如：基千安全风险等级的智能化部署决策、无需人工干预等。

8.研发运营一体化控制技术运营过程的安全风险

技术运营过程是指应用发布给用户后的过程，将安全内建千运营过程中，通过监控、运营、响应、反馈等实现技术运营的安全风险闭环管理，包括：安全监控、运营安全、应急响应、运营反馈，具体要求如表5所示。

8.1 安全监控

安全监控是指在运营过程中对应用网络、运行状态等进行监控，识别攻击行为、发现安全问题和风险。

8.2 运营安全

运营安全是指对技术运营过程中的配置管理、变更管理等进行安全管理，通过安全监控分析、安全检测、安全缺陷识别、处理与跟踪等方式降低或消除安全问题对生产运营过程带来的影响。

8.3 应急响应

应急响应识别企业潜在安全危机和风险，针对运营过程中的安全事件、风险进行响应、跟踪和处置，及时消减风险和影响，保障业务连续性。应急响应涉及预案与流程机制建立的要求、应急演练的要求、事件管理的要求、人员与团队的要求、响应指标要求、自动化要求。

8.4 运营反馈

运营反馈关注安全信息的动态性、实时性、整体联动性，通过对应用研发、交付、运营全流程中的安全涌洞、缺陷和事件信息的获取并向左“＂（即向上游）反馈，实现DevSecOps全过程的及时、有效反馈，实现DevSecOps闭环管理，如表5所示

表5研发运营一体化控制运营过程风险要求 级别 安全监控 运营安全 应急响应 运营反馈
1. 在运营监控中实现基础的安全监控。 运营过程具备基础的安全管理规范，包括但不限千：变更管理安全审核机制等。 l)具有基础的安全应急响应机制与流程；2)基千事件、风险的影响情况和严重程度进行分级、分类。 l)具备基础的安全问题反馈机制；2)定期收集运营过程中的安全问题，并进行反馈。

l)具有安全监控管理要求，包括流程、制度、策略、组织、措施； 2)具有专有的安全监控机制，能够覆盖部分业务场景，包括但不限于：病毒攻击、DDoS攻击、暴力破解、注入攻击、接 口滥用等。l)运营过程具备基础的安全管理规范，包括但不限千：变更管理安全审核机制、配置管理权限控制、自动化运维工具安全准入机制与操作权限管理等 2)定期进行常规安全检查与改进，检查内容包括但不限于：应用运行状态、系统漏洞和数据备份等； 3)定期进行线上应用安全检测与处置，如：定期Web漏洞扫描、主机漏洞扫描、渗透测试等； 4)具备对不符合安全质量门限的应用上线检查与发现机制，如：应用上线安全检查清单等； 5)通过对告警信息、日志等进行自动化分析，发现线上应用存在的安全风险并进行通知、处置、跟踪； 6)收集涌洞和情报信息，对线上应用的运行环境、系统服务、使用框架及三方组件等进行预警及处置。l)制定和发布应急响应流程与规范，有基本的事件记录，针对不同级别的事件有

有持续反馈的流程、规范与组织，包括但不限千：安全问题收集、分类分级、 对应的响应要求与处1反馈、跟踪等机制； 理流程； 2)设立专门的安全应急响应角色，跟进安全应急响应与处置； 3)对安全事件建立复盘机制并形成知识 库。2).待续反馈的安全

问题能够自动化反馈到问题跟踪管理系统，并且实现闭环管理； 3)有周期性的安全报告总结机制，如：安全漏洞的处理报告 等。

同上， 且需达到 运营过程具备全 同上， 且需要达 有完善的持续反 以下耍求： 面的安全管理制度体 到以下耍求： 馈的流程、规范、组 系，包括但不限千安 织与平台，包括但不

2)具有完善的安全监控指标并可视化展示，包括但不限千：分类型和级别的安全事件数、安全攻击类型、攻击来源、攻击次数等； 3)具有安全监控平台，能够可视化展示应用运行状态，包括：收渠、分析运行数据，发现潜在安全缺陷，并进行分级告警； 4)具有集中、统一的管理平台实现监控关联分析。全策略、安全管理制度、安全操作规程等 2)对于自动化运维工具进行安全加固并具备自动化监控机制，及时发现工具的操作安全风险； 3)具备自动化安全审计机制，对权限管理制度和操作流程等进行合规审查及风险控制； 4)具备自动化运营日志分析系统，对于运营过程中日志进行 自动化分析，发现安全风险并告警； 5)针对应用及组件 信息建立专门的漏洞 和情报监测渠道，对线上应用的运行环境、系统服务、使用框架及三方组件等进行预警、处置与闭环，并有标准的流程与规范； 6)具备从外部接收相关漏洞通告和情报的渠道，并有完整的运营机制。2)有专门的安全事件管理平台，能够对 安全事件进行跟踪、统计、分析、可视化展示等； 3)具备安全应急响应职能团队，跟进安全应急响应与处置， 设立不同的应急角色； 4)具备完善的应急体系，包括但不限千：定期开展应急演练计划、安全应急预案、启动条件、应急组织、应急策略、应急资源、恢复机制等； 5)建立安全应急响应度量机制，对响应团队响应效能等作出要求，驱动团队改进优化。 上

限千：安全问题收集、分类分级、反馈、跟踪、处理、汇总分析等机制； 2)持续反馈平台具有一定的自动化能力，如：情报收集、发现处置、事件升级、持续监测、预警通知等； 3)持续反馈安全问题汇总分析结果，如：安全漏洞的处理报告、自动化系统的汇总分析结果等。 2)2) 2)

3) 3) 4) 4) 4) 5) 5)

2) 2) 2) 2) 威胁及攻击。 在安全风险，进行智能化处置。 3)具备安全问题的智能化分析及反馈能力，实现整个研发运营过程安全的自动优化。