《安全软件开发框架(SSDF) 1.1:降低软件漏洞风险的建议》解读（三）

安全软件开发框架SSDF是由美国国家标准与技术研究院发布的关于安全软件开发的一组实践，帮助开发组织减少发布的软件中的漏洞数量，减少利用未检测到或未解决的漏洞的潜在影响，从根本上解决漏洞防止再次发生。本文根据《Secure Software Development Framework (SSDF) Version 1.1:Recommendations for Mitigating the Risk of Software Vulnerabilities》文档翻译整理，本文是第三部分，主要是该框架的安全实践列表以及相应的参考中的组织准备部分。 

表1:安全软件开发框架(SSDF)1.1版本

实践1（组织准备）	任务	概念实现参考示例	参考
定义软件开发的安全要求（PO.1）： 确保随时了解软件开发的安全要求，以便在整个SDLC中考虑到这些要求，并且由于需求信息可以统一收集并共享，因此可以最大限度地减少重复工作。包括来自内部来源（如组织的政策、业务目标和风险管理战略）和外部来源（如适用的法律法规）的要求。	PO.1.1:确定并记录软件开发基础设施和过程的所有安全要求，并长期维护这些要求。	示例1：保护整个SDLC中的软件开发基础架构及其组件(包括开发端点)的安全并维护该安全。 示例2：保护整个SDLC中的软件开发过程的安全，包括正在开发的软件所使用的开源和其他第三方软件组件的安全性。 示例3：至少每年审查和更新一次安全要求，如果内部或外部来源有新的要求，或者发生了针对软件开发基础设施的重大安全事件，应尽快审查和更新安全要求。 示例4：就即将发生的需求变更对相关角色进行培训。	不一一展示，需要原文件可私信我获取
	PO.1.2:确定并记录所开发软件要满足的所有安全要求，并长期维护这些要求。	示例1：定义并指定基于风险的软件体系结构和设计需求的策略，例如使代码模块化以促进代码重用和更新；在执行期间将安全组件与其他组件隔离；避免未记录的命令和设置；提供相关功能帮助软件收购者安全部署、操作和维护软件。 示例2：定义并规定组织软件安全要求的策略，并在SDLC中的关键点验证合规性（例如，由gates验证的软件缺陷类别、对已发布软件中漏洞的实时响应）。 示例3：分析适用技术堆栈（例如，语言、环境、部署模型）的风险，并建议或要求使用风险较低的堆栈。 示例4：根据SDLC模型、软件寿命及其他因素，指定每个软件版本需要归档的内容（例如，代码、包文件、第三方库、文档、数据清单）以及需要保留多长时间。 示例5：确保策略覆盖整个软件生命周期，包括通知用户软件支持即将结束和软件寿命终止的日期。 示例6：至少每年审查一次所有安全要求，如果内部或外部来源有新的要求，发布的软件中发现了重大漏洞，或者发生了针对组织开发的软件的重大安全事件，应尽早审查。 示例7:建立并遵循处理需求异常请求的流程，包括对所有已批准的异常请求进行定期审查。
	PO.1.3:将要求传达给向组织提供商业软件组件的所有第三方。[原PW.3.1]	示例1：定义软件组件的核心安全需求集，并将其包含在采购文档、软件合同和与第三方签订的其他协议中。 示例2：定义选择软件的安全相关标准；标准可以包括第三方的漏洞披露计划和产品安全事件响应能力，或者第三方对相关方面的履约情况。 示例3：要求第三方证明其软件符合组织的安全要求。 示例4：要求第三方为其软件的所有组件提供来源数据和完整性验证机制。 示例5：当需要购买的第三方软件组件不符合安全要求时，要建立并遵循流程以解决风险；对所有已批准的例外需求情况的定期审查也应该这样。

实践2（组织准备）	任务	概念实现参考示例	参考
实施角色和责（PO.2）： 确保参与SDLC的组织内外的每个人都能够在整个SDLC中履行与SDLC相关的角色和责任。	PO.2.1:根据需要创建新角色或调整现有角色的职责，以涵盖SDLC的所有部分。定期审查和维护已定义的角色和职责，并根据需要定期更新。	示例1:明确软件开发团队中所有成员在SDLC中的角色和职责。 示例2:将安全角色集成到软件开发团队中。 示例3:明确网络安全员工、安全负责人、项目经理和主管、高级管理层、软件开发人员、软件测试人员、软件保证主管和员工、产品所有者、运营和平台工程师以及参与SDLC的其他人员的角色和职责。 示例4：对所有角色和责任进行年度审查。 示例5：如果角色和责任发生变更，要提前对相关人员进行培训，并确认其理解这些变更并同意遵守这些变更。 示例6：采用相关工具和流程，促进具有SDLC相关角色和职责的个人之间的沟通和参与，例如为团队讨论创建消息传递渠道。 示例7:为每一个项目都指定一个组或一个团队作为代码所有者。	不一一展示，需要原文件可私信我获取
	PO.2.2：为所有负责安全开发的人员提供基于角色的培训。定期审查人员熟练程度和参与培训的情况，并根据需要更新培训。	示例1：记录每个角色的预期培训结果。 示例2：为实现每个角色的预期结果设计培训或课程类型。 示例3：为每个角色创建培训计划。 示例4：根据不同组织地需求，定制化地为每一个角色设计培训内容。 示例5：制定绩效指标，不断优化培训的效果。
	PO.2.3：向最高管理层或相关授权人员获取获取有关安全发展的承诺，并将这份承诺传达给与之相关的所有角色和相关人。	示例1:指定一个领导者或领导团队，负责整个安全软件开发过程，包括负责将软件发布到生产环境，并在适当的时候委派职责。 示例2：提高授权人对在整个开发生命周期中不集成安全性的情况下开发软件的风险以及安全开发实践提供的风险缓解的认识。 示例2:提高授权人对开发软件的风险的认识，对整个开发生命周期中的集成安全性以及安全开发实践保持足够的重视。 示例3：协助上级管理层将安全的开发的相关要求纳入到与具有开发相关角色和职责的人员的沟通中。 示例4:对所有相关的角色和职责的人员进行培训，使其了解高级管理层对安全发展的承诺以及安全发展对组织的重要性。

实践3（组织准备）	任务	概念实现参考示例	参考
实施支持工具（PO.3）： 使用自动化减少人力，提高整个SDLC中安全实践的准确性、可重复性、可用性和全面性，并提供记录和演示这些实践使用的方法。工具链和工具可以在组织的不同层次使用，例如组织范围或特定项目，并且可以处理SDLC的特定部分，就像构建管道一样。	PO.3.1：明确每个工具链中必须或应该包含哪些工具或工具类型，以及工具链组件如何相互集成，以减轻已识别的风险。	示例1：定义工具链的类别，并指定每个类别要强制使用的工具或工具类型。 示例2：确定要集成到开发人员工具链中的安全工具。 示例3：定义在工具之间需要传递的信息以及要使用的数据格式。 示例4：评估工具的签名能力，以创建不可变的记录/日志，以便在工具链中进行审核。 示例5：使用自动化技术进行工具链的管理和编排。	不一一展示，需要原文件可私信我获取
	PO.3.2：遵循推荐的安全实践来部署、操作和维护工具以及工具链。	示例1：评估、选择和获取工具，并评估每个工具的安全性。 示例2：将工具与现有的其他工具以及软件开发过程与工作流集成。 示例3:将基于代码的配置用于工具链(例如，管道即代码、工具链即代码)。 示例4:实现可重复构建所需的技术和过程。 示例5：根据需要更新、升级或更换工具，以解决工具漏洞或添加新的工具功能。 示例6：持续监控工具和工具日志，实时发现潜在的操作和安全问题，包括策略违规和异常行为。 示例7：定期验证工具的完整性并检查每个工具的来源，以识别潜在问题。 示例8：关于编译器、解释器和构建工具，请参见PW.6。 示例9：关于实施和维护安全环境，请参见PO.5。
	PO.3.3：配置工具以生成支持组织定义的安全软件开发实践的Artifact。	示例1:使用现有的工具(例如，工作流跟踪、问题跟踪、价值流映射)来创建安全开发相关行为的审计跟踪，帮助组织持续改进。 示例2:确定应该多久对收集的信息进行一次审核，并实施必要的流程。 示例3:为Artifact数据建立并实施安全和保留策略。 示例4：将工具无法生成的Artifact分配下去。

实践4（组织准备）	任务	概念实现参考示例	参考
定义和使用软件安全检查标准(PO.4): 在开发期间，通过定义和使用检查软件安全性的标准，确保由SDLC产生的软件满足组织的期望。	PO.4.1:定义软件安全检查的标准，并跟踪整个SDLC。	示例1：确保标准充分表明如何有效地管理安全风险。 示例2:定义关键性能指标(KPI)、关键风险指标(kri)、漏洞严重性分数以及其他软件安全度量。 示例3：将软件安全标准添加到现有检查中（例如，敏捷SDLC方法中完成的定义）。 示例4：检查作为软件开发工作流系统的一部分而生成的Artifact，以确定它们是否满足标准。 示例5:将安全检查批准、拒绝和例外请求记录作为工作流和跟踪系统的一部分。 示例6:分析收集每个开发项目的安全成功和失败的上下文中的数据，并使用结果改进SDLC。	不一一展示，需要原文件可私信我获取
	PO.4.2：实施流程、机制等，以收集和保护支持标准的必要信息。	示例1:使用工具链自动收集信息，为安全决策提供信息。 示例2:如果需要，部署额外的工具来支持支持标准的信息的生成和收集。 示例3:利用标准自动化决策过程，并定期审查这些过程。 示例4:仅允许授权人员访问收集的信息，并防止对信息进行任何更改或删除。

实践5（组织准备）	任务	概念实现参考示例	参考
实施和维护安全的软件开发环境(PO.5): 确保软件开发环境的所有组件都受到强有力的保护，免受内部和外部威胁，以防止环境或其中正在开发或维护的软件受到损害。软件开发环境包括开发、构建、测试和分发环境。	PO.5.1:隔离和保护软件开发中涉及的每个环境。	示例1：对每个环境使用多因素、基于风险的身份验证和条件访问。 示例2:使用网络隔离和访问控制将环境彼此隔离，并与生产环境隔离，并将每个非生产环境中的组件相互隔离，以减少攻击面和攻击者的横向移动以及权限/访问升级。 示例3：强制身份验证并严格限制进入和退出每个软件开发环境的连接，包括尽量减少对互联网的访问。 示例4：尽量减少对工具链系统（如构建服务）的直接人工访问。持续监控和审核所有访问尝试和所有特权访问的使用。 示例5：尽量减少使用生产环境软件以及来自非生产环境的服务。 示例6:定期记录、监控和审核环境之间以及每个环境中的组件之间的授权和访问信任关系。 示例7:持续记录和监控开发环境所有组件的操作和警报，以检测、响应和恢复未遂和实际的网络事故。 示例8：配置隔离和保护环境所涉及的安全控制和工具，以生成其活动的Artifact。 示例9：持续监控每个环境中部署的所有软件是否存在新的漏洞，并按照基于风险的方法对漏洞做出适当响应。 示例10：配置并实施措施，以确保环境的托管基础架构遵循零信任架构。	不一一展示，需要原文件可私信我获取
	PO.5.2：保护和强化开发端点（即软件设计人员、开发人员、测试人员、构建人员等的端点），使用基于风险的方法执行开发相关任务。	示例1:根据批准的强化指南、清单等配置每个开发端点。；例如，对所有静态和传输中的敏感数据启用符合FIPS标准的加密。 示例2:配置每个开发端点和开发资源，以提供用户和服务所需的最少功能，并实施最小特权原则。 示例3：持续监控所有开发端点的安全状况，包括监控和审计所有特权访问的使用。 示例4:配置安全控制和其他涉及保护和加固开发端点的工具，为其活动生成Artifact。 示例5：要求对开发端点和开发资源的所有访问进行多因素身份验证。 示例6:在非生产网络上提供专用的开发端点，用于执行所有与开发相关的任务。在生产网络上为所有其他任务提供单独的端点。 示例7:按照零信任架构配置每个开发端点。

以上是安全软件开发框架(SSDF)1.1版本中的组织准备部分的全部内容，后面会继续为大家整理软件保护部分、可靠软件生产部分和漏洞响应部分，欢迎大家继续关注。

（谢绝转载，更多内容可查看我的主页）