安全软件开发框架SSDF是由美国国家标准与技术研究院发布的关于安全软件开发的一组实践，帮助开发组织减少发布的软件中的漏洞数量，减少利用未检测到或未解决的漏洞的潜在影响，从根本上解决漏洞防止再次发生。本文根据《Secure Software Development Framework (SSDF) Version 1.1:Recommendations for Mitigating the Risk of Software Vulnerabilities》文档翻译整理，本文是第五部分，主要是该框架的安全实践列表以及相应的参考中的生产安全可靠的软件（Produce Well-Secured Software ）的下半部分。
| 实践5（生产安全可靠的软件） | 任务 | 概念实现参考示例 | 参考 |
| 遵守安全编码实践创建源代码（PW.5）： 减少软件中的安全漏洞数量，并通过最大限度地减少源代码创建过程中引入的符合或超过组织定义的漏洞严重性标准的漏洞来降低成本。 | PW.5.1:遵循适合开发语言和环境的所有安全编码实践，以满足组织的要求。 | 示例1：验证所有输入，对所有输出进行验证和正确编码。 示例2:避免使用不安全的函数和调用。 示例3：检测错误，并妥善处理。 示例4：提供日志记录和跟踪功能。 示例5：使用具有自动化功能的开发环境，开发环境应该鼓励或要求使用实时的、培训到位的安全编码实践。 示例6：当自动化方法不足或不可用时，手动遵循确保遵守安全编码实践的程序。 示例7:使用工具(例如，linters、formatters)来标准化源代码的样式和格式。 示例8：检查开发语言和环境中常见的其他漏洞。 示例9：让开发人员审查自己的人类可读代码（human-readable code），以补充（非取代）其他人或工具执行的代码审查。参见PW.7。 | 不一一展示，需要原文件可私信我获取 |
| PW.5.2:移至PW.5.1作为示例 |
| 实践6（生产安全可靠的软件） | 任务 | 概念实现参考示例 | 参考 |
| 配置编译、解释器和构建过程以提高可执行文件的安全性（PW.6）： 通过在测试之前消除漏洞，减少软件中的安全漏洞数量并降低成本。 | PW.6.1:使用编译器、解释器和构建工具，些工具可以提供提高可执行文件安全性的功能。 | 示例1：使用最新版本的编译器、解释器和构建工具。 示例2：在部署或更新编译器、解释器和构建工具时，遵循更改管理流程，并审核工具的所有意外变更。 示例3：定期验证编译器、解释器和构建工具的真实性和完整性。参见PO.3。 | 不一一展示，需要原文件可私信我获取 |
| PW.6.2：确定应使用哪种编译器、解释器和构建工具功能，以及应如何配置每种功能，然后实施和使用批准的配置。 | 示例1：启用编译器功能，这些功能会在编译过程中对安全性较差的代码发出警告。 示例2：实现“干净构建”理念，将所有编译器警告视为错误并消除，被确定为误报或无关的警告除外。 示例3:在一个专用的、高度受控的构建环境中执行所有的构建。 示例4:启用使执行特征随机化或模糊化的编译器功能，例如内存位置使用，否则这些执行特征是可预测的，因此可能被利用。 示例5:进行测试以确保功能按预期运行，并且不会无意中导致任何操作问题或其他问题。 示例6：持续验证批准的配置是否正在使用。 示例7：将已批准的工具配置作为配置代码提供，以便开发人员可以方便地使用它们。 |
| 实践7（保护软件） | 任务 | 概念实现参考示例 | 参考 |
| 审查和/或分析人工可读代码（Human-Readable Code），以识别漏洞并验证是否符合安全要求（PW.7）： 帮助识别漏洞，以便在软件发布之前对其进行更正，以防止被利用。使用自动化方法可以减少检测漏洞所需的工作量和资源。人工可读代码包括源代码、脚本和组织认为人工可读的任何其他形式的代码。 | PW.7.1:根据组织的定义，确定是否应该使用代码审查(一人工直接查看代码以发现问题)和/或代码分析(使用工具来发现代码中的问题，以完全自动化的方式，或与人工审查相结合的方式)。 | 示例1：遵循组织的政策或指导方针，确定何时进行代码审查以及如何进行代码审查。这可能包括第三方代码和内部编写的可重用代码模块。 示例2:遵循组织的政策或指导方针，了解何时应该执行代码分析，以及应该如何进行。 示例3:根据软件的阶段选择代码审查和/或分析方法。 | 不一一展示，需要原文件可私信我获取 |
| PW.7.2：根据组织的安全编码标准执行代码审查和/或代码分析，并在开发团队的工作流程或问题跟踪系统中记录和分类所有发现的问题和建议的补救措施。 | 示例1：执行代码的同行评审，对所有的代码审计进行审查，并把分析或测试结果作为同行评审的一部分。 示例2：使用专家评审员检查代码中是否存在后门和其他恶意内容。 示例3：使用有助于同行评审过程的同行评审工具，并记录所有讨论和其他反馈。 示例4:使用静态分析工具自动检查代码是否存在漏洞，以及是否符合组织的安全编码标准，同时由人工检查工具报告的问题，并在必要时进行补救。 示 例5：使用审查清单来验证代码是否符合要求。 示例6:当人工可读 代码被检入代码存储库时，使用自动化的工具持续地识别和修复文档化的和验证的不安全的软件实践。 示例7：识别并记录发现问题的根本原因。 示例8：在开发人员可以访问和搜索的wiki中记录从代码审查和分析中获得的经验教训。 |
| 实践8（保护软件） | 任务 | 概念实现参考示例 | 参考 |
| 测试可执行代码以识别漏洞并验证是否符合安全要求(PW.8): 帮助识别漏洞，以便在软件发布之前对其进行更正，以防止被利用。使用自动化方法可以减少检测漏洞所需的工作量和资源，并提高可追溯性和可重复性。可执行代码包括二进制文件、直接执行的字节码和源代码，以及组织认为可执行的任何其他形式的代码。 | PW.8.1：确定是否应执行可执行代码测试，以发现先前审查、分析或测试未发现的漏洞，如果需要，应使用哪种类型的测试。 | 示例1：遵循组织的政策或指导方针，确定何时进行代码测试以及如何进行代码测试（例如，在沙盒环境中）。这可能包括第三方可执行代码和内部编写的可重复使用的可执行代码模块。 示例2:根据软件的阶段选择测试方法。 | 不一一展示，需要原文件可私信我获取 |
| PW.8.2:确定测试范围，设计测试，执行测试，并记录结果。记录和分类所有在开发团队的工作流或问题跟踪系统中发现的问题和建议的补救措施。 | 示例1:对安全功能进行健壮功能测试 示例2：将动态漏洞测试集成到项目的自动化测试套件中。 示例3：将以前报告的漏洞测试纳入项目的测试套件，以确保不会重新引入错误。 示例4：在制定测试计划时，要考虑软件在生产中使用的基础设施和技术堆栈。 示例5：使用模糊测试工具来发现输入处理的问题。 示例6:如果资源可用，使用渗透测试来模拟攻击者在高风险情况下如何试图破坏软件。 示例7：识别并记录发现问题的根本原因。 示例8:在开发人员可以访问和搜索的wiki中记录从代码测试中获得的经验教训。 示例9：在开发测试计划时使用源代码、设计记录和其他资源。 |
| 实践9（保护软件） | 任务 | 概念实现参考示例 | 参考 |
| 将软件配置为默认具有安全设置（PW.9）： 在安装时帮助提高软件的安全性，以降低软件部署时安全设置薄弱的可能性，从而避免更大的泄露风险。 | PW.9.1：通过确定如何配置对安全有影响的每个设置或与安全相关的设置来定义安全基线，以便默认设置是安全的，确保不会削弱平台、网络基础设施或服务提供的安全功能。 | 示例1：进行测试，以确保设置（包括默认设置）按预期工作，并且不会无意中导致任何安全缺陷、操作问题或其他问题。 | 不一一展示，需要原文件可私信我获取 |
| PW.9.2：实现默认设置（或默认设置组，如果适用），并为软件管理员记录每个设置。 | 示例1:验证已批准的软件配置是否到位。 示例2:记录每个设置的用途、选项、默认值、安全相关性、潜在的操作影响以及与其他设置的关系。 示例3:使用权威的、有规划的编程机制，来记录软件管理员如何实现和评估每个设置。 示例4：以可用的格式存储默认配置，并遵循更改控制要求进行修改（例如，将配置作为代码）。 |
以上是安全软件开发框架(SSDF)1.1版本中的生产安全可靠的软件部分的全部内容，后面会继续为大家整理可靠软件生产部分和漏洞响应部分，欢迎大家继续关注。
（谢绝转载，更多内容可查看我的主页）
81
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
