第八章 现有和新兴政府指南

在本章中，我们将讨论政府和公共部门组织针对软件供应链安全的现有和新兴出版物。这些出版物建立在我们在上一章中讨论的现有商业指南的基础上，并考虑了国防部 （DoD）、美国联邦民事行政部门 （FCEB） 机构和国家安全局 （NSA） 等机构的一些独特要求。

8.1 系统和组织的网络安全供应链风险管理实践

2020年初，美国国家标准与技术研究院(NIST)首次发布了特别出版物(SP) 800-161，“系统和组织的网络安全供应链风险管理(C-SCRM)实践”。然而，与本书中讨论的许多其他资源一样，网络安全行政命令(EO) 14028保证对原始NIST C-SCRM出版物进行更新。

《网络安全行政令》第4(b)、4(c)和4(d)条特别关注软件供应链问题，因此，NIST在800-161修订版1附录F中发布了他们的回应和指南，即“对14028号行政命令关于发布增强软件供应链安全指南的呼吁的回应”。而不是将指导嵌入到更广泛的800-161文件，NIST将其作为独立资源发布在网上(www..nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/ software-security-supply-chains)。

在深入研究NIST提供的具体指导之前，我们应该回顾一下《行政令》第4节的详细内容。第4部分要求商务部长通过NIST与政府、行业和学术界合作，确定现有的或开发新的标准、工具和最佳实践，以与《行政命令》第4部分保持一致。本节包括评估开发人员和供应商的软件和安全实践的标准。

此外，这项评估的任务是在《行政令》公布后30天内进行。除此之外，在发布后的180天内，NIST主任被要求发布主要指导方针，以增强与第4节要求一致的软件供应链安全性。

在行政令发布后的一年内，NIST的主任被要求发布额外的指导方针和程序，以定期审查和维护NIST就该主题发布的指导方针。为了制作在线发布的初步指南，NIST从SP 800-161r1中提取了见解，以及在2021年6月“增强软件供应链安全研讨会”(https://csrc.nist.gov/Events/2021/enhancement-Software-Supply-Chain-Security-Workshop)工作组，当然还有NIST EO页面本身提交给NIST的各种立场文件。

NIST的800-161r1指南致力于告知各机构作为其IT计划的一部分使用的第三方软件和服务的获取、使用和维护。该指南可以集成到他们的C-SCRM计划中，并用于帮助通知采买和采购活动。它不仅可以被联邦机构实施和使用，也可以被相关的供应商用来支持他们的软件供应链实践和过程。随着这些最佳实践和需求进入联邦合同语言，并成为向美国联邦政府出售产品的软件供应商所必需的，该指南将变得相关。

NIST还提供了一个关系图来说明他们的各种出版物(如800-37r2、800-53r5)和安全软件开发框架(SSDF)之间的关系，这将在后面的“NIST的安全软件开发框架”一节中讨论。这些文档既可以用于政府购买安全软件，也可以用于行业对这些最佳实践和需求的认证。图8.1展示了各种出版物之间的关系。

关键软件

NIST对EO的关键要求之一是定义关键软件。NIST对关键软件的定义是“具有或直接依赖于具有这些属性的一个或多个组件的任何软件”。

关键软件：

任何阅读此列表的人都会很快同意，这是一套复杂的标准，会使大多数软件潜在地变得关键。出于这个原因，让我们打开前面列出的一些标准。首先，必须定义直接的软件依赖关系。NIST将直接软件依赖定义为其他软件组件，如库和包，这些组件直接集成到正在讨论的特定软件中或对其操作是必要的(www.nist .gov/itl/executive-order- improvement -nations-cybersecurity/ criticalsoftwaredefines-faqs #Ref_FAQ2)。

它们还指定不包括其他独立产品的接口或服务。关键的信任可能是另一个令人困惑的短语。NIST解释说，这是指用于网络控制端点安全和网络保护等安全功能的软件类别(www.nist.gov/itl/executive-order-improvingnations-cybersecurity/critical-software-definition-faqs#Ref_FAQ3)。

NIST强调，他们的定义适用于为生产环境购买和部署的任何形式的软件。这意味着，它不适用于用于研究和开发(R&D)用例的软件。NIST还建议，关键软件需求的实现阶段首先关注用于关键安全功能的独立本地软件，或者如果受到损害可能会造成重大潜在危害的软件，然后关注其他软件，如云、混合和源代码管理等。

NIST继续提供了他们认为关键的软件类别的初步列表，以及它们包含的基本原理。该列表包括身份、凭证和访问管理(ICAM)、操作系统、Web浏览器、端点安全、网络控制等类别。其基本原理是，如果易受攻击并被利用，它们的关键访问权限和功能可能会危及系统的安全性和完整性。

对于那些希望深入了解NIST定义的关键软件的人，请查看关键软件定义FAQ页面，该页面回答了www.nist.gov/itl/executive-order-improving-nations-cybersecurity/critical-software-Definition-faqs上的一些常见问题和关注点。

关键软件安全措施

除了定义关键软件之外，NIST还为他们称为eo关键软件的安全措施提供了指导。NIST使用了来自社区、虚拟研讨会的意见书，以及来自网络安全和基础设施安全局(CISA)和管理和预算办公室(OMB)的意见，以及其他来源，以确定适用于关键软件的安全措施。

NIST为安全措施定义的主要范围是关键软件的使用，而不是它的开发和获取。也就是说，还有其他的指导来源，比如处理软件开发的SSDF，以及800-161r1本身，它更广泛地涵盖了C-SCRM和软件的获取。NIST的关键软件安全措施的目标包括保护软件和相关平台免受未经授权的访问和使用。它还努力防止被利用，并保护软件和平台使用的数据的机密性、完整性和可用性。

NIST承认事故会发生，因此组织必须能够快速检测、响应并从事故中恢复。此外，组织必须努力改进可能影响关键软件和平台的人类行为和行为。考虑到Verizon的2022年数据泄露调查报告(DBIR)等来源，这种承认是至关重要的，该报告指出，超过60%的数据泄露涉及人为因素，但组织仅将3%的安全预算用于人为方面。

NIST的指南进一步定义了一组可用于保护关键软件的健壮的安全实践和过程。它也承认，这份清单并非详尽无遗或无所不包，随着风险形势的变化，它将随着时间的推移而增长和演变。

现在，让我们深入了解NIST的一些安全措施，看看NIST为关键软件定义了哪些基本安全措施。值得注意的是，NIST关于关键软件安全措施的讨论来自许多来源，例如其他NIST出版物，以及来自CISA、OMB、NSA等的资源。

多因素身份验证(MFA)是最早列出的建议之一。认证因素通常包括以下内容:

MFA是公共和私营部门组织经常引用的安全最佳实践。这种身份验证类型超越了用户名和密码等基本身份验证措施，它添加了身份验证因素，包括SMS文本代码、电话呼叫、通过移动设备上的身份验证应用程序进行批准，甚至还有个人身份验证(PIV)或通用访问卡(cac)等形式因素，以及YubiKeys等流行示例。(有关YubiKeys的更多信息，请访问 www.yubico.com。)根据辅助身份验证源的不同，添加这些因素会大大增加恶意行为者破坏凭据的难度。

然而，值得注意的是，即使是MFA也不是绝对可靠的，并且可能被SMS网络钓鱼等方法所破坏(https://thehackernews.com/2022/08/twilio-suffers-data-breach-after.html)。因此，NIST的指南要求MFA的使用不仅对所有管理员，而且对所有用户都是防模拟的。这有时也被称为防网络钓鱼MFA，通常身份验证方法(如密码、SMS和安全问题)不被认为是防网络钓鱼的。抵制网络钓鱼的一些核心原则是MFA包括身份验证者和用户身份之间的强绑定，消除共享秘密，并确保响应仅发送给受信任的方。

抗网络钓鱼的MFA示例包括FIDO2和PIV智能选项(www.yubico.com/resources/glossary/phishing-resistant-mfa)。 基于MFA对所有用户的建议，NIST还建议对每个服务进行唯一标识和身份验证，并遵循最小特权访问管理原则。这些控制确保了适当的访问控制，并可以限制恶意网络活动的爆炸半径。正如NIST在其800-207出版物《零信任架构》(https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800207.pdf)中所定义的那样，最少特权访问控制也是更广泛地推动零信任的基本原则。

虽然最低权限访问控制可以限制恶意活动的影响，但NIST的下一个建议也是如此，即采用边界保护，例如网络分段，并使用软件定义的边界。周界描述的工作原理是确保系统和环境的一个区域中的事件不会对整个系统甚至它所连接的外部系统产生级联影响。

为了实现第二个目标，即保护关键软件和软件平台使用的数据的机密性、完整性和可用性，NIST提供了一系列组织可以遵守的关键控制和实践，包括建立和维护数据清单。如果没有适当的数据清单，组织是不可能保护其数据的。网络安全领域有句流行的说法:“你无法捍卫你不知道存在的东西。”与前面讨论的网络级访问控制非常相似，也应该通过使用细粒度访问控制来保护组织的数据和资源。

NIST建议通过使用符合NIST加密标准的加密来保护静态数据(https://nvlpubs.nist.gov/ nistpubs/SpecialPublications/NIST. sp .800- 175br1 .pdf)。传输中的数据也是如此;NIST的建议是，在可能的情况下，不仅要使用加密，还要使用相互身份验证。

相互认证是指双方同时对彼此进行认证，并使用支持的认证协议(如IKE (Internet Key Exchange)、SSH (Secure Shell)和TLS (Transport Layer Security))进行认证。这样做可以确保数据在传输过程中被加密，以便数据不会暴露给可能访问它的未经授权的各方，以及他们可以减轻某些类型的攻击，例如路径攻击、重播和欺骗。

这些类型的攻击包括恶意行为者试图捕获传输中的数据、复制数据或模仿交换中的有效实体。为此，NIST的最后一条建议是，不仅要备份数据，还要执行备份恢复以准备好恢复数据。它承认，尽管存在诸如加密和相互身份验证之类的控制，事件仍然可能而且确实会发生，从而损害组织数据，并且当这些事件发生时，组织必须能够从有效的备份中恢复数据。

根据 NIST 的定义，关键软件安全的第三个目标是需要识别和维护关键软件平台和软件驻留在这些平台上的软件，以防止其被利用。这方面的控制措施包括建立和维护软件资产清单。软件资产软件资产清单也是互联网安全中心（Center for Internet Security (CIS) 在其 CIS 关键安全控制指南 (www.cisecurity.org/control) 中也推荐了软件资产清单）。

对软件进行清查和管理可以更好地进行软件治理和控制确保只有经过授权的软件才能被执行。控制，确保只有经过授权的软件才能在系统上安装和执行。当然，软件库存不仅仅是广义上的软件产品库存，还包括组件级库存。当然，软件库存不仅包括广义的软件产品库存，还包括组件级库存，即软件物料清单（SBOM本书中广泛讨论的软件物料清单 (SBOM)。除了软件库存之外，企业还应确保使用补丁管理最佳实践，确保识别、记录和缓解已知的漏洞，并采取以下措施在文档化的变更控制流程中进行。流程。软件平台以及更广泛的一般软件也需要配置管理最佳实践。这些最佳实践包括实施加固的安全配置和监控这些最佳实践包括实施加固的安全配置以及监控平台和软件是否存在未经授权的更改等活动。

如前所述，NIST 认识到，尽管实施了这些最佳实践和安全控制的最佳实践和安全控制措施，事件仍有可能发生。因此因此，第四个目标包括能够快速检测、响应和恢复影响关键软件的威胁和事故。因此，第四个目标包括能够快速检测、响应和恢复影响关键软件和平台的威胁和事件。

为实现所需的响应和恢复能力，组织必须正确记录任何安全事件的所有必要信息。要实施日志记录最佳实践，企业应利用 NIST 的《计算机安全日志管理指南》等指南以及针对其产品和平台的特定供应商指南 (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf)。必须持续监控关键软件，这可以结合使用端点安全保护产品或服务（通常称为端点检测和响应 (EDR) 工具）来实现。EDR 工具有助于识别、审查和最小化攻击面以及已知威胁的暴露程度，控制软件的执行内容，并在发生事故时协助恢复。

企业必须对关键软件和平台实施网络安全保护，以检测堆栈各层的威胁，帮助预防威胁，并向安全操作人员和其他应对事件的人员提供必要的遥测数据。为了有效地进行事件响应，NIST 建议根据所有安全操作和事件响应团队成员的具体角色和职责对他们进行培训最后一个目标侧重于加强对有助于关键软件和平台安全的人类行动的理解和执行，是一个以人为本的目标。该目标包括根据关键软件和平台用户的角色和职责对其进行培训等活动，其中包括那些通常拥有较高权限的管理员。最后，它建议对关键软件和平台的所有用户和管理员进行广泛的安全意识培训，并衡量培训的效果，以推动改进和取得更好的成果。

最后一个目标的重点是加强对有助于关键软件和平台安全的人类行动的理解和执行，这是一个以人为本的目标。这一目标包括根据关键软件和平台用户的角色和职责对其进行培训等活动，其中包括那些通常拥有较高权限的管理员。最后，它建议对关键软件和平台的所有用户和管理员进行广泛的安全意识培训，并衡量培训的效果，以推动改进和取得更好的成果。

8.2 软件验证

NIST 网络行政命令第 4 部分指南的另一个关键组成部分是发布指南，为供应商测试其源代码推荐最低标准。它包括手动和自动测试，例如代码审查工具、静态应用程序安全测试 (SAST)、动态应用程序安全测试 (DAST) 和渗透测试。与行政命令第 4 部分指南中的其他部分非常相似，NIST 采取了从社区收集立场文件 (www.nist.gov/itl/executive-order-improving-nations-cybersecurity/enhancing-software supply-chain-security) 和举办研讨会 (www.nist.gov/itl/executive-order-improving-nations-cybersecurity/enhancing-software-supply-chain-security) 的方法。

在深入探讨所提出的验证测试方法的细节之前，值得注意的是，NIST 指出，虽然网络 EO 使用供应商一词来表示测试，但开发人员经常从外部来源获取软件，因此，如果使用来自其他来源的软件，他们也会进行自己的验证。在已发布的指南中，NIST 推荐了 11 种类型的测试和方法以及我们将很快讨论的补充技术（https:// nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8397.pdf）。从高层次上讲，NIST 的指南讨论了确保开发的软件能够按照开发人员的意图运行，同时在整个生命周期中没有漏洞的必要性。获得这种保证涉及各种活动，例如威胁建模、自动化测试 (SAST/DAST)、动态分析、纠正不可接受的错误或发现，以及对任何相关库、包和服务使用类似的技术。虽然上一章涉及商业指导时已经涉及了许多此类活动，但 我们将从 NIST 定义的角度简要介绍这些活动，这些活动与他们的网络安全 EO 指导相关。

威胁建模

NIST 建议在 SDLC 早期使用威胁建模来识别设计级安全问题。您将获得对系统的概念理解和可视化，并开始分析潜在攻击，以及其相关目标和潜在威胁中实现的利用方法。通过威胁建模，组织正在尝试识别潜在威胁、弱点和漏洞，然后定义与这些威胁相一致的缓解计划。NIST 指出国防部 (DoD) DevSecOps 参考架构图（如图 8.2 所示）作为威胁建模如何作为系统开发和规划活动的一部分融入 DevSecOps 方法论的一个例子。
DevSecOps 不是线性活动（例如瀑布），威胁建模也不应该是线性活动。它应该作为频繁和迭代系统和软件交付的一部分来完成。

自动化测试

NIST 在其指南中明确指出，自动化测试可以像脚本一样简单，用于自动化静态分析，也可以像创建整个环境一样复杂和自动化，包括运行测试和验证测试成功。组织可以使用简单的工具来测试支持 Web 的应用程序和字段，也可以使用涉及模块和子系统的更复杂的工具。建议包括自动验证，以确保静态分析不会报告新的弱点，测试以迭代方式运行，结果准确，并且使用自动化可以减少对人工分析和工作量的需求，而人工分析和工作量既耗费资源又容易出错。使用 Git 和 CI/CD 管道等现代开发系统的组织可以使验证过程在提交和拉取请求时自动化和可重复

基于代码或静态分析和动态测试

NIST 区分了两种方法：基于代码或静态分析和基于执行的测试，它们分别提供了 SAST 和 DAST 等示例。基于代码的静态分析推理以原生格式编写的代码，而动态分析涉及基于执行的动态测试和分析，这需要程序执行。与前面提到的用于自动化测试的 DevSecOps 方法一样，NIST 建议在编写代码后立即以迭代小块的形式进行静态代码分析。这种方法比等待对最终产品执行 SAST 更有效，因为可以在 SDLC 中尽早解决缺陷和漏洞

评论硬解码密码

NIST 建议使用启发式工具查找应用程序代码中的硬编码密码。这些密码可能涉及凭证、加密密钥、API 密钥和访问令牌等。由于 API、令牌和凭证的广泛使用，这在云原生环境中尤其具有挑战性，本书的一位作者在一篇题为 "在 DevSecOps 云原生世界中保守秘密"（www.csoonline.com/article/3655688/keeping-secrets-in-a-devsecops-cloud-native-world.html）的文章中谈到了这个话题。研究表明，相当一部分数据泄露事件都与凭证泄露有关，因此企业应加强机密管理能力，以消除这些风险。

通过语言提供的检查和保护运行

在指南中，NIST 还建议使用各种编程语言（包括编译型和解释型）提供的预构建检查。NIST 还强调，有些语言不具备内存安全性，即防止程序员引入与应用程序中内存使用方式相关的特定类型的错误，并建议强制执行内存安全性。除了使用内置的强制执行功能外，企业还可以使用静态分析器或 "精简器 "等措施来查找危险的函数和参数。值得注意的是，其他指南（如上一章讨论的 OpenSSF 开源安全动员计划）也建议业界转向内存安全语言，摒弃与内存安全相关的固有风险增加的传统语言。

黑盒测试用例

与前面讨论过的测试类型不同，黑盒测试并不与特定的代码片段挂钩，而是侧重于功能需求，并验证软件不应该做什么。这些测试包括拒绝服务和输入边界等内容，在进行测试时不需要源代码分析和威胁建模所需的内部知识和假设。

历史测试案例

当 NIST 指南使用 "历史测试用例 "一词时，它指的是通常所说的回归测试。回归测试在成熟的安全团队中非常普遍，他们实施测试来验证先前发现并修复的漏洞是否存在。这种类型的测试非常重要，因为在配置和卫生偏移等情况下，不安全的配置和系统状态可能会再次出现。回归测试有助于验证情况并非如此。

模糊测试

NIST 推荐的另一种软件验证方法是模糊或模糊测试，这是一种自动测试方法，通过向软件中注入无效、畸形或意外输入来识别缺陷和漏洞。一旦这些输入被注入系统，模糊测试工具就会观察系统的反应，如死机或泄露本不应该泄露的信息。开放式全球应用安全项目（OWASP）为希望了解更多信息的用户提供了一个全面的模糊页面，网址是 https://owasp.org/www-community/Fuzzing。

网络应用扫描

网络应用扫描通常被称为动态应用安全测试（DAST）或交互式应用安全测试（IAST），适用于软件提供网络服务的情况。这两种工具执行的活动与模糊测试类似，但它们都是针对网络应用程序执行的，因为它们都在寻找异常或故障。世界上最流行的网络应用扫描工具是 OWASP Zed Attack Proxy (ZAP；(www.zaproxy.org))。

检查随附的软件组件

NIST 最后建议的开发人员测试清单最低标准是检查包含的软件组件。NIST 指出，这项活动的目标是确保所包含的代码至少与本地开发的代码一样安全。正如我们在本书中所讨论的，软件组成分析（SCA）等工具可以帮助识别软件正在使用的开放源码软件库、软件包和依赖项。这些工具可查询漏洞数据库，如 NIST 的国家漏洞数据库 (NVD)，以查找这些组件中的已知漏洞。鉴于大多数现代软件都是由开放源码软件组件组成的，因此这项工作尤为重要。 NIST 还提供了有关我们讨论的所有技术的其他背景和补充信息，如果您想了解有关此类测试技术的更多详情以及如何成功实施这些技术，这些信息值得您深入了解。

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 稳健的安全软件开发实践分为四组：

在这些实践中，有定义实践的元素，如实践、任务、名义实施示例和参考（将实践映射到任务）。如前所述，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 过程中采取适当步骤确保软件的安全。