NIST 安全软件开发框架 1.1

识别并记录组织软件开发基础设施和流程的所有安全需求，并随时间维护这些需求。例如：示例 1：定义用于保护软件开发基础设施及其组件的政策，包括开发端点，在整个软件开发生命周期（SDLC）中并维持该安全性。示例 2：定义在整个软件开发生命周期（SDLC）中确保软件开发过程安全的策略，并维护该安全性，包括对所开发软件中使用的开源和其他第三方软件组件的安全管理。示例 3：至少每年审查并更新安全要求，或者在有来自内部或外部的新要求，或针对软件开发基础设施发生重大安全事件时尽早进行更新。 示例 4：向受影响的人员传达即将发生的要求变化。 参考文献：BSAFSS：SM.3, DE.1, IA.1, IA.2 BSIMM：CP1.1, CP1.3, SR1.1, SR2.2, SE1.2, SE2.6 EO14028: 4e(ix) IEC62443: SM-7, SM-9 NISTCSF: ID.GV-3 OWASPASVS: 1.1.1 OWASPMASVS: 1.10 OWASPSAMM: PC1-A, PC1-B, PC2-A PCISSLC: 2.1, 2.2 SCFPSSD: 安全开发实践的实施和部署规划 SP80053: SA-1, SA-8, SA-15, SR-3 SP800160: 3.1.2, 3.2.1, 3.2.2, 3.3.1, 3.4.2, 3.4.3 SP800161: SA-1, SA-8, SA-15, SR-3 SP800181: T0414;K0003, K0039, K0044, K0157, K0168, K0177, K0211, K0260, K0261, K0262, K0524;S0010, S0357, S0368;A0033, A0123, A0151

识别并记录组织开发的软件所需满足的所有安全要求，并随时间维护这些要求。 示例： 示例 1：制定政策，明确基于风险的软件架构和设计要求，例如使代码模块化以便于代码重用和更新；在执行过程中将安全组件与其他组件隔离；避免使用未记录的命令和设置；并提供有助于软件获取者安全部署、操作和维护软件的功能。示例 2：定义指定组织软件安全要求的策略，并在软件开发生命周期（SDLC）的关键点验证合规性（例如，通过关卡验证的软件缺陷类别、对已发布软件中发现的漏洞的响应）。示例3：分析可用技术栈的风险（例如，语言、环境、部署模型），并推荐或要求使用相对于其他技术栈能降低风险的栈。示例4：定义策略，指定每个软件版本需要归档的内容（例如代码、包文件、第三方库、文档、数据清单）以及根据软件开发生命周期模型、软件使用寿命结束和其他因素需要保留的时间。示例 5：确保政策涵盖整个软件生命周期，包括通知用户软件即将停止支持的时间以及软件使用寿命结束的日期。示例6：至少每年审查一次所有安全需求，或在收到内部或外部的新需求、已发布软件中发现重大漏洞，或针对组织开发的软件发生重大安全事件时，提前进行审查。示例 7：建立并遵循处理需求例外请求的流程，包括对所有已批准例外进行定期审查。参考：BSAFSS: SC.1-1, SC.2, PD.1-1, PD.1-2, PD.1-3, PD.2-2, SI, PA, CS, AA, LO, EE BSIMM: SM1.1, SM1.4, SM2.2, CP1.1, CP1.2, CP1.3, CP2.1, CP2.3, AM1.2, SFD1.1, SFD2.1, SFD3.2, SR1.1, SR1.3, SR2.2, SR3.3, SR3.4 EO14028: 4e(ix) IEC62443: SR-3, SR-4, SR-5, SD-4 ISO27034: 7.3.2 MSSDL: 2, 5 NISTCSF: ID.GV-3 OWASPMASVS: 1.12 OWASPSAMM: PC1-A, PC1-B, PC2-A, PC3-A, SR1-A, SR1-B, SR2-B, SA1-B, IR1-A PCISSLC: 2.1, 2.2, 2.3, 3.3 SCFPSSD: 建立编码标准和规范 SP80053: SA-8, SA-8(3), SA-15, SR-3 SP800160: 3.1.2, 3.2.1, 3.3.1 SP800161: SA-8, SA-15, SR-3 SP800181: T0414;K0003, K0039, K0044, K0157, K0168, K0177, K0211, K0260, K0261, K0262, K0524;S0010, S0357, S0368;A0033, A0123, A0151

向所有将向组织提供商业软件组件以供组织自身软件重用的第三方传达需求。[原PW.3.1] 示例：示例1：为软件组件定义一套核心安全需求，并将其包含在采购文件、软件合同以及与第三方的其他协议中。示例 2：定义选择软件的安全相关标准；这些标准可以包括第三方的漏洞披露计划和产品安全事件响应能力，或第三方对组织定义的实践的遵守情况。示例 3：要求第三方证明其软件符合组织的安全要求。示例 4：要求第三方为其软件的所有组件提供来源数据和完整性验证机制。示例 5：建立并遵循流程，在第三方软件组件未满足安全要求时处理风险；这应包括对所有批准的要求例外进行定期审查。参考资料：BSAFSS: SM.1, SM.2, SM.2-1, SM。2-4 BSIMM: CP2.4, CP3.2, SR2.5, SR3.2 EO14028: 4e(vi), 4e(ix) IDASOAR: 19, 21 IEC62443: SM-9, SM-10 MSSDL: 7 NISTCSF: ID.SC-3 OWASPSAMM: SR3-A SCAGILE: 需要安全专家协助的任务 8 SCFPSSD: 管理使用第三方组件固有的安全风险 SCSIC: 供应商采购完整性控制 SP80053: SA-4, SA-9, SA-10, SA-10(1), SA-15, SR-3, SR-4, SR-5 SP800160: 3.1.1, 3.1.2 SP800161: SA-4，SA-9，SA-9(1)，SA-9(3)，SA-10，SA-10(1)，SA-15，SR-3，SR-4，SR-5 SP800181: T0203，T0415；K0039；S0374；A0056，A0161

根据需要创建新角色并调整现有角色的职责，以涵盖软件开发生命周期（SDLC）的所有部分。定期审查和维护已定义的角色和职责，并根据需要进行更新。 示例： 示例1：为软件开发团队的所有成员定义与SDLC相关的角色和职责。 示例2：将安全角色整合到软件开发团队中。示例3：为网络安全人员、安全负责人、项目经理和负责人、高级管理层、软件开发人员、软件测试人员、软件保障负责人及人员、产品负责人、运营及平台工程师以及参与SDLC的其他人员定义角色和职责。 示例4：对所有角色和职责进行年度审查。示例5：向受影响的个人教育即将发生的角色和职责变更，并确认这些个人理解这些变更并同意遵循。示例6：实施和使用工具及流程，促进具有SDLC相关角色和职责的人员之间的沟通和参与，例如创建团队讨论的消息通道。示例7：为每个项目指定一组个人或一个团队作为代码负责人。参考资料：BSAFSS：PD.2-1, PD.2-2 BSIMM：SM1.1, SM2.3, SM2.7, CR1.7 EO14028：4e(ix) IEC62443：SM-2, SM-13 NISTCSF：ID.AM-6, ID.GV-2 PCISSLC：1.2 SCSIC：供应商软件开发完整性控制 SP80053：SA-3 SP800160：3.2.1, 3.2.4, 3.3.1 SP800161：SA-3 SP800181：K0233

为所有在安全开发中承担职责的人员提供基于角色的培训。定期审查人员的能力和基于角色的培训，并根据需要更新培训内容。示例：示例 1：记录每个角色培训的预期成果。示例 2：定义为了实现每个角色的预期成果所需的培训类型或课程。示例 3：为每个角色制定培训计划。示例 4：获取或创建每个角色的培训；获取的培训可能需要为组织进行定制。示例 5：衡量结果绩效，以识别培训可能需要改进的领域。参考资料：BSAFSS：PD.2-2 BSIMM：T1.1, T1.7, T1.8, T2.5, T2.8, T2.9, T3.1, T3.2, T3.4 EO14028：4e(ix) IEC62443：SM-4 MSSDL：1 NISTCSF：PR.在 OWASPSAMM：EG1-A，EG2-A PCISSLC：1.3 SCAGILE：操作安全任务 14，15；需要安全专家协助的任务 1 SCFPSSD：规划安全开发实践的实施和部署 SCSIC：供应商软件开发完整性控制 SP80053：SA-8 SP800160：3.2.4，3.2.6 SP800161：SA-8 SP800181：OV-TEA-001，OV-TEA-002；T0030，T0073，T0320；K0204, K0208, K0220, K0226, K0243, K0245, K0252;S0100, S0101;A0004, A0057

获得高层管理或授权官员对安全开发的承诺，并将该承诺传达给所有涉及开发相关角色和职责的人。示例：示例1：任命一个单一领导或领导团队负责整个安全软件开发过程，包括对软件发布到生产环境负责，并根据需要分配职责。示例2：提高授权官员对在整个开发生命周期中未整合安全性开发软件的风险以及通过安全开发实践进行风险缓解的认识。示例3：协助高层管理人员将安全开发支持纳入其与具有开发相关职能和责任的员工的沟通中。示例 4：对所有涉及开发相关角色和职责的人员进行教育，使其了解高层管理对安全开发的承诺以及安全开发对组织的重要性。参考资料：BSIMM: SM1.3, SM2.7, CP2.5 EO14028: 4e(ix) NISTCSF: ID.RM-1, ID.SC-1 OWASP SAMM: SM1.A PCI SSLC: 1.1 SP800181: T0001, T0004

指定每个工具链中必须或应包含哪些工具或工具类型，以减轻已识别的风险，以及工具链组件如何相互集成。示例：示例1：定义工具链类别，并指定每个类别必须使用的工具或工具类型。示例2：确定要集成到开发者工具链中的安全工具。示例 3：定义在工具之间传递的信息以及要使用的数据格式。示例 4：评估工具的签名能力，以在工具链中创建不可更改的记录/日志，以便审计。示例 5：使用自动化技术进行工具链管理和编排。参考资料：BSIMM：CR1.4, ST1.4, ST2.5, SE2.7 CNCFSSCP：保护材料——验证；保护构建流水线——验证、自动化、安全认证/访问；保护工件——验证；保护部署——验证 EO14028: 4e(iii), 4e(ix) MSSDL: 8 OWASPSAMM: IR2-B, ST2-B SCAGILE: 需要安全专家协助的任务 9 SCSIC: 供应商软件交付完整性控制 SP80053: SA-15 SP800161: SA-15 SP800181: K0013, K0178

遵循推荐的安全实践来部署、操作和维护工具及工具链。示例：示例 1：评估、选择并获取工具，并评估每个工具的安全性。示例 2：将工具与其他工具以及现有的软件开发流程和工作流集成。示例 3：对工具链使用基于代码的配置（例如，作为代码的流水线、作为代码的工具链）。示例 4：实施实现可重现构建所需的技术和流程。 示例 5：根据需要更新、升级或更换工具，以解决工具漏洞或增加新的工具功能。 示例 6：持续监控工具及工具日志，以发现潜在的操作和安全问题，包括政策违规和异常行为。示例 7：定期验证每个工具的完整性并检查其来源，以识别潜在问题。示例 8：关于编译器、解释器和构建工具，请参见 PW.6。示例 9：关于实施和维护安全环境，请参见 PO.5。参考文献：BSAFSS: DE.2 BSIMM: SR1.1, SR1.3, SR3。4 CNCFSSCP：保护构建流水线——验证、自动化、受控环境、安全认证/访问；保护制品——验证、自动化、受控环境、加密；保护部署——验证、自动化 EO14028：4e(i)(F)、4e(ii)、4e(iii)、4e(v)、4e(vi)、4e(ix) IEC62443：SM-7 IR8397：2.2 OWASP ASVS：1.14.3、1.14.4、14.1、14.2 OWASP MASVS：7.9 OWASPSCVS: 3, 5 SCAGILE: 需要安全专家协助的任务 9 SCFPSSD: 使用当前的编译器和工具链版本并启用安全编译器选项 SCSIC: 供应商软件交付完整性控制 SP80053: SA-15 SP800161: SA-15 SP800181: K0013, K0178

配置工具以生成其对组织定义的安全软件开发实践支持的成果。例如：示例 1：使用现有工具（例如，工作流跟踪、问题跟踪、价值流映射）创建一个安全开发相关操作的审计轨迹，以用于持续改进。示例 2：确定收集的信息应多久审核一次，并实施必要的流程。示例 3：建立并执行工件数据的安全和保留政策。示例 4：分配创建工具无法生成的任何所需工件的责任。参考文献：BSAFSS：PD.1-5 BSIMM：SM1.4, SM3.4, SR1。3 CNCFSSCP：保护构建管道——验证、自动化、受控环境；保护工件——验证 EO14028：4e(i)(F)、4e(ii)、4e(v)、4e(ix) IEC62443：SM-12、SI-2 MSSDL：8 OWASPSAMM：PC3-B OWASPSCVS：3.13、3.14 PCISSLC：2.5 SCAGILE：需要安全专家协助的任务 9 SCSIC：供应商软件交付完整性控制 SP80053：SA-15 SP800161：SA-15 SP800181：K0013；T0024

定义软件安全检查的标准，并在整个软件开发生命周期中跟踪。示例：示例1：确保这些标准能够充分表明安全风险管理的效果。示例2：定义关键绩效指标（KPI）、关键风险指标（KRI）、漏洞严重性评分及其他软件安全的衡量指标。示例3：将软件安全标准添加到现有的检查中（例如，敏捷软件开发生命周期方法中的“完成定义”)。示例4：审查作为软件开发工作流系统一部分生成的工件，以确定它们是否符合标准。示例5：在工作流和跟踪系统中记录安全检查的批准、拒绝和例外请求。示例 6：在每个开发项目的安全成功与失败的背景下分析收集的数据，并利用结果改进 SDLC。参考文献：BSAFSS：TV.2-1，TV.5-1 BSIMM：SM1.4，SM2.1，SM2.2，SM2.6，SM3.3，CP2.2 EO14028：4e(iv)，4e(v)，4e(ix) IEC62443：SI-1，SI-2，SVV-3 ISO27034：7.3.5 MSSDL：3 OWASPSAMM：PC3-A，DR3-B，IR3-B，ST3-B PCISSLC：3.3 SP80053：SA-15，SA-15(1) SP800160：3.2.1，3。2.5, 3.3.1 SP800161：SA-15, SA-15(1) SP800181：K0153, K0165

实施流程、机制等，以收集和保护支持标准所需的信息。示例：示例 1：使用工具链自动收集能够为安全决策提供信息的数据。示例 2：如果需要，部署额外的工具以支持生成和收集支持标准的信息。示例 3：利用标准自动化决策过程，并定期审查这些过程。 示例 4：仅允许授权人员访问收集的信息，并防止任何信息的更改或删除。 参考资料： BSAFSS: PD.1-4, PD.1-5 BSIMM: SM1.4, SM2.1, SM2.2, SM3.4 EO14028: 4e(iv), 4e(v), 4e(ix) IEC62443: SI-1, SVV-1, SVV-2, SVV-3, SVV-4 OWASPSAMM: PC3-B PCISSLC: 25 SCSIC：供应商软件交付完整性控制 SP80053：SA-15, SA-15(1), SA-15(11) SP800160：3.2.5, 3.3.7 SP800161：SA-15, SA-15(1), SA-15(11) SP800181：T0349；K0153

分离并保护软件开发中涉及的每个环境。例如：示例1：对每个环境使用基于风险的多因素认证和条件访问。示例 2：使用网络分段和访问控制将各个环境彼此隔离，并与生产环境隔离，同时在每个非生产环境内将各个组件相互分离，以减少攻击面以及攻击者的横向移动和权限/访问升级。示例3：执行身份验证并严格限制进入和退出每个软件开发环境的连接，包括将网络访问限制在必要的范围内。示例4：尽量减少对工具链系统（如构建服务）的直接人工访问。持续监控和审计所有访问尝试以及所有特权访问的使用情况。示例 5：尽量减少在非生产环境中使用生产环境的软件和服务。示例 6：定期记录、监控和审计环境之间以及每个环境内各组件之间授权和访问的信任关系。示例7：持续记录和监控开发环境中所有组件的操作和警报，以检测、响应和从尝试性以及实际的网络事件中恢复。示例8：配置涉及分离和保护环境的安全控制和其他工具，以生成其活动的相关产物。示例 9：持续监控部署在各个环境中的所有软件是否存在新的漏洞，并根据基于风险的方法适当响应漏洞。示例 10：按照零信任架构配置并实施措施，以保障环境的托管基础设施安全。参考资料：BSAFSS: DE.1, IA.1, IA.2 CNCFSSCP：保障构建管道安全——受控环境 EO14028：4e(i)(A)、4e(i)(B)、4e(i)(C)、4e(i)(D)、4e(i)(F)、4e(ii)、4e(iii)、4e(v)、4e(vi)、4e(ix) IEC62443：SM-7 NISTCSF：PR.AC-5、PR.DS-7 SCAGILE：需要安全专家协助的任务 11 SCSIC：供应商软件交付完整性控制 SP80053：SA-3(1)、SA-8、SA-15 SP800161：SA-3、SA-8、SA-15 SP800181：OM-NET-001、SP-SYS-001；T0019, T0023, T0144, T0160, T0262, T0438, T0484, T0485, T0553;K0001, K0005, K0007, K0033, K0049, K0056, K0061, K0071, K0104, K0112, K0179, K0326, K0487;S0007, S0084, S0121;A0048

保护并加固开发端点（即软件设计师、开发人员、测试人员、构建人员等使用的端点），以使用基于风险的方法执行与开发相关的任务。示例：示例1：根据批准的加固指南、清单等配置每个开发端点；例如，对所有静态和传输中的敏感数据启用符合FIPS标准的加密。示例 2：配置每个开发端点和开发资源，以提供用户和服务所需的最少功能，并执行最小权限原则。 示例 3：持续监控所有开发端点的安全状态，包括监控和审计所有特权访问的使用情况。示例 4：配置安全控制和其他用于保护和加固开发端点的工具，以生成其活动的产物。示例 5：要求对所有访问开发端点和开发资源的操作进行多因素身份验证。示例 6：在非生产网络上提供专用的开发端点，用于执行所有与开发相关的任务。为所有其他任务在生产网络上提供独立的端点。示例 7：按照零信任架构配置每个开发端点。参考资料：BSAFSS: DE.1-1, IA.1, IA.2 EO14028: 4e(i)(C), 4e(i)(E), 4e(i)(F), 4e(ii), 4e(iii), 4e(v), 4e(vi), 4e(ix) IEC62443: SM-7 NISTCSF: PR.AC-4, PR.AC-7, PR.IP-1, PR.IP-3, PR.IP-12, PR.PT-1, PR.PT-3, DE.CM SCAGILE：需要安全专家协助的任务 11 SCSIC：供应商软件交付完整性控制 SP80053：SA-15 SP800161：SA-15 SP800181：OM-ADM-001, SP-SYS-001；T0484, T0485, T0489, T0553；K0005, K0007, K0077, K0088, K0130, K0167, K0205, K0275；S0076, S0097, S0121, S0158；A0155

根据最低权限原则存储所有形式的代码——包括源代码、可执行代码和配置即代码——以确保只有授权人员、工具、服务等可以访问。示例：示例1：将所有源代码和配置即代码存储在代码库中，并根据代码的性质限制对其的访问。例如，为公众访问而公开的开源代码可能需要保护其完整性和可用性；其他代码也可能需要保护其机密性。示例 2：使用仓库的版本控制功能跟踪对代码所做的所有更改，并对个人账户负责。示例 3：对代码仓库使用提交签名。示例 4：让代码所有者审查并批准他人对代码所做的所有更改。示例 5：使用代码签名来帮助保护可执行文件的完整性。示例 6：使用加密（例如加密哈希）来帮助保护文件完整性。参考文献：BSAFSS：IA.1, IA.2, SM.4-1, DE.1-2；BSIMM：SE2.4；CNCFSSCP：保护源代码—验证、自动化、受控环境、安全认证；材料安全——自动化 EO14028：4e(iii)、4e(iv)、4e(ix) IDASOAR：事实表 25 IEC62443：SM-6、SM-7、SM-8 NISTCSF：PR.AC-4、PR.DS-6、PR.IP-3 OWASP ASVS：1.10、10.3.2 OWASP MASVS：7.1 OWASP SAMM：OE3-B PCI SSLC：5.1、6.1 SCSIC：供应商软件交付完整性控制、供应商软件开发完整性控制 SP80053：SA-10 SP800161：SA-8、SA-10

向软件获取者提供软件完整性验证信息。例如：示例 1：在安全性良好的网站上发布发行文件的加密哈希值。示例 2：使用已建立的证书颁发机构进行代码签名，以便消费者的操作系统或其他工具和服务在使用前可以确认签名的有效性。示例 3：定期审查代码签名流程，包括证书续期、轮换、吊销和保护。参考资料：BSAFSS：SM.4，SM.5，SM.6 BSIMM：SE2.4 CNCFSSCP：保障部署——验证 EO14028：4e(iii)，4e(ix)，4e(x) IEC62443：SM-6，SM-8，SUM-4 NISTCSF：PR.DS-6 NISTLABEL：2.2.2.4 OWASPSAMM：OE3-B OWASPSCVS：4 PCISSLC：6.1，6.2 SCSIC：供应商软件交付完整性控制 SP80053：SA-8 SP800161：SA-8 SP800181：K0178

安全地归档每个软件版本需要保留的必要文件和支持数据（例如，完整性验证信息、来源数据）。示例：示例 1：按照组织既定的政策，将发布文件、相关图像等存储在仓库中。仅允许必要的人员以只读方式访问，其他人不得访问。示例 2：存储和保护发布完整性验证信息和来源数据，例如将其保存在与发布文件分开的位置或对数据进行签名。参考资料：BSAFSS: PD.1-5, DE.1-2, IA.2 CNCFSSCP: 保护工件—自动化、受控环境、加密；部署安全——验证 EO14028: 4e(iii), 4e(vi), 4e(ix), 4e(x) IDASOAR: 25 IEC62443: SM-6, SM-7 NISTCSF: PR.IP-4 OWASPSCVS: 1, 3.18, 3.19, 6.3 PCI SSLC: 5.2, 6.1, 6.2 SCSIC: 供应商软件交付完整性控制 SP80053: SA-10, SA-15, SA-15(11), SR-4 SP800161: SA-8, SA-10, SA-15(11), SR-4

收集、保护、维护并共享每个软件版本所有组件的来源数据（例如，在软件物料清单 [SBOM] 中）。示例：示例 1：根据组织的政策向软件获取者提供来源数据，最好使用基于标准的格式。示例 2：向组织的运营和响应团队提供来源数据，以帮助他们缓解软件漏洞。 示例 3：保护来源数据的完整性，并提供一种方法让接收方验证来源数据的完整性。 示例 4：每当软件的任何组件更新时，更新来源数据。 参考文献：BSAFSS: SM.2 BSIMM: SE3。6 CNCFSSCP：材料安全——验证、自动化 EO14028：4e(vi)、4e(vii)、4e(ix)、4e(x) NTIA SBOM：全部 OWASP SCVS：1.4、2 SCSIC：供应商软件交付完整性控制 SCTPC：维护3 SP80053：SA-8、SR-3、SR-4 SP800161：SA-8、SR-3、SR-4

使用各种风险建模方法——例如威胁建模、攻击建模或攻击面映射——来帮助评估软件的安全风险。示例：示例 1：培训开发团队（特别是安全负责人），或与风险建模专家合作，创建模型并分析如何使用基于风险的方法来传达风险，并确定如何应对这些风险，包括实施缓解措施。示例2：对高风险区域进行更严格的评估，例如保护敏感数据以及保障身份验证、认证和访问控制，包括凭证管理。示例3：审查以前软件的漏洞报告和统计数据，以为安全风险评估提供参考。示例4：使用数据分类方法来识别和描述软件将交互的每种类型的数据。参考文献：BSAFSS：SC.1 BSIMM：AM1.2, AM1.3, AM1.5, AM2.1, AM2.2, AM2.5, AM2.6, AM2.7, SFD2.2, AA1.1, AA1.2, AA1.3, AA2.1 EO14028：4e(ix) IDASOAR：1 IEC62443：SM-4, SR-1, SR-2, SD-1 IR8397：2.1 ISO27034：7.3.3 MSSDL：4 NISTCSF：ID.RA OWASPASVS：1.1.2, 1.2, 1.4, 1.6, 1.8, 1.9, 1.11, 2, 3, 4, 6, 8, 9, 11, 12, 13 OWASPMASVS: 1.6, 1.8, 2, 3, 4, 5, 6 OWASPSAMM: TA1-A, TA1-B, TA3-B, DR1-A PCISSLC: 3.2, 3.3 SCAGILE: 需要安全专家帮助的任务 3 SCFPSSD: 威胁建模 SCTTM: 全部指南 SP80053: SA-8, SA-11(2), SA-11(6), SA-15(5) SP800160: 3.3.4, 3.4.5 SP800161: SA-8, SA-11(2), SA-11(6), SA-15(5) SP800181: T0038, T0062;K0005, K0009, K0038, K0039, K0070, K0080, K0119, K0147, K0149, K0151, K0152, K0160, K0161, K0162, K0165, K0297, K0310, K0344, K0362, K0487, K0624;S0006, S0009, S0022, S0078, S0171, S0229, S0248;A0092, A0093, A0107

跟踪并维护软件的安全需求、风险和设计决策。示例：示例 1：记录对每个风险的应对措施，包括如何实现缓解措施以及对任何获批的安全需求例外的理由。将任何缓解措施添加到软件的安全需求中。示例 2：保存设计决策、风险响应和已批准的例外记录，这些记录可在软件生命周期的其余阶段用于审计和维护。示例 3：定期重新评估所有已批准的安全性需求例外，并根据需要实施变更。参考文献：BSAFSS: SC.1-1, PD.1-1 BSIMM: SFD3.1, SFD3.3, AA2.2, AA3.2 EO14028: 4e(v), 4e(ix) IEC62443: SD-1 ISO27034: 7.3.3 MSSDL: 4 NISTLABEL: 2.2.2.2 OWASPASVS: 1.1.3, 1.1.4 OWASPMASVS: 1.3, 1.6 OWASPSAMM: DR1-B PCISSLC: 3.2, 3.3 SP80053: SA-8, SA-10, SA-17 SP800161: SA-8, SA-17 SP800181: T0256;K0005, K0038, K0039, K0147, K0149, K0160, K0161, K0162, K0165, K0344, K0362, K0487;S0006, S0009, S0078, S0171, S0229, S0248;A0092, A0107

在适当的情况下，应支持使用标准化的安全功能和服务（例如，使软件能够与现有的日志管理、身份管理、访问控制和漏洞管理系统集成），而不是创建专有的安全功能和服务实现。[原PW.4]3] 示例： 示例 1：维护一个或多个用于支持标准化安全功能和服务的模块的软件仓库。 示例 2：确定用于支持标准化安全功能和服务的模块的安全配置，并使这些配置可用（例如，作为配置即代码），以便开发人员可以方便地使用它们。示例 3：定义软件开发中必须支持的安全功能和服务的标准。参考文献：BSAFSS：SI.2-1、SI.2-2、LO.1；BSIMM：SFD1.1、SFD2.1、SFD3.2、SR1.1、SR3.4；EO14028：4e(ix)；IEC62443：SD-1、SD-4；MSSDL：5；OWASP ASVS：1.1.6；OWASP SAMM：SA2-A；SCFPSSD：标准化身份与访问管理；建立日志要求和审计实践

请由 1) 未参与设计的合格人员（或多人）和/或 2) 在工具链中实现的自动化流程对软件设计进行审查，以确认并确保其满足所有安全要求，并妥善处理已识别的风险信息。示例：示例 1：审查软件设计，以确认其符合适用的安全要求。示例2：审查在软件设计过程中创建的风险模型，以确定它们是否能够充分识别风险。示例3：审查软件设计，以确认其是否充分应对风险模型中识别的风险。示例4：让软件设计人员纠正未达到要求的部分。示例5：如果无法满足安全要求，请更改设计和/或风险应对策略。 示例6：记录设计评审的发现，以作为工件（例如，在软件规范中、在问题跟踪系统中、在威胁模型中）。 参考文献： BSAFSS: TV.3 BSIMM: AA1.1, AA1.2, AA1.3, AA2.1, AA3.1 EO14028: 4e(iv), 4e(v), 4e(ix) IEC62443: SM-2, SR-2, SR-5, SD-3, SD-4, SI-2 ISO27034: 73.3 OWASPASVS: 1.1.5 OWASPSAMM: DR1-A, DR1-B PCISSLC: 3.2 SP800181: T0328;K0038, K0039, K0070, K0080, K0119, K0152, K0153, K0161, K0165, K0172, K0297;S0006, S0009, S0022, S0036, S0141, S0171

获取并维护安全可靠的软件组件（例如，软件库、模块、中间件、框架），这些组件来自商业、开源及其他第三方开发者，以供组织的软件使用。示例：示例1：在其预期使用的背景下审核和评估第三方软件组件。如果将来组件要以明显不同的方式使用，请在新的上下文下再次进行审查和评估。示例2：确定软件组件的安全配置，并将其提供出来（例如，以代码形式的配置），以便开发人员可以方便地使用这些配置。示例3：获取来源信息（例如。每个软件组件都进行 SBOM、源代码组成分析、二进制软件组成分析，并分析这些信息以更好地评估组件可能带来的风险。示例 4：建立一个或多个软件仓库，以托管经过批准和审查的开源组件。示例5：维护一份组织批准的商业软件组件及其组件版本的清单，并附上其来源数据。 示例6：指定哪些组件必须包含在要开发的软件中。示例7：实施流程，以将已部署的软件组件更新到新版本，并在所有从这些版本的迁移成功完成之前，保留旧版本的软件组件。 示例8：如果无法确认所获取的二进制文件的完整性或来源，则在验证源代码的完整性和来源后，从源代码构建二进制文件。 参考文献：BSAFSS: SM。2 BSIMM: SFD2.1, SFD3.2, SR2.4, SR3.1, SE3.6 CNCFSSCP: 材料安全—验证 EO14028: 4e(iii), 4e(vi), 4e(ix), 4e(x) IDASOAR: 19 IEC62443: SM-9, SM-10 MSSDL: 6 NISTCSF: ID.SC-2 OWASPASVS: 1.1.6 OWASPSAMM: SA1-A OWASPSCVS: 4 SCSIC: 供应商采购完整性控制 SCTPC: 维护 SP80053: SA-4, SA-5, SA-8(3), SA-10(6), SR-3, SR-4 SP800161: SA-4, SA-5, SA-8(3), SA-10(6), SR-3, SR-4 SP800181: K0039

按照软件开发生命周期（SDLC）流程，在内部创建和维护安全性良好的软件组件，以满足无法通过第三方软件组件更好满足的常见内部软件开发需求。例如：示例 1：在创建和维护组件时，遵循组织制定的安全实践，以实现安全的软件开发。示例 2：确定软件组件的安全配置，并使其可用（例如，作为配置即代码），以便开发人员可以轻松使用这些配置。示例 3：为这些组件维护一个或多个软件仓库。示例 4：指定必须包含在待开发软件中的组件。示例5：实施流程以将已部署的软件组件更新到较新版本，并在所有从这些版本的过渡成功完成之前，维护软件组件的旧版本。参考资料：BSIMM：SFD1.1, SFD2.1, SFD3.2, SR1.1 EO14028：4e(ix) IDASOAR：19 OWASPASVS：1.1.6 SCTPC：MAINTAIN SP80053：SA-8(3) SP800161：SA-8(3) SP800181：SP-DEV-001

验证所获取的商业、开源及所有其他第三方软件组件在其整个生命周期内是否符合组织定义的要求。例如：示例 1：定期检查供应商尚未修复的软件模块和服务中是否存在公开已知的漏洞。示例2：在工具链中构建对软件组件已知漏洞的自动检测。示例3：使用商业服务的现有结果来审查软件模块和服务。示例4：确保每个软件组件仍在积极维护中且未达到生命周期终点；这应包括对被修复软件中新发现的漏洞。示例 5：为每个不再维护或在不久的将来无法使用的软件组件制定行动计划。示例 6：通过数字签名或其他机制确认软件组件的完整性。示例 7：审查、分析和/或测试代码。参见 PW.7 和 PW.8。参考文献：BSAFSS: SC.3-1, SM.2-1, SM.2-2, SM.2-3, TV.2, TV.3 BSIMM: CP3.2, SR2.4, SR3.1, SR3.2, SE2.4, SE3.6 CNCFSSCP：材料安全——验证，自动化 EO14028：4e(iii)、4e(iv)、4e(vi)、4e(ix)、4e(x) IDASOAR：21 IEC62443：SI-1、SM-9、SM-10、DM-1 IR8397：2.11 MSSDL：7 NISTCSF：ID.SC-4、PR.DS-6 NISTLABEL：2.2.2.2 OWASPASVS：10、14.2 OWASPMASVS：7.5 OWASPSAMM：TA3-A、SR3-B OWASPSCVS：4、5、6 PCISSLC：3.2、3.4、4.1 SCAGILE：需要安全专家协助的任务 8 SCFPSSD：管理使用第三方组件固有的安全风险 SCSIC：供应商采购完整性控制、同行评审和安全测试 SCTPC：维护、评估 SP80053：SA-9, SR-3, SR-4, SR-4(3), SR-4(4) SP800160：3.1.2, 3.3.8 SP800161：SA-4, SA-8, SA-9, SA-9(3), SR-3, SR-4, SR-4(3), SR-4(4) SP800181：SP-DEV-002; K0153, K0266; S0298

遵循所有适用于开发语言和环境的安全编码实践，以满足组织的要求。例如：示例1：验证所有输入，并验证和正确编码所有输出。示例2：避免使用不安全的函数和调用。示例3：检测错误，并优雅地处理它们。示例4：提供日志记录和追踪功能。示例 5：使用带有自动化功能的开发环境，这些功能鼓励或要求使用安全编码实践，并提供即时在位培训。示例 6：当自动化方法不足或不可用时，遵循手动确保符合安全编码实践的程序。示例 7：使用工具（例如，代码检查工具、格式化工具）来标准化源代码的风格和格式。示例 8：检查开发语言和环境中常见的其他漏洞。示例 9：让开发人员审查他们自己的可读代码，以补充（而不是替代）其他人或工具执行的代码审查。参见 PW.7。参考文献：BSAFSS: SC.2, SC.3, LO.1, EE.1 BSIMM: SR3.3, CR1.4, CR3.5 EO14028: 4e(iv), 4e(ix) IDASOAR: 2 IEC62443: SI-1, SI-2 ISO27034: 7.3.5 MSSDL: 9 OWASPASVS: 1.1.7, 1.5, 1.7, 5, 7 OWASPMASVS: 7.6 SCFPSSD: 建立日志要求和审计实践，使用代码分析工具早期发现安全问题，安全处理数据，处理错误，仅使用安全函数 SP800181: SP-DEV-001;T0013, T0077, T0176;K0009, K0016, K0039, K0070, K0140, K0624;S0019, S0060, S0149, S0172, S0266;A0036, A0047

使用提供功能以提高可执行文件安全性的编译器、解释器和构建工具。示例：示例1：使用最新版本的编译器、解释器和构建工具。示例2：在部署或更新编译器、解释器和构建工具时遵循变更管理流程，并审计所有工具的意外更改。示例 3：定期验证编译器、解释器和构建工具的真实性和完整性。参见 PO.3。参考资料：BSAFSS：DE.2-1 BSIMM：SE2。4 CNCFSSCP：保障构建流水线安全—验证、自动化 EO14028：4e(iv)、4e(ix) IEC62443：SI-2 MSSDL：8 SCAGILE：运营安全任务 3 SCFPSSD：使用当前编译器和工具链版本并确保编译器选项安全 SCSIC：供应商软件开发完整性控制 SP80053：SA-15 SP800161：SA-15

确定应使用哪些编译器、解释器和构建工具功能，以及如何配置每一项功能，然后实施并使用批准的配置。示例：示例 1：在编译过程中启用会对安全性差的代码发出警告的编译器功能。示例 2：实现“干净构建”概念，将所有编译器警告视为错误并消除，除非被确定为误报或无关警告。示例 3：在专门的、高度受控的构建环境中执行所有构建。示例 4：启用编译器功能，这些功能可以随机化或混淆执行特性，例如内存位置的使用，否则这些特性是可预测的，从而可能被利用。 示例 5：进行测试以确保这些功能按预期工作，并且不会意外引发任何操作问题或其他问题。 示例 6：持续验证所批准的配置是否正在使用。示例 7：将已批准的工具配置以代码化配置的形式提供，以便开发人员可以方便地使用它们。参考资料：BSAFSS：DE.2-3，DE.2-4，DE.2-5 BSIMM：SE2.4，SE3.2 CNCFSSCP：构建管道安全—验证，自动化 EO14028：4e(iv)，4e(ix) IEC62443：SI-2 IR8397：2.5 MSSDL：8 OWASP ASVS：14.1，14.2.1 OWASP MASVS：7.2 PCI SSLC：3。2 SCAGILE：操作安全任务 8 SCFPSSD：使用当前的编译器和工具链版本以及安全编译器选项 SCSIC：供应商软件开发完整性控制 SP80053：SA-15, SR-9 SP800161：SA-15, SR-9 SP800181：K0039, K0070

确定是否应使用代码审查（由人工直接查看代码以发现问题）和/或代码分析（使用工具以完全自动或与人工结合的方式发现代码中的问题），根据组织的定义进行。示例：示例 1：遵循组织的政策或指南，确定何时应进行代码审查以及如何进行代码审查。这可能包括第三方代码以及内部编写的可重用代码模块。示例 2：遵循组织的政策或指南，确定何时应进行代码分析以及如何进行分析。示例 3：根据软件的开发阶段选择代码审查和/或分析方法。参考文献：BSIMM: CR1.5 EO14028: 4e(iv), 4e(ix) IEC62443: SM-5, SI-1, SVV-1 NISTLABEL: 2.2.2.2 SCSIC：同行评审和安全测试 SP80053：SA-11 SP800161：SA-11 SP800181：SP-DEV-002；K0013, K0039, K0070, K0153, K0165；S0174

根据组织的安全编码标准执行代码审查和/或代码分析，并在开发团队的工作流程或问题跟踪系统中记录和分类所有发现的问题及推荐的整改措施。 示例： 示例 1：对代码进行同行评审，并将任何现有的代码审查、分析或测试结果作为同行评审的一部分进行审核。示例 2：使用专家审查员检查代码是否存在后门或其他恶意内容。示例 3：使用能够促进同行审查过程的同行评审工具，并记录所有讨论和其他反馈。示例 4：使用静态分析工具自动检查代码的漏洞及其是否符合组织的安全编码标准，由人工对工具报告的问题进行审核并在必要时进行修复。 示例 5：使用审核清单来验证代码是否符合要求。示例 6：使用自动化工具持续识别并修复已记录和验证的不安全软件实践，同时将可读代码提交到代码仓库。示例 7：识别并记录发现问题的根本原因。示例 8：将代码审查和分析中获得的经验教训记录在开发人员可以访问和搜索的 Wiki 中。参考文献：BSAFSS: TV.2, PD.1-4 BSIMM: CR1。2, CR1.4, CR1.6, CR2.6, CR2.7, CR3.4, CR3.5 EO14028: 4e(iv), 4e(v), 4e(ix) IDASOAR: 3, 4, 5, 14, 15, 48 IEC62443: SI-1, SVV-1, SVV-2 IR8397: 2.3, 2.4 ISO27034: 7.3.6 MSSDL: 9, 10 NISTLABEL: 2.2.2.2 OWASPASVS: 1.1.7, 10 OWASPMASVS: 7.5 OWASPSAMM: IR1-B, IR2-A, IR2-B, IR3-A PCISSLC: 3.2, 4.1 SCAGILE: 运营安全任务 4, 7;需要安全专家帮助的任务 10 SCFPSSD：使用代码分析工具提前发现安全问题，使用静态分析安全测试工具，执行安全功能/缓解措施的手动验证 SCSIC：同行评审和安全测试 SP80053：SA-11, SA-11(1), SA-11(4), SA-15(7) SP800161：SA-11, SA-11(1), SA-11(4), SA-15(7) SP800181：SP-DEV-001, SP-DEV-002;T0013, T0111, T0176, T0267, T0516;K0009, K0039, K0070, K0140, K0624;S0019, S0060, S0078, S0137, S0149, S0167, S0174, S0242, S0266;A0007, A0015, A0036, A0044, A0047

确定是否应执行可执行代码测试，以发现以前的审查、分析或测试未识别的漏洞，如果需要，应使用哪种类型的测试。示例：示例 1：遵循组织的政策或指南，确定何时应进行代码测试以及如何进行测试（例如，在沙箱环境中）。这可能包括第三方可执行代码以及内部开发的可重用可执行代码模块。示例 2：根据软件的阶段选择测试方法。参考文献：BSAFSS: TV.3 BSIMM: PT2.3 EO14028: 4e(ix) IEC62443: SVV-1, SVV-2, SVV-3, SVV-4, SVV-5 NISTLABEL: 2.2.2.2 SCSIC: 同行评审和安全测试 SP80053: SA-11 SP800161: SA-11 SP800181: SP-DEV-001, SP-DEV-002;T0456;K0013, K0039, K0070, K0153, K0165, K0342, K0367, K0536, K0624;S0001, S0015, S0026, S0061, S0083, S0112, S0135

确定测试范围，设计测试，执行测试，并记录结果，包括在开发团队的工作流程或问题跟踪系统中记录和分类所有发现的问题及推荐的修复措施。示例：示例 1：对安全功能进行全面的功能测试。示例 2：将动态漏洞测试集成到项目的自动化测试套件中。示例3：将先前报告的漏洞测试纳入项目测试套件，以确保错误不会被重新引入。示例4：在制定测试计划时，考虑软件在生产环境中使用的基础设施和技术栈。示例5：使用模糊测试工具查找输入处理问题。示例6：如果有资源可用，使用渗透测试来模拟攻击者在高风险场景中可能尝试破坏软件的方式。示例7：识别并记录发现问题的根本原因。示例8：将代码测试中学到的经验记录在开发人员可以访问和搜索的维基中。示例9：在制定测试计划时使用源代码、设计记录及其他资源。参考资料：BSAFSS：TV.3, TV.5, PD.1-4 BSIMM：ST1.1, ST1.3, ST1.4, ST2.4, ST2.5, ST2.6, ST3.3, ST3.4, ST3.5, ST3.6, PT1.1, PT1.2, PT1.3, PT3.1 EO14028：4e(iv), 4e(v), 4e(ix) IDASOAR：7, 8, 10, 11, 38, 39, 43, 44, 48, 55, 56, 57 IEC62443：SM-5, SM-13, SI-1, SVV-1, SVV-2, SVV-3, SVV-4, SVV-5 IR8397：2.6, 2.7, 2.8, 2.9, 2.10, 2.11 ISO27034：7.3.6 MSSDL：10, 11 NISTLABEL：2.2.2.2 OWASPMASVS：7.5 OWASPSAMM：ST1-A、ST1-B、ST2-A、ST2-B、ST3-A PCISSLC：4.1 SCAGILE：操作安全任务10、11；需要安全专家协助的任务 4, 5, 6, 7 SCFPSSD：执行动态分析安全测试、模糊解析器测试、网络漏洞扫描、执行安全功能/缓解措施的自动化功能测试、执行渗透测试 SCSIC：同行评审和安全测试 SP80053：SA-11，SA-11(5)，SA-11(8)，SA-15(7) SP800161：SA-11，SA-11(5)，SA-11(8)，SA-15(7) SP800181：SP-DEV-001，SP-DEV-002；T0013, T0028, T0169, T0176, T0253, T0266, T0456, T0516;K0009, K0039, K0070, K0272, K0339, K0342, K0362, K0536, K0624;S0001, S0015, S0046, S0051, S0078, S0081, S0083, S0135, S0137, S0167, S0242;A0015

通过确定如何配置每个影响安全的设置或与安全相关的设置来定义安全基线，以确保默认设置是安全的，并且不会削弱平台、网络基础设施或服务提供的安全功能。示例： 示例 1：进行测试以确保设置，包括默认设置，按预期工作，并且不会无意中导致任何安全漏洞、操作问题或其他问题。 参考文献： BSAFSS: CF.1 BSIMM: SE2.2 EO14028: 4e(iv), 4e(ix) IDASOAR: 23 IEC62443: SD-4, SVV-1, SG-1 ISO27034: 7.3.5 SCAGILE：需要安全专家协助的任务 12 SCSIC：供应商软件交付完整性控制、供应商软件开发完整性控制 SP800181：SP-DEV-002；K0009, K0039, K0073, K0153, K0165, K0275, K0531；S0167

实施默认设置（或默认设置组，如果适用），并为软件管理员记录每个设置。示例：示例1：验证已批准的配置是否已应用于软件。示例2：记录每个设置的用途、选项、默认值、安全相关性、潜在操作影响以及与其他设置的关系。示例 3：使用权威的编程技术机制记录每个设置如何被软件管理员实施和评估。 示例 4：以可用格式存储默认配置，并在修改时遵循变更控制实践（例如，配置即代码）。 参考文献： BSAFSS: CF.1 BSIMM: SE2.2 EO14028: 4e(iv), 4e(ix) IDASOAR: 23 IEC62443: SG-3 OWASPSAMM: OE1-A PCISSLC: 8.1, 82 SCAGILE：需要安全专家帮助的任务 12 SCFPSSD：验证安全配置和平台缓解措施的使用 SCSIC：供应商软件交付完整性控制，供应商软件开发完整性控制 SP80053：SA-5, SA-8(23) SP800161：SA-5, SA-8(23) SP800181：SP-DEV-001；K0009, K0039, K0073, K0153, K0165, K0275, K0531

从软件获取者、用户和公开来源收集有关软件及其使用的第三方组件潜在漏洞的信息，并调查所有可靠的报告。例如：示例1：通过手动或自动方式监控漏洞数据库、安全邮件列表及其他漏洞报告来源。示例 2：使用威胁情报来源更好地了解漏洞通常是如何被利用的。 示例 3：自动审查所有软件组件的来源和软件组成数据，以识别它们可能存在的任何新漏洞。 参考文献：BSAFSS: VM.1-3, VM.3 BSIMM: AM1.5, CMVM1.2, CMVM2.1, CMVM3.4, CMVM3.7 CNCFSSCP：保护材料——验证 EO14028：4e(iv)、4e(vi)、4e(viii)、4e(ix) IEC62443：DM-1、DM-2、DM-3 ISO29147：6.2.1、6.2.2、6.2.4、6.3、6.5 ISO30111：7.1.3 OWASPSAMM：IM1-A、IM2-B、EH1-B OWASPSCVS：4 PCISSLC：3.4、4.1、9。1 SCAGILE：操作安全任务 5 SCFPSSD：漏洞响应与披露 SCTPC：MONITOR1 SP80053：SA-10, SR-3, SR-4 SP800161：SA-10, SR-3, SR-4 SP800181：K0009, K0038, K0040, K0070, K0161, K0362;S0078

审查、分析和/或测试软件代码，以识别或确认先前未被发现的漏洞的存在。 示例： 示例 1：配置工具链，以对所有受支持的版本定期或持续执行自动化代码分析和测试。 示例 2：参见 PW.7 和 PW.8。 参考资料：BSAFSS: VM.1-2, VM.2-1 BSIMM: CMVM3.1 EO14028: 4e(iv), 4e(vi), 4e(viii), 4e(ix) IEC62443: SI-1, SVV-2, SVV-3, SVV-4, DM-1, DM-2 ISO27034: 7.3.6 ISO29147: 6.4 ISO30111: 7.1.4 PCISSLC: 3.4, 4.1 SCAGILE: 运营安全任务 10, 11 SP80053: SA-11 SP800161: SA-11 SP800181: SP-DEV-002;K0009, K0039, K0153

制定一项涉及漏洞披露和修复的政策，并实施支持该政策所需的角色、职责和流程。示例：示例1：建立漏洞披露计划，并让安全研究人员能够轻松了解您的计划并报告可能存在的漏洞。示例 2：建立产品安全事件响应团队（PSIRT）和相应流程，以处理漏洞报告和事件的响应，包括为所有相关方制定沟通计划。示例3：制定安全响应操作手册，以处理一般报告的漏洞、零日漏洞报告、在实际环境中被利用的漏洞，以及涉及多个方和开源软件组件的重大持续事件。 示例4：定期进行产品安全事件响应流程的演练。 参考资料：BSAFSS: VM.1-1, VM.2；BSIMM: CMVM1.1, CMVM2.1, CMVM3.3, CMVM3。7 EO14028：4e(viii)、4e(ix) IEC62443：DM-1、DM-2、DM-3、DM-4、DM-5 ISO29147：全部 ISO30111：全部 MSSDL：12 NIST标签：2.2.2.3 OWASPMASVS：1.11 OWASPSAMM：IM1-A、IM1-B、IM2-A、IM2-B PCISSLC：9.2、9.3 SCFPSSD：漏洞响应与披露 SP80053：SA-15(10) SP800160：3.3.8 SP800161：SA-15(10) SP800181：K0041、K0042、K0151、K0292、K0317；S0054；A0025 SP800216：全部

分析每个漏洞，以收集足够的信息来评估风险，从而规划其修复或其他风险应对措施。示例：示例1：使用现有的问题跟踪软件记录每个漏洞。示例2：根据漏洞可被利用的可能性、被利用后可能造成的影响以及其他相关特征，对每个漏洞进行风险计算。参考资料：BSAFSS: VM.2 BSIMM: CMVM1。2, CMVM2.2 EO14028: 4e(iv)、4e(viii)、4e(ix) IEC62443: DM-2, DM-3 ISO30111: 7.1.4 NISTLABEL: 2.2.2.2 PCISSLC: 3.4, 4.2 SCAGILE: 运营安全任务1，需要安全专家协助的任务10 SP80053: SA-10, SA-15(7) SP800160: 3.3.8 SP800161: SA-15(7) SP800181: K0009, K0039, K0070, K0161, K0165;S0078

为漏洞制定和实施风险应对措施。示例：示例 1：根据风险做出决策，确定每个漏洞是进行修复还是通过其他方式（如风险接受、风险转移）来处理风险，并优先考虑要采取的任何行动。示例 2：如果某个漏洞尚无永久解决方案，应确定在永久解决方案可用之前如何对该漏洞进行临时缓解，并将该临时缓解措施添加到计划中。示例 3：制定并发布安全公告，为软件使用者提供必要的信息，包括漏洞的描述、如何发现易受攻击的软件实例以及如何解决这些问题（例如，在哪里获取补丁以及补丁在软件中做了哪些更改；可能需要更改哪些配置设置；如何实施临时解决方法）。示例 4：通过自动化且可靠的传递机制向受让方提供修复措施。单个修复措施可以解决多个漏洞。 示例 5：根据需要更新设计决策、风险应对和已批准例外的记录。参见 PW.1.2。 参考资料： BSAFSS: VM.1-1, VM-2 BSIMM: CMVM2.1 EO14028: 4e(iv), 4e(vi), 4e(viii), 4e(ix) IEC62443: DM-4 ISO30111: 7.1.4, 7.1.5 NISTLABEL: 2.2.2.2 PCISSLC: 41, 4.2, 10.1 SCAGILE：操作安全任务 2 SCFPSSD：修复漏洞，识别缓解因素或解决方法 SCTPC：缓解 SP80053：SA-5, SA-10, SA-11, SA-15(7) SP800160：3.3.8 SP800161：SA-5, SA-8, SA-10, SA-11, SA-15(7) SP800181：T0163, T0229, T0264;K0009, K0070

分析已识别的漏洞以确定其根本原因。示例：示例 1：记录发现问题的根本原因。示例 2：通过根本原因分析在开发人员可以访问和搜索的 wiki 中记录经验教训。参考资料：BSAFSS: VM.2-1 BSIMM: CMVM3.1, CMVM3.2 EO14028: 4e(ix) IEC62443: DM-3 ISO30111: 7.1.4 OWASPSAMM: IM3-A PCISSLC: 4.2 SCFPSSD：安全开发生命周期反馈 SP800181：T0047、K0009、K0039、K0070、K0343

随着时间的推移分析根本原因以识别模式，例如某个特定的安全编码实践没有被持续遵循。例子：例子1：通过根本原因分析将经验教训记录在开发人员可以访问和搜索的维基中。例子2：在工具链中添加机制以自动检测未来的根本原因实例。示例 3：更新手动流程以检测未来根本原因的实例。参考文献：BSAFSS: VM.2-1, PD.1-3 BSIMM: CP3.3, CMVM3.2 EO14028: 4e(ix) IEC62443: DM-4 ISO30111: 7.1.7 OWASPSAMM: IM3-B PCISSLC: 2.6, 4.2 SCFPSSD: 安全开发生命周期反馈 SP800160: 3.3.8 SP800181: T0111, K0009, K0039, K0070, K0343

检查软件是否存在类似漏洞，以根除某类漏洞，并主动修复，而不是等待外部报告。 示例：示例 1：参见 PW.7 和 PW.8。 参考资料：BSAFSS: VM.2 BSIMM: CR3.3, CMVM3.1 EO14028: 4e(iv), 4e(viii), 4e(ix) IEC62443: SI-1, DM-3, DM-4 ISO30111: 7.1.4 PCISSLC: 4.2 SP80053: SA-11 SP800161: SA-11 SP800181: SP-DEV-001, SP-DEV-002; K0009, K0039, K0070

审查 SDLC（软件开发生命周期）流程，并在适当情况下进行更新，以防止（或减少）根本原因在软件更新或新创建的软件中再次发生。示例：示例 1：通过根本原因分析，将经验教训记录在开发人员可以访问和搜索的维基中。示例 2：规划并实施对相关 SDLC 实践的变更。参考文献：BSAFSS: PD.1-3, BSIMM: CP3.3，CMVM3.2 EO14028：4e(ix) IEC62443：DM-6 ISO30111：7.1.7 MSSDL：2 PCISSLC：2.6，4.2 SCFPSSD：安全开发生命周期反馈 SP80053：SA-15 SP800161：SA-15 SP800181：K0009, K0039, K0070