安全软件开发框架SSDF是由美国国家标准与技术研究院发布的关于安全软件开发的一组实践，帮助开发组织减少发布的软件中的漏洞数量，减少利用未检测到或未解决的漏洞的潜在影响，从根本上解决漏洞防止再次发生。本文根据《Secure Software Development Framework (SSDF) Version 1.1:Recommendations for Mitigating the Risk of Software Vulnerabilities》文档翻译整理，本文是第二部分，主要是该框架的安全实践列表以及相应的参考。
本文档对1.1版安全软件开发框架（SSDF）进行了说明，并基于已建立的安全软件开发实践文档，提供了基本、可靠和安全的推荐实践。实践分为四类：
1、组织准备（PO）：组织应确保人员、流程和技术都能在组织级别执行安全软件开发。
2、保护软件（PS）：组织应保护其软件的所有组件免受篡改和未经授权的访问。
3、生产安全可靠的软件（PW）：组织应生产安全可靠组织应该生产安全可靠的软件，尽量减少安全漏洞。
4、应对漏洞（RV）：组织应识别其软件版本中的残余漏洞，并做出适当的响应，解决这些漏洞，防止将来发生类似的漏洞。
每个实践定义都包括以下要素：
实践：实践的名称和唯一标识符，然后简要解释实践是什么以及价值
任务：执行练习可能需要的一个或多个动作
概念实现示例：可用于帮助实现任务的工具、流程或其他方法类型的一个或多个概念示例。不需要将示例进行组合，所述实例不是唯一可行的选项，某些示例可能不适用于某些组织和情况。
引用：指向一个或多个已建立的安全开发实践文档以及到特定的任务。
表1定义了实践。它们只是一个组织可能需要做的事情的子集；关于每种做法的更多信息可以在参考文献中找到。表中的实践、任务和概念实施示例的顺序与实施顺序以及实践、任务或示例的重要性无关。
该表使用了“敏感数据”、“合格人员”和“安全可靠”等术语，这些术语在本出版物中没有定义。采用SSDF的组织需要根据自己的环境和用例来定义这些术语。环境的名称也是如此，比如“开发”、“构建”、“试运行”、“集成”、“测试”、“生产”和“发布”，这些名称在不同的组织和项目中也有很大的不同。为了正确保护环境，特别是为了防止攻击者在环境间横向移动，枚举环境是非常重要的。
表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：当需要购买的第三方软件组件不符合安全要求时，要建立并遵循流程以解决风险；对所有已批准的例外需求情况的定期审查也应该这样。 |
未完，持续整理中...
（谢绝转载，更多内容可查看我的主页）
