1、 ICS 35.020 L70 YD 中华人民共和国通信行业标准 YD/T 3764.620XX 代替 YD/T 研发运营一体化（ DevOps）能力成熟度 模型 第 6 部分：安全及风险管理 The capability maturity model of devopsPart 6 ： security risk management （报批稿） 点击此处添加本稿完成日期 -发布 -实施 中 华 人 民 共 和 国 工 业 和 信 息 化 部 发 布 YD/T 3763.620XX I 目 次 目 次 前 言 .IIIY 1 范围 .1 2 规范性引用文件 .1 3 术语和定义 .1 4 缩
2、略语 .3 5 安全及风险管理 .3 6 研发运营一体化控制通用风险 .4 6.1 组织建设和人员管理 .4 6.2 安全工具链 .4 6.3 基础设施管理 .4 6.4 第三方管理 .4 6.5 数据管理 .5 6.6 度量与反馈改进 .5 7 研发运营一体化控制开发过程风险 .8 7.1 需求管理 .8 7.2 设计管理 .8 7.3 开发过程管理 .8 8 研发运营一体化控制交付过程风险 .10 8.1 配置管理 .10 8.2 构建管理 .10 YD/T 3763.620XX II 8.3 测试管理 .10 8.4 部署与发布管理 .10 9 研发运营一体化控制技术运营过程的安全风险
3、.12 9.1 安全监控 .13 9.2 运营安全 .13 9.3 应急响应 .13 9.4 运营反馈 .13 YD/T 3763.620XX III 前 言 本标准是研发运营一体化（ DevOps）能力成熟度模型系列标准之一。该系列标准的结构及名称如 下 : 研发运营一体化（ DevOps）能力成熟度模型 第 1部分：总体架构 研发运营一体化（ DevOps）能力成熟度模型 第 2部分：敏捷开发管理 研发运营一体化（ DevOps）能力成熟度模型 第 3部分：持续交付 研发运营一体化（ DevOps）能力成熟度模型 第 4部分：技术运营 研发运营一体化（ DevOps）能力成熟度模型 第 5
4、部分：应用设计 研发运营一体化（ DevOps）能力成熟度模型 第 6部分：安全及风险管理 研发运营一体化（ DevOps）能力成熟度模型 第 7部分：评估方法 研发运营一体化（ DevOps）能力成熟度模型 第 8部分：系统和工具技术要求 本部分是第 6部分：安全及风险管理 本部分按照 GB/T 1.12009给出的规则起草。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。 本部分由中国通信标准化协会提出并归口。 本部分起草单位： 中国信息通信研究院、北京华佑科技有限公司、 腾讯云计算（北京）有限责任 公司、阿里巴巴（中国）有限公司、 OPPO广东移动通信有限
5、公司 、奇安信科技集团股份有限公司、浙 江蚂蚁小微金融服务集团股份有限公司、杭州安恒信息技术股份有限公司 、北京金山云网络技术有限 公司、中国移动通信集团有限公司、中国联合网络通信集团有限公司、 普元信息技术股份有限公司、 畅捷通信息技术股份有限公司、 苏宁消费金融有限公司 、中软国际科技服务有限公司 本部分主要起草人： 牛晓玲、萧田国、刘凯铃、景韵、张嵩、赵锐、韩方、韩晓光、庄飞、李青、 李滨、张祖优、武鑫、程岩、袁明坤、杨廷峰、毛茂德、陈雪秀、郑锐、王广清、郭雪、张娜、邸望 春、 王晓翔、 侯大鹏、公丽丽、王 永霞、程莹、 张婷婷、 叶林、周麟、王浏明、李明亮、王迪、李卜、 熊昌伟、戚文平
6、、顾黄亮、王云峰、马婷、李励立 YD/T 3763.620XX IV YD/T 3764.620XX 1 1 范围 本部分规定了 IT软件或相关服务在采用研发运营一体化（ DevOps）统一开发模式下，如何保障 IT 软件和相关服务的安全，进行风险管理。 本部分适用于具备 IT软件研发交付运营能力的组织实施 IT软件开发和服务过程的能力进行评价和 指导；可供其他相关行业或组织进行参考；也可作为第三方权威评估机构衡量软件开发交付成熟的标 准依据。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本 文件。凡是不注日期的引用文件，其最新版本（包
7、括所有的修改单）适用于本文件。 1GB/T 25069-2010 信息安全技术 术语 2GB/T 37988-2019 信息安全技术 数据安全能力成熟度模型 3 术语、定义 及缩略语 3.1 术语及定义 下列术语和定义适用于本文件。 3.1.1 安全基线 security baseline 为了明确应用需要满足的最基本的安全防护能力而制定的一系列安全配置基准。 3.1.2 安全门限 security threshold 研发运营一体化（ DevOps）能力成熟度模型 第 6 部分：安全及风险管理 YD/T 3764.620XX 2 用于确定安全质量的最低可接受风险级别。 3.1.3 安全态势感
8、知 security situation awareness 基于环境的、动态、整体地洞悉安全风险的能力 ,是以安全大数据为基础 ,从全局视角提升对安全 威胁的发现识别、分析、响应处置能力的一种方式。 3.1.4 安全需求基线 security requirements baseline 经过攻击面分析及威胁建模，确定的满足软件安全风险管理的基本安全需求清单。 3.1.5 安全需求标准库 security requirements standard library 基于信息安全相关的国家法律、法规，行业监管要求，公司的策略与实践，以及信息安全业界的 最佳实践，形成的安全的功能需求、功能性的安全
9、需求以及非功能性安全需求的标准集合。 3.1.6 暴力破解 brute force attack 攻击者通过系统地组合所有可能性（例如登录时用到的账户名、密码），尝试所有的可能性破解 用户的账户名、密码等敏感信息。 3.1.7 分布式拒绝服务攻击 distributed denial of service;DDoS 处于不同位置的多个攻击者同时向一个或数个目标发动攻击，或者一个攻击者控制了位于不同位 置的多台机器并利用这些机器对受害者同时实施攻击。由于攻击的发出点是分布在不同地方的，这类 攻击称为分布式拒绝服务攻击，其中的攻击者可以有多个。拒绝服务指一种系统失去可用性的攻击。 GB/T 250
10、69-2010 3.1.8 攻击面分析 attack surface analysis 程序任何能被用户或者其它程序所访问到的部分，这些暴露给用户的地方往往也是最可能被恶意 攻击者攻击的地方。攻击面分析就是枚举所有访问入库、接口、协议以及可执行代码等的过程。 3.1.9 YD/T 3764.620XX 3 工作项 work item 项目研发过程中的需求、任务、缺陷等。 3.1.10 黑盒安全测试 black-box security test 也称为动态应用安全测试，在测试或运行阶段分析应用程序的动态运行状态。模拟黑客行为对应 用程序进行动态攻击，分析应用程序的反应，从而确定该应用是否易受攻
11、击。 3.1.11 红蓝对抗 reds vs. blues 攻守双方在实际环境中进行网络进攻和防御的一种网络安全攻防演练。 3.1.12 基础设施即代码 infrastructure as code 基于软件开发实践的基础设施自动化方法，强调系统及其配置的日常置备和变更具有一致性和可 重复性。 3.1.13 金丝雀发布 canary release 可以降低在生产环境中引入新软件版本的风险的技术，先将新版本发布给小部分用户，逐渐发布 到整体基础设施并且将新版本发布给所有用户。 3.1.14 蓝绿部署 blue-green deployment 可以保证系统在不间断提供服务的情况下上线的部署方式
12、。 3.1.15 逆向攻击 reverse attack 对软件等进行逆向破解以进行黑客攻击的一种手段。 3.1.16 渗透测试 penetration test YD/T 3764.620XX 4 以未经授权的动作绕过某一系统的安全机制的方式，检查数据处理系统的安全功能，以发行信息 系统安全问题的手段。也成渗透性测试或逆向测试。 GB/T 25069-2010 信息安全技术 术语 3.1.17 威胁建模 threat modeling 通过结构化的方法，系统的识别、评估产品的安全风险和威胁，并针对这些风险、威胁制定消减 措施的一个过程。 3.1.18 研发安全运营一体化 DevSecOps
13、全新的安全及风险管理理念与模式，是指将安全内嵌到应用的全生命周期中，在这种模式下安全 是每个人的责任。 3.1.19 资产 asset 对组织具有价值的任何东西。 GB/T 25069-2010 3.1.20 资产动态感知 asset dynamic awareness 基于资产探测、自动化关联分析等手段，实现对资产变化的动态检测，实时感知设备、端口、服 务等资产的变化。 3.1.21 资产风险管理 asset risk management 通过全面识别企业 it资产，通过漏洞扫描、漏洞情报等手段及时识别资产的安全风险，并进行响 应，实现资产风险的有效管理。 3.1.22 注入攻击 inje
14、ction attacks 将不受信任的数据作为命令或查询的一部分发送到解析器时攻击手段，其本质是把用户输入的数 据当做代码执行，如： SQL注入、 XML注入、命令注入、 CRLF注入等。 3.2 缩略语 YD/T 3764.620XX 5 下列缩略语适用于本文件。 API 应用程序编程接口 Application Programming Interface CD 持续交付 Continuous Delivery CI 持续集成 Continuous Integration CSRF 跨站点请求伪造 Cross Site Request Forgery IDE 集成开发环境 Integrat
15、ed Development Environment MTTR 平均修复时长 Mean Time To Repair RASP 应用运行时自我保护 Runtime Application Self-Protection SDK 软件开发工具包 Software Development Kit XSS 跨站点脚本 Cross-Site Scripting 4 安全及风险管理 本标准规定了 IT软件或相关服务在采用研发安全运营一体化（ DevSecOps）的开发模式下，相比于 传统开发模型发生变化，安全融入每个阶段过程，开发、安全、运营各部门紧密合作。 DevSecOps强调 在安全风险可控的前提
16、下，帮助企业提升 IT效能，更好地实现研发运营一体化。 安全及风险管理分级技术要求包括：控制通用风险、控制开发过程风险、控制交付过程风险、控 制运营过程风险，如表 1所示。 表 1 安全及风险管理分级技术要求 安全及风险管理 控制通用风险 控制开发过程风险 控制交付过程风险 控制运营过程风险 组织建设和人员管理 需求管理 配置管理 监控管理 安全工具链 设计管理 构建管理 运营安全 基础设施管理 开发过程管理 测试管理 应急响应 第三方管理 部署与发布管理 运营反馈 数据管理 YD/T 3764.620XX 6 度量与反馈改进 5 研发运营一体化控制通用风险 在 DevOps 模式下，安全内建
17、于开发、交付、运营过程中，通用风险覆盖三个过程中的共性安全要 求，包括：组织建设和人员管理、安全工具链、基础设施管理、第三方管理、数据管理、度量与反馈 改进，具体要求如表 2 所示。 5.1 组织建设和人员管理 组织建设和人员管理指组织在将安全内建到 DevOps过程中时，需要建设对应的组织负责不同的安 全职责与工作，需要建设组织级的安全文化以及对研发人员、测试人员、技术运营人员等进行安全管 理，包括第三方机构和人员，实现每个人都为安全负责。 5.2 安全工具链 安全工具链，关注研发运营一体化过程中与应用相关的安全工具。安全工具链建设过程中，一方 面，将安全左移研发过程 (DevSec)，并强
18、化运营过程安全（ SecOps），实现将安全工具内嵌到 DevOps 全生命周期；另一方面，安全工具由人工化、单一化向自动化、多元化及智能化方向发展。 5.3 基础设施管理 基础设施作为应用的载体，包括基础资源层、操作系统层、应用中间件层等，基础设施的安全性、 一致性、可靠性与稳定性为应用的安全及风险管理提供基础支撑。 5.4 第三方管理 第三方管理是指围绕应用安全对合作的第三方机构、人员、软件、服务进行安全管理，包括：接 入控制、日常管理与监控、安全风险评估等，第三方机构包括：监管机构、供应商、合作伙伴等。 5.5 数据管理 数据管理是指在研发运营一体化过程中，对从采集、存储、传输、处理、交
19、换到销毁的整个数据 生命周期过程中涉及的各类数据进行安全及合规管理，利用制度、流程及工具等手段保护数据的机密 性、完整性和可用性。 GB/T 37988-2019 5.4 6.1 注： 关于数据安全生命周期及数据分类分级可以参考信息安全技术 数据安全能力成熟度模型。 5.6 度量与反馈改进 度量与反馈改进是指通过对应用的研发、交付、运营过程的安全风险进行度量、展示并反馈给团 队处理和改进的机制。设立清晰可量化的安全度量指标模型并可视化展示度量数据，有助于团队共享 YD/T 3764.620XX 7 信息、识别改进方向并衡量改进效果。另外，设立及时有效的反馈机制，可以加快信息传递速率与准 确性，
20、有助于尽早地发现问题、分析问题、反馈问题、解决问题。度量与反馈改进可以保证整个团队 内部安全信息获取的及时性和一致性，实现基于度量的持续改进。如表 2所示： 表 2 研发运营一体化控制通用风险要求 级别 组织建设和人 员管理 安全工具链 基础设施管理 第三方管理 数据管理 度量与反馈改 进 1 有专职的安全 管理岗位及人 员。 具有漏洞扫描 工 具 ， 如 ： Web 安全扫描 工具、 App 安 全扫描工具、 主机安全扫描 工具等。 1） 生产环境 的管理有安全 管理规范与流 程； 2） 生产环境 具 有 安 全 基 线。 具有第三方管 理的安全规范 与制度，明确 人员管理、数 据安全、服务
21、 器运维等安全 要求。 数据管理具有 基本的安全管 理要求。 安全问题统计 与报告以手工 方式为主。 2 1) 有专门的 安全管理团队 与安全主管， 如：安全部门 等； 2) 有明确的 组织内各角色 的安全职责、 权利和义务； 3) 研 发 人 员、测试人员 和技术运营人 员的安全职责 分离； 4) 有明确的 团队间安全协 作 流 程 和 规 范。 1） 确保安全 工具的有效性 及安全性，具 有一定的安全 规范和要求， 如：定期规则 升级、软件补 丁升级、工具 版本升级等； 2） 具有应用 安全自动化测 试工具及安全 配 置 加 固 工 具，包括但不 限于：源代码 安 全 检 测 工 具、黑盒
22、安全 测试工具、安 全基线检查工 具、主机安全 扫描工具等； 3） 具有自动 化漏洞扫描平 1） 基础设施 的管理有安全 规范与流程， 如：云平台安 全管理、中间 件安全漏洞管 理等； 2） 基础设施 的管理有安全 的工具系统； 3） 具有基础 设施的安全基 线； 4） 定期执行 基础设施安全 基线扫描，及 时发现和处理 安全风险。 1） 具有完善 的第三方管理 安全规范与制 度，如：明确 的第三方人员 引入和办公场 所出入规则、 第三方服务的 访问控制等； 2） 第三方合 作须签署相应 的安全协议； 3） 控制第三 方软件的接入 风险，包括但 不限于：第三 方开源软件、 第三方商业软 件等。
23、 1） 数据管理 具有安全管理 要求，覆盖运 营过程，如： 制 度 、 规 范 等； 2） 具有明确 的数据分类分 级方法，对生 成或收集的数 据进行分类分 级标识，如： 通过打标签的 方式等； 3） 对于不同 环境、类别及 级别的数据具 有安全管控机 制，如：访问 控制、数据加 解密、数据脱 敏等。 1） 仅在局部 领域定义部分 安 全 度 量 指 标； 2） 安全度量 报告以自动化 方式生成和展 示，团队成员 可查看报告； 3） 基于度量 识别的安全问 题纳入系统管 理，并定期反 馈团队； 4） 团队定期 实施改进并取 得效果，如： 每月 /季度一 次、应用上线 前后等。 YD/T 376
24、4.620XX 8 台，具备多维 度扫描工具组 合扫描，具备 周期性巡检机 制； 4） 具有软件 组 成 分 析 工 具，包括但不 限于：开源组 件安全风险检 测工具等。 3 1) 同上，且 需达到以下要 求： 2) 有完善的 安全管理体系 与流程，如： 参考行业的最 佳实践和监管 要求等； 3) 有高效的 团队间安全协 作机制，包括 但不限于：虚 拟安全小组、 定期或不定期 召开团队间会 议、共同协作 处理关键安全 问题等； 4) 已建立安 全专家组织， 负责评审关键 架构设计并建 设安全、研发 与运营团队的 一 体 化 规 范 等； 1） 同上，且 需达到以下要 求： 2） 具有安全 需
25、求 管 理 工 具，并在集成 完成前进行代 码安全检测； 3） 具有威胁 建模及安全需 求管理自动化 平台； 4） 具有开源 组件许可证合 规检测工具； 5） 具有应用 安全自动化测 试工具及安全 配 置 加 固 工 具，并集成到 研发运营一体 化平台； 6） 具有统一 的漏洞管理平 台，对漏洞进 行汇聚及集中 1） 同上，且 需达到以下要 求： 2） 具有统一 的基础设施安 全基线，包括 但不限于：开 发、测试、生 产环境等； 3） 基础设施 的管理采用基 础设施即代码 与自动化方式 管理，实现管 理低风险、可 追 溯 、 可 审 计； 4） 具有安全 的开发环境与 工具，包括但 不限于：安
26、全 的开发工具、 安全的开发配 置 、 安 全 的 CI/CD 工 具 等； 5） 基础设施 1） 同上，且 需达到以下要 求： 2） 通过技术 平台对第三方 合作进行管理 和监控，如： 办公场所与机 房人员出入、 应用的访问和 操作等； 3） 对于因第 三方合作造成 的安全事件、 问题有应急响 应措施； 4） 对第三方 进行定期和按 需的安全风险 评估和审计， 如：通过相关 权威机构安全 评测等。 1） 数据管理 按数据生命周 期进行管理， 具有完善的安 全管理要求及 流程，包括但 不限于制度、 规范、流程、 指南等； 2） 实现对数 据分类分级的 自动化标识、 审核等，对于 不同环境、类
27、别及级别的数 据具有自动化 管控手段； 3） 具备自动 化的数据安全 相 关 管 理 工 具，如：数据 资产管理、数 据脱敏、数据 防泄漏等； 4） 具备数据 使用过程的自 动化监控和审 1） 建立跨领 域、跨组织、 端到端的安全 度量指标体系 并持续更新， 具有部分预测 性指标，如： 漏洞修复率、 安 全 问 题 MTTR、安全覆 盖率等； 2） 具有安全 度量平台，支 持自动生成报 告内容、分类 分级展示、趋 势展示、阈值 设置与预警、 按需定制、多 种图表类型、 订阅等； 3） 安全度量 数 据 完 整 真 实，数据时效 性不低于 T+1 天，度量数据 至 少 半 年 以 YD/T 37
28、64.620XX 9 5) 针对研发 人员、测试人 员和技术运营 人员开展专项 的安全技能培 训； 6) 在 IT 组 织内进行安全 意识教育和培 训，提升团队 成 员 安 全 能 力，建立安全 文化。 的管理，实现 自动化漏洞扫 描、漏洞修复 通知推送、提 供漏洞验证， 支持漏洞按照 种类与风险级 别等维度进行 统计、分析、 展示； 7） 具有统一 的资产风险管 理平台，能对 应用相关的资 产进行风险监 控及管理； 8） 具有自动 化的安全测试 平台； 9） 具备自主 集成外部安全 工具的能力， 如：安全自动 化测试平台集 成多种黑盒安 全 扫 描 工 具 等。 具备良好的抗 攻击与灾备容
29、错能力，能有 效地实现多方 联防联控； 6） 基础设施 支持低风险的 应 用 发 布 方 式。 计机制。 上； 4） 基于度量 识别的安全问 题可自动化反 馈给团队的工 作 项 管 理 平 台； 5） 度量反馈 的安全问题纳 入研发迭代的 待 办 事 项 列 表； 6） 基于度量 分析安全问题 库，反馈针对 性 的 安 全 建 议，如：历史 共性安全缺陷 等。 4 1） 同上，且 需达到以下要 求： 2） 有高级别 的安全管理组 织，履行组织 级的安全治理 职责，如：重 大风险的审阅 和处置策略的 决策等； 1） 同上，且 需达到以下要 求： 2） 应用集成 安全 SDK，具 有包括但不限 于
30、密钥安全、 资 源 操 作 安 全、运行时自 我 防 护 能 力 等，同时具备 1） 同上，且 需达到以下要 求： 2） 具有统一 的基础设施管 理平台； 3） 基础设施 的管理具有部 分智能化安全 能力，如：支 持秒级容灾容 1） 同上，且 需达到以下要 求： 2） 通过自动 化的技术平台 对第三方进行 安全管理、监 控 和 应 急 响 应，如：第三 方安全评级与 风险监控系统 1） 同上，且 需达到以下要 求： 2） 具备数据 流转的自动化 追踪和溯源能 力； 3） 具备数据 安全风险监控 系统，对数据 使用过程中的 1） 同上，且 需达到以下要 求： 2） 建立基于 分级评价的完 整安全
31、度量体 系，如：能力 成 熟 度 模 型 等； 3） 具有安全 度量平台，支 YD/T 3764.620XX 10 3） 有完善的 安 全 专 家 团 队，如：数据 安全、网络安 全等； 4） 有常态化 的安全文化建 设，如：完善 的 培 训 机 制 等。 统一安全管控 平台； 3） 具备全网 资产动态感知 平台，构建资 产安全风险画 像，实时感知 企业资产的风 险变化； 4） 具备自主 研发安全工具 的能力，如： 自研基于流量 的 web 安全扫 描器等； 5） 持续运营 和改进安全工 具，提升安全 工具效能，包 括但不限于安 全策略持续调 优、安全工具 的 能 力 提 升 等。 错切换、安
32、全 风险问题自动 处置等。 等； 3） 通过自动 化方式对第三 方进行实时的 安全风险评估 与审计。 风险进行自动 化的识别、监 控、告警和处 置。 持 成 熟 度 展 示； 4） 团队持续 改进，提升安 全能力的成熟 度； 5） 团队基于 度量反馈主动 持续改进，全 面提升安全效 能，如：漏洞 修复率、误报 率等指标的改 善等； 6） 识别有效 改进，并作为 企业级安全知 识扩展到整个 组织。 5 1） 同上，且 需达到以下要 求： 2） 具有行业 影响力的安全 专家团队，能 有效对行业进 行贡献； 3） 具有安全 组织建设与安 全人员管理的 持 续 改 进 机 制。 1） 同上，且 需达到
33、以下要 求： 2） 具备智能 化软件安全开 发全生命周期 管理平台，智 能 化 威 胁 建 模、智能化安 全测试及智能 化的安全风险 评估； 3） 具备智能 化应用安全态 1） 同上，且 需达到以下要 求： 2） 基础设施 管理具备全面 的智能化安全 能力，能够自 动化发现、分 析和修复环境 问题，及时发 现并处置安全 威胁。 1） 同上，且 需达到以下要 求： 2） 通过智能 化的技术平台 对第三方进行 安全管理、监 控 和 应 急 响 应； 3） 通过智能 化方式对第三 方进行实时的 安全风险评估 1） 同上，且 需达到以下要 求： 2） 具备智能 化数据安全风 险管理能力， 实现对数据安
34、 全风险的态势 感知，实现数 据安全风险的 智能化预测和 处置。 1） 同上，且 需达到以下要 求： 2） 持续改进 安全指标体系 与安全度量平 台，支持深度 智能化、支持 业务决策等。 YD/T 3764.620XX 11 势感知平台， 智能化资产安 全风险感知及 处置，智能化 应用安全威胁 感知及防护。 与审计。 6 研发运营一体化控制开发过程风险 从应用的开发过程开始实施安全风险管理工作，可以保障进入交付过程的代码是安全的，降低后 续交付、运营中的安全风险，保障研发运营一体化的整体安全，包括：需求管理、设计管理和开发过 程管理，具体要求如表 3所示。 6.1 需求管理 需求管理是指将安全
35、工作左移到应用生命周期的源头，在应用的需求阶段即进行安全风险控制， 定义安全需求并采取有效的措施和手段，从而控制开发过程的安全风险。安全需求既要包括功能性的 安全需求，如：认证、授权、安全日志与审计等；又要包括非功能性安全需求，如：健壮性、可用性、 可靠性等。 6.2 设计管理 设计管理关注开发过程中应用架构与设计过程中的安全风险控制。通过攻击面分析、威胁建模等 手段，识别应用潜在的安全风险和威胁，制定措施消除或减少威胁、规避风险，确保应用的安全性。 6.3 开发过程管理 开发过程管理指对编码过程中的安全风险进行管理，通过引入安全编码规范与检测机制降低源代 码中的安全风险。如表 3所示： 表
36、3 研发运营一体化控制开发过程风险要求 级别 需求管理 设计管理 开发过程管理 1 需求包含基本的安全内容。 具有基础的安全设计规范，包 括但不限于：身份认证、访问 控制、加密等。 具有项目级安全编码规范。 2 1） 需求包含安全内容，并纳 入团队整体的需求清单； 2） 分析项目涉及的法律法规 和行业规范要求，并制定合规 1） 同上，且需达到以下要 求： 2） 基于风险级别及业务优先 具有团队级安全编码规范，对 于不同类型编码语言具有相应 的安全编码指南。 YD/T 3764.620XX 12 和安全需求基线，如：个人隐 私风险等； 3） 针对安全需求具有相应的 用例，并明确验收标准，如： 安全需求清单等； 4） 针对不同技术栈，制定相 应的安全需求。 级等对应用进行分级； 3） 制定和发布标准化的安全 性功能，如：统一认证接入 等； 4） 安全设计中具有基础的威 胁建模的分析方法； 5） 基于应用分级，针对应用 开展安全设计评审，并交付安 全设计方案。 3
