8.3 NIST 的安全软件开发框架

正如本书的几个部分所讨论的那样，网络安全行政命令 (EO) 14028 对零信任、云计算以及软件供应链安全等领域产生了广泛影响。作为网络安全行政命令的一部分，政府必须“只购买安全开发的软件”。行政命令指示 NIST 发布指南，确定增强软件供应链安全性的做法。NIST 正是这么做的。与业界合作，NIST 发布了安全软件开发框架 (SSDF) 版本 1.1，以及其他软件供应链安全指南。本节深入讨论了 SSDF、它是什么以及它为什么重要。

SSDF 指出，很少有 SDLC 模型明确解决软件安全问题。谈到网络安全，业内许多人都熟悉的一个常用短语是“固定的，而不是固定的”。网络安全通常是数字系统开发中的事后考虑，通常在 SDLC 的后期解决，而不是更早，因为安全最佳实践和要求可以从一开始就集成到软件和系统中。值得注意的是，2022 年发布的 SSDF 1.1 版建立在 2020 年 4 月的原始 SSDF 版本之上。为了促进 SSDF 的更新，NIST 与来自公共和私营部门的参与者举行了一个研讨会，并收到了 150 多份立场文件，供 SSDF 更新考虑。

SSDF 的目标受众包括软件生产商（例如产品供应商、政府软件开发商和内部开发团队）和软件采购方或消费者。虽然 SSDF 是专门为联邦机构使用而创建的，但它包含的最佳实践和任务适用于所有行业的软件开发团队，并且可以被许多不同的组织使用。还值得注意的是，SSDF 不是规定性的，而是描述性的；它没有具体说明如何实施每项实践，而是侧重于安全软件成果，并允许组织实施实践以促进这些成果。这是合乎逻辑的，因为保护软件的方法无穷无尽，而且每个生产和使用软件的组织都有独特的人员、流程和技术。该指南还澄清，在确定使用哪些实践以及为实现上述实践而投入的资源时，应考虑组织的风险承受能力等因素。

NIST 为从生产商和供应商处采购软件或包含软件的产品的联邦机构制定了最低建议。这些建议包括几项关键条款，有助于确保政府不会采购不安全的软件和产品。在机构采购软件时，NIST 建议他们使用 SSDF 术语或有关安全软件开发要求的沟通方式。NIST 还建议供应商在整个 SDLC 期间证明 SSDF 开发实践。一个经常引起争议的话题是证明，即某事的证据或证明。通常，从流程角度来看，证明可以由亲自完成，也称为自我证明，也可以由独立的第三方（例如第三方评估组织 (3PAO)）完成。

使用 3PAO 增加了认证的保证，因为它是由理论上的第三方而不是被评估方进行的。也就是说，3PAO 合规制度在时间和成本方面也会带来额外的开销，以配合其潜在的严格性。例如，FedRAMP 是希望在联邦市场提供服务的云服务提供商 (CSP) 的授权流程，要求 CSP 接受第三方评估。然而，截至本文撰写时，尽管该计划已经存在 10 年，但只有大约 250 个 FedRAMP 授权的云服务产品。如果在 SSDF 下对软件生产商采取 3PAO 方法，它无疑会在限制获准向政府销售软件的合格供应商数量方面产生类似的影响。

然而，NIST 在其指导意见中指出，根据机构和软件消费者的风险承受能力，在某些情况下可能需要第三方认证。批评者敦促政府机构不要采取这种方法，因为这会对 SSDF 的采用产生影响，并指出了其他类似计划延迟的例子，例如国防部的网络安全成熟度模型认证 (CMMC)，该计划经历了几次挫折 (https://insidedefense.com/daily-news/delay-publicly-releasing-cmmc-process guide-attributed-potential-national-security)，其中一些与为新合规认证实施 3PAO 流程的复杂性有关

SSDF 详情

如前所述，NIST SSDF 旨在倡导使用基本的、公认的安全软件开发最佳实践。SSDF 的独特之处在于，它没有完全从零开始创建指南，而是使用了许多已知的、已实施的既定指南来源，如 Synopsys 的 "成熟度模型中的构建安全性"（BSIMM）和 OWASP 的 "软件保证成熟度模型"（SAMM）等。

SSDF 稳健的安全软件开发实践分为四组：

• 准备组织 (PO)
• 保护软件 (PS)
• 制作安全可靠的软件 (PW)
• 应对漏洞 (RV)

在这些实践中，有定义实践的元素，如实践、任务、名义实施示例和参考（将实践映射到任务）。如前所述，SSDF 的最新版本涉及《网络安全电子法令》的要求，因此还包括与《电子法令》第 4e 条具体要求的映射。使用 SSDF 实践的预期目标是减少软件发布中包含的漏洞数量，以及这些漏洞在未被发现或未被处理的情况下被利用的影响。

准备组织 (PO)

对于任何希望开发安全软件的组织来说，为安全软件开发做好准备是合乎逻辑的第一步。这组实践包括定义软件开发的安全要求，其中包括对组织软件开发基础架构的要求以及组织开发的软件必须满足的安全要求。当然，这些要求也必须传达给所有向组织提供商业软件组件以供重用的第三方。

定义角色和职责是组织必须采取的另一个基本步骤。它包括 SDLC 所有环节的角色，并为担任这些角色的人员提供适当的培训。指南强调，需要获得上层管理人员或授权官员对安全开发的承诺，并确保参与流程的个人了解这一承诺。这通常被称为 "行政买入"。

现代软件交付涉及到支持工具链，这些工具链利用自动化最大程度地减少了与软件开发相关的人力，并带来了更加一致、准确和可重现的结果。这方面的任务包括指定必须用于降低风险的工具和工具类型，以及它们如何相互集成。各组织还应定义使用工具链的推荐安全实践，并确保正确配置工具以支持安全软件开发实践。

各组织还应定义和使用软件安全检查标准。这包括实施流程和工具，在整个 SDLC 过程中保护信息安全。工具链可用于自动为安全决策提供信息，并生成有关漏洞管理的指标。

最后，组织应为软件开发提供安全的环境。这通常表现为创建不同的环境，如开发、测试、暂存和生产环境。这些环境被分割开来，以限制危害影响其他环境的爆炸半径，并根据不同的环境满足不同的安全要求，同时改进配置管理，控制配置漂移，即实际配置与期望配置不一致的情况。

可以通过 MFA、有条件访问控制或最小许可访问控制等方法来保护这些环境，并确保记录和监控各种开发环境中的所有活动，以便更好地检测、响应和恢复。确保环境安全还意味着对开发人员和其他与环境交互的人员所使用的端点进行加固，以确保它们不会带来风险。您会发现，这些建议与当前的零信任指导和最佳实践有几处相似之处。

保护软件 (PS)

在保护组织的基础上，还要保护软件（PS）本身。这一组的做法包括保护代码免遭未经授权的更改、验证代码的完整性以及保护每个软件版本。

保护所有形式的代码免遭未经授权的更改和篡改，对于确保代码不会被有意或无意地修改而损害其完整性至关重要。代码应根据其安全要求，采用符合最小许可访问控制的方法进行存储，这与开放源码软件代码或专有代码不同。企业可以采取一些措施，如使用支持版本控制和提交签名的代码库，并由代码所有者和维护者进行审查，以防止未经授权的更改和篡改。还可以使用加密哈希值等方法对代码进行签名，以确保其完整性。

不仅需要维护代码的完整性，还必须为软件消费者提供验证这种完整性的方法。这就是在安全良好的网站上发布哈希值等做法的作用所在。代码签名应得到可信证书颁发机构的支持，软件用户可将其作为签名的保证或信任措施。

最后，每个软件版本都应得到保护和保存。它还有助于回滚软件和应用程序（在版本被破坏的情况下）并恢复到 "已知良好 "状态。保护和保存软件版本可以让消费者了解代码的出处以及代码出处的相关完整性。

制作安全可靠的软件 (PW)

既然需求已经编纂，开发环境和访问这些环境的端点已经解决，组织就可以专注于生产安全可靠的软件。这并不是说这些实践不会在组织或项目的整个生命周期中同时进行，但它们确实是相互依存的，同时也需要在必要时重新审视和修订。

您会注意到，在 SSDF 的 PO 部分，已定义并记录了安全要求。现在，软件的设计必须满足这些安全要求。这时，组织可以使用威胁建模和攻击面映射等风险建模方法来评估所开发软件的安全风险。企业可以对开发团队进行威胁建模等方法的培训，以提高开发团队的能力，使其能够了解所开发系统和软件面临的威胁以及降低这些风险的措施。通过使用数据分类方法，企业可以优先对高敏感性和高风险领域进行更严格的评估，以降低风险并采取补救措施。组织还应定期审查软件设计，确保其符合组织定义的安全和合规要求。这不仅包括内部开发的软件，还包括从第三方采购或使用的软件。根据所使用软件的性质，组织或许可以与软件设计者合作，纠正不符合安全要求的情况，但这不适用于开放源码软件等情况，因为这些软件没有合同或相关协议（如服务水平协议）。

我们鼓励各组织重复使用现有的、安全可靠的软件，而不是重复功能。这种重复使用有很多好处，如降低开发成本、加快能力交付、减少在环境中引入新漏洞的可能性。大型企业组织普遍存在代码蔓延的问题，即代码无节制地增长，尤其是在 "代码化 "时代，云原生环境中的基础设施甚至安全都可以定义为代码。这种 "作为代码 "的方法支持模块化、重用、配置即代码、加固代码模板和清单等概念，这些概念可以安全地用于组织内的其他地方，甚至更多地方。尽管如此，正如第 6 章 "云和容器化 "中讨论的 Palo Alto Unit 42 研究中提到的，如果这些清单和代码模板包含漏洞，它们现在也会被大规模复制，因此需要适当的治理和严格的安全性。

重用现有软件和代码的组织，甚至是组织内的团队，应确保审查和评估代码的安全性和错误配置问题，并了解与重用代码相关的出处信息。SSDF 提出的一项类似建议是，在内部创建并维护安全性能良好的软件组件和存储库，以供开发人员重复使用，这与 NIST 800-161r1 提出的建议如出一辙。

组织创建的源代码应符合组织采用的安全编码实践和行业指导所倡导的安全编码实践。这些实践包括验证所有输入、避免不安全的函数和调用，以及使用工具识别代码中的漏洞等步骤。

应对漏洞 (RV)

虽然企业可能已经定义了安全要求，准备好了环境，甚至努力制作安全软件，但漏洞还是不可避免地会出现。现实情况是，在开发过程中识别所有漏洞是根本不可能的，而且随着时间的推移，漏洞还会被发现。正如我们所讨论的，软件存在的时间越长，漏洞就越有可能被研究人员、恶意行为者和/或其他人发现。

各组织应不断努力识别和确认漏洞。这包括监控漏洞数据库、使用威胁情报馈送，以及自动审查所有软件组件以识别任何新漏洞。这些做法非常关键，因为在最初扫描和检查代码时，难免会出现新的漏洞。企业还应制定以漏洞披露和修复为中心的政策，并如前所述，定义必要的角色和责任，以便在漏洞出现时加以解决。关于漏洞披露，团队通常会努力建立产品安全事故响应团队（PSIRT），我们将在第 10 章 "供应商实用指南 "中对此进行深入讨论。

组织不仅需要识别和确认漏洞的方法，还需要根据漏洞带来的风险进行补救。这意味着要有一套评估、优先处理和修复软件漏洞的流程。利用工具和管理，企业就可以在了解风险的情况下做出决策，如补救、接受，在某些情况下还可以转移风险。生产软件的组织还需要有既定的方法来开发并向软件消费者发布安全公告，帮助他们了解软件的漏洞和对消费者的潜在影响，以及在可能的情况下解决漏洞所需的步骤。

最后，组织应采取措施，通过分析找出漏洞的根本原因，这有助于通过解决根本原因，而不仅仅是单个漏洞，来减少今后出现漏洞的频率。

从所讨论的大量安全软件开发任务和实践中可以看出，任何具有相当规模的组织都不可能总是有能力正确地完成所有这些实践。尽管如此，企业仍可采取措施，将 SSDF 作为指南，编纂其安全软件开发实践，并帮助确保在整个 SDLC 过程中采取适当步骤确保软件的安全。