安全软件开发框架SSDF是由美国国家标准与技术研究院发布的关于安全软件开发的一组实践,帮助开发组织减少发布的软件中的漏洞数量,减少利用未检测到或未解决的漏洞的潜在影响,从根本上解决漏洞防止再次发生。本文根据《Secure Software Development Framework (SSDF) Version 1.1:Recommendations for Mitigating the Risk of Software Vulnerabilities》文档翻译整理,本文是第五部分,主要是该框架的安全实践列表以及相应的参考中的生产安全可靠的软件(Produce Well-Secured Software )部分。
生产安全可靠的软件部分:
实践1(生产安全可靠的软件) | 任务 | 概念实现参考示例 | 参考 |
设计软件以满足安全要求并降低安全风险(PW.1): 确定和评估软件的安全要求;确定软件在运行期间可能面临的安全风险,以及软件的设计和架构应如何减轻这些风险;针对任何放宽或放弃安全要求的情况都应该给予安全风险去分析其合理性。在软件设计过程中解决安全需求和风险是提高软件安全性的关键,也有助于提高开发效率 | PW.1.1:使用各种形式的风险建模,如威胁建模、攻击建模或攻击面映射,以帮助评估软件的安全风险。 | 示例1:培训开发团队或与风险建模专家合作,创建模型并分析如何使用基于风险的方法来传达风险,并确定如何解决风险,包括实施缓解措施。 示例2:对高风险领域进行更严格的评估,例如保护敏感数据和保护身份识别、身份验证和访问控制,包括凭据管理。 示例3:查看以前软件的漏洞报告和统计数据,为安全风险评估提供信息。 示例4:使用数据分类方法来识别和描述软件将与之交互的每种类型的数据。 | 不一一展示,需要原文件可私信我获取 |
PW.1.2:跟踪和维护软件的安全要求、风险和设计决策。 | 示例1:记录对每种风险的响应,包括如何实现缓解措施,以及安全需求的任何例外情况的批准理由是什么。为软件的安全要求添加所有可用措施。 示例2:维护设计决策、风险响应和批准的异常的记录,这些记录可用于整个软件生命周期的审计和维护目的。 示例3:定期重新评估所有已批准的安全要求例外情况,并根据需要实施更改。 | ||
PW.1.3:在适当的情况下,内置对使用标准化安全功能和服务的支持(例如,使软件能够与现有的日志管理、身份管理、访问控制和漏洞管理系统集成),而不是将安全功能和服务独立实现。[原PW.4.3] | 示例1:维护一个或多个软件库模块,以支持标准化的安全功能和服务。 示例2:确定用于支持标准化安全功能和服务的模块的安全配置,并使这些配置可用(例如,作为代码的配置),以便开发人员可以方便地使用它们。 示例3:定义要开发的软件必须支持哪些安全特性和服务的标准。 |
实践2(生产安全可靠的软件) | 任务 | 概念实现参考示例 | 参考 |
审查软件设计,验证是否符合安全要求和风险信息(PW.2): 帮助确保软件是否满足安全要求,并合理地处理已识别的风险信息。 | PW.2.1:让未参与设计的合格人员和/或工具链中实例化的自动化流程去审查软件设计,以确认并强制执行满足所有的安全要求,妥善处理已识别的风险信息。 | 示例1:审查软件设计,以确认它满足了适用的安全要求。 示例2:审查软件设计过程中创建的风险模型,以确定它们是否能够充分识别风险。 示例3:审查软件设计,以确认其能妥善解决风险模型所识别的风险。 示例4:让软件的设计者纠正故障以满足要求。 示例5:如果无法满足安全要求,则更改设计和/或风险应对策略。 示例6:记录设计评审的结果,作为artifacts (例如,在软件规范、问题跟踪系统、威胁模型中)。 | 不一一展示,需要原文件可私信我获取 |
验证第三方软件符合安全要求(PW.3):移至PW.4
实践4(生产安全可靠的软件) | 任务 | 概念实现参考示例 | 参考 |
在可行的情况下重用现有的、安全性良好的软件,而不是单纯复制功能(PW.4): 通过重用已经检查过其安全状况的软件模块和服务,降低软件开发成本,加快软件开发,并降低在软件中引入额外安全漏洞的可能性。这对于软件安全功能的实现(如加密模块和协议)尤为重要。 | PW.4.1:从商业、开源和其他第三方开发人员处获取并维护安全性良好的软件组件(如软件库、模块、中间件、框架),供组织软件使用。 | 示例1:根据第三方软件组件的预期用途对其进行审查和评估。如果一个组件将来要以不同的方式使用,请考虑到新的使用情况下再次进行审查和评估。 示例2:确定软件组件的安全配置,确保这些配置可用(例如,作为代码的配置),以便开发人员可以方便地使用这些配置。 示例3:获取每个软件组件的来源信息(例如SBOM、源组成分析、二进制软件组成分析),并分析这些信息,更好地评估组件可能引入的风险。 示例4:建立一个或多个软件库,来托管经过批准和审查的开源组件。 示例5:维护组织批准的商业软件组件和组件版本的列表及其来源数据。 示例6:指定要开发的软件中必须包含哪些组件。 示例7:实施流程,将已部署的软件组件更新为较新版本,并保留较旧版本的软件组件,直到成功完成版本的转换。 示例8:如果无法确认获取的二进制文件的完整性或来源,请在验证源代码的完整性和来源后,从源代码构建二进制文件。 | 不一一展示,需要原文件可私信我获取 |
PW.4.2:按照SDLC流程在内部创建和维护安全性良好的软件组件,以满足第三方软件组件无法满足的内部软件开发需求 | 示例1:在创建和维护组件时,遵循组织制定的安全软件开发的安全实践。 示例2:确定软件组件的安全配置,确保这些配置可用(例如,作为代码配置),以便开发人员可以轻松地使用这些配置。 示例3:为这些组件维护一个或多个软件存储库。 示例4:指定要开发的软件中必须包含哪些组件。 示例5:实施流程,将已部署的软件组件更新为较新版本,并保留较旧版本的软件组件,直到成功完成版本的转换。 | ||
PW.4.3:移至PW.1.3 | |||
PW.4.4:验证获得的商业、开源和所有其他第三方软件组件是否在其整个生命周期中都符合组织定义的要求。 | 例1:定期检查软件模块和服务中是否存在厂商尚未修复的已知漏洞。 示例2:在工具链中构建对软件组件中已知漏洞的自动检测。 示例3:使用商业服务的成熟结论来审查软件模块和服务。 示例4:确保每个软件组件仍在积极维护,且未过期;包括在正在修复的软件中发现的新漏洞。 示例5:为每个不再维护或在不久的将来不可用的软件组件确定一个行动计划。 示例6:通过数字签名或其他机制确认软件组件的完整性。 示例7:审查、分析和/或测试代码。参见PW.7和PW.8。 |
以上是安全软件开发框架(SSDF)1.1版本中的生产安全可靠的软件部分的上半部分,后面会继续为大家整理可靠软件生产部分和漏洞响应部分,欢迎大家继续关注。
(谢绝转载,更多内容可查看我的主页)