第 5 章：保护应用程序和软件供应链

在本书中，我们一路探索了从软件配置管理 (SCM) 到持续集成和持续交付的交付过程，并在此过程中探讨了安全工具和实践。我们讨论了现代工具中基于角色的访问控制 (RBAC) 和策略即代码 (PaC) 治理如何帮助保护您的代码仓库和管道，并提到了早期安全测试在持续集成中的作用。我们还研究了动态测试以发现应用程序中的运行时漏洞。这些都只是对安全的浅尝辄止。

在本章中，我们将把安全放在首要位置，在一个网络攻击日益频繁和复杂的世界中，给予它应有的关注。备受瞩目的数据泄露事件屡见报端，全球范围内的法规日益收紧，客户也越来越多地根据供应商的安全态势来评估他们。

随着发布周期从数月缩短到数天，传统的将安全作为生产前最后一道关卡的模式已难以为继。取而代之的是，我们已将安全责任“左移”至开发人员，他们现在必须将安全实践整合到日常工作流程中。那些并非安全专家的开发人员如今承担着前所未有的安全责任。

人工智能有望缓解这种紧张局面。AI 驱动的安全工具正在提高检测准确性，大幅减少浪费开发人员时间的误报，甚至能自动生成修复代码。AI 不仅仅是将安全负担左移，它还帮助分担了这一负担，为开发人员提供了专家级的安全指导，而无需他们自己成为安全专家。

本章将探讨人工智能原生软件交付的演进如何改变我们处理安全问题的方式——它不仅仅是增加更多的工具或流程，而是从根本上改变了我们识别、优先处理和修复安全问题的方式。我们将深入探讨软件供应链安全的重要性，它保护了从初始代码到最终产品中软件构建和交付所涉及的工具、流程和人员。这是一个关键问题，因为现代软件严重依赖于相互连接的组件，每个组件都可能存在被恶意行为者利用的潜在漏洞。

理解供应链问题并学会以安全视角评估您的软件开发生命周期 (SDLC) 将使您能够实施强大的安全措施，更好地保护您的应用程序、数据和组织的声誉。

现代应用程序与网络威胁态势

构建和部署现代软件应用程序严重依赖于分布式且复杂的软件供应链。这些供应链通常包含庞大的代码仓库网络、开源依赖项、第三方组件、制品仓库以及 CI/CD 管道。尽管这种相互连接性促进了创新并加速了我们的开发周期，但它也贯穿始终地引入了安全风险。不断扩大的攻击面以及漏洞在整个供应链中传播的可能性，使得我们的软件供应链成为恶意行为者的主要目标。

在本节中，我们将探讨这些威胁，并了解管理软件供应链的监管合规框架如何演变以应对这些威胁。最后，我们将审视新的合规要求如何影响您的组织。

日益增长的软件供应链攻击威胁

软件供应链涵盖了所有参与创建和交付软件的人员、流程和工具。它跨越软件开发的整个生命周期，从最初的代码创建到部署和维护。这是一个复杂的生态系统，其中每个要素都在最终产品中发挥着关键作用。

软件供应链主要由两个部分组成：应用程序和 DevOps 工具链，如 图 5-1 所示。

软件供应链中的应用程序风险

此处的“应用程序”指的是您软件的所有组成部分，包括您的专有源代码；像库、框架和模块这样的开源依赖项；以及在开发过程中产生的软件制品。

根据 Synopsys 发布的《2024 年开源安全与风险分析报告》，96% 的代码库包含开源组件。重要的是要记住，我们的组织有责任保护我们使用的开源组件，就像保护内部开发的代码一样。由于开源使用如此广泛，我们不应惊讶于应用程序中发现的漏洞有 80% 以上来自开源软件 (OSS) 依赖项。2021 年在广泛使用的 Java 日志库 Log4j 中发现的一个漏洞就是开源引入威胁的一个例子。该漏洞允许攻击者通过简单地向应用程序日志发送一个特殊构造的字符串，从而在受影响的系统上远程执行代码。由于 Log4j 在应用程序和服务中的广泛使用，该漏洞利用极其危险，导致了大规模的抢修和缓解工作。

在广泛使用的 XZ Utils 数据压缩工具中发现后门是另一个例子。XZ Utils 与许多开源项目一样，由资源有限的志愿者维护，难以解决安全问题。一名受信任的贡献者被发现植入了一个后门，该后门允许攻击者获取运行使用该工具构建的软件系统的管理员权限。该工具存在于大多数 Linux 发行版中，幸运的是在广泛部署到生产系统之前被发现。

应用程序供应链中的另一个新兴威胁是利用人工智能编码助手“幻觉”现象。当 AI 模型虚构包名，推荐不存在的库或错误的包标识符时，它们就为攻击者创造了机会。恶意行为者可以监控流行的 AI 编码助手，寻找此类“幻觉”，然后将这些虚构的包名注册到公共仓库中。当开发人员试图使用这些不存在但 AI 推荐的包时，他们会在不知不觉中安装恶意代码。这种“幻觉抢注”攻击向量已在野外被观察到，研究人员发现常见的编码助手经常推荐不存在的包。

软件供应链中的 DevOps 风险

DevOps 工具链包括用于自动化软件构建、测试和部署的工具和流程集合。这涵盖了代码仓库、CI/CD 工具和管道、制品注册表以及其他简化开发过程的工具，例如 GitOps 和 IaCM 工具。

SolarWinds 攻击事件是 DevOps 工具链被攻陷后如何被利用来传播恶意代码的一个鲜明例子。在这起复杂的攻击中，威胁行为者渗透了 SolarWinds Orion 软件构建系统，将恶意代码注入合法的软件更新中。这些被污染的更新随后分发给了一万八千名 SolarWinds 客户，使得攻击者能够广泛访问他们的网络。此事件凸显了攻击者利用 DevOps 管道固有的信任和自动化功能来大规模分发恶意软件的潜力，将一次例行的软件更新变成了毁灭性的网络攻击。

2021 年的 Codecov 供应链攻击是另一起工具链安全漏洞事件，影响了数千个组织。恶意行为者修改了 Codecov Bash Uploader 脚本（客户用于上传代码覆盖率数据的工具）。这一修改使得攻击者能够从 Codecov 客户的持续集成环境中窃取敏感信息，例如令牌、密钥和凭据。该漏洞在两个多月内未被发现，可能暴露了客户持续集成环境中存储的敏感数据。

日益增长的威胁

软件供应链攻击不会消失。Gartner 研究报告预测，到 2025 年，全球 45% 的组织将经历软件供应链攻击。代码中的安全缺陷、第三方库或您管道中的某个工具都可能产生连锁反应，从而危及整个软件产品。保护软件供应链不仅是为了保护单个组件，更是为了确保整个开发和交付过程的完整性和安全性。

适用于软件供应链的监管合规框架

鉴于日益增长的威胁，各国政府和监管机构已通过制定法规来应对这些挑战，旨在建立最佳实践、促进透明度，并要求组织采取主动措施来保护其软件供应链。其中一些最重要的合规和监管框架包括：

美国第 14028 号行政命令：《改善国家网络安全》

该行政命令于 2021 年发布，要求联邦机构及其软件供应商加强其软件供应链安全实践。它强调使用安全的软件开发实践、漏洞披露和事件响应。

欧盟《网络和信息安全指令 2》（NIS2 指令） 该指令旨在欧盟范围内建立高水平的通用网络安全标准。它包含了关于软件供应链安全的条款，要求组织评估和管理与软件组件及第三方依赖项相关的风险。

NIST SP 800-218：《安全软件开发框架》(SSDF)

这份美国国家标准与技术研究院的出版物为将安全集成到软件开发生命周期 (SDLC) 中提供了指导，包括供应链风险管理。它提供了一个全面的安全软件开发实践框架。

ISO/IEC 27036-2:2023

该标准提供了管理与供应商和供应链相关的信息安全风险的指南。它涵盖了供应商选择、合同管理和绩效监控等多个方面。

支付卡行业数据安全标准 (PCI DSS)

尽管 PCI DSS 不完全专注于软件供应链，但它要求处理支付卡数据的组织实施安全的软件开发实践，其中包括管理供应链风险。

网络韧性法案 (CRA)

这项拟议中的欧盟法规旨在增强数字产品和服务的网络安全。它包括了对漏洞处理、安全更新、软件物料清单 (SBOM) 以及在发现漏洞后 24 小时内报告已活跃利用漏洞的要求。

此外，质量体系法规 (QSR) (21 CFR Part 820) 和通用数据保护条例 (GDPR) 是间接影响软件供应链问题的软件实践监管框架。QSR 强制要求严格的控制和流程，以确保医疗设备的安全性和有效性，其中包括软件组件。这要求制造商对集成到其设备中的软件进行验证和控制。同样，GDPR 对个人数据保护的严格要求，使得组织必须实施强大的技术和组织措施，这可能扩展到软件及其供应链的安全，特别是当它处理个人数据时。

这些框架和法规有助于构建一个更安全、更具韧性的软件生态系统，使企业和消费者都受益。然而，日益增加的复杂性可能会影响开发团队。理解这些要求并将其整合到您的流程中对于成功合规至关重要。

通过左移保护现代应用程序

面对动机强烈的黑客，我们传统的"等到最后"的安全方法已远远不够。这些措施不仅无法提供我们所需的保护，而且传统的安全测试还会减缓软件交付速度。为了保护现代应用程序，组织必须使用专为现代 DevOps 工作流设计的工具和实践。在本节中，我们将探讨组织在实施安全实践时面临的挑战。在 第 3 章 中，我们简要提到了左移安全，即在开发的最早阶段实施安全实践。我们将探讨如何利用这种方法来缓解风险，以及实施左移安全和以开发人员友好的方式管理漏洞的最佳实践。

对开发人员友好的左移安全的需求

您必须在软件开发周期的每个可能阶段积极处理和测试安全问题，而不是等到最后才测试应用程序的安全性。这种方法不仅通过避免后期对软件代码进行大量返工来节省时间和精力，而且还提高了最终产品的整体安全性和效率。图 5-2 对比了左移安全方法与传统应用程序安全方法。

重要的是要指出，有效的左移安全不仅仅是在交付过程的早期执行安全测试。虽然这可能有助于开发人员避免在数天或数周后返回代码时产生的上下文切换成本，但它最终并未节省工作量。真正有效的实施需要选择能够与您的 CI/CD 管道无缝集成的安全工具。这些工具不仅应识别漏洞，还应根据严重程度对其进行优先级排序，并提供可操作的见解。您选择的工具应标准化并去除重复的发现，以帮助开发人员避免警报疲劳，并专注于最关键的风险。这种集成方法确保安全在开发过程中处于绝对核心地位。

应用程序安全扫描器

有许多可用的扫描器和工具用于安全测试和分析，其中许多现在都增强了 AI 能力。让我们来看看这些扫描器和工具最常见的类别：

软件成分分析 (SCA)

这种类型的扫描器通过分析软件物料清单 (SBOM) 来识别第三方组件和依赖项中的漏洞，以检测库和框架中的已知漏洞。我们将在本章后面探讨 SBOM。SCA 工具在漏洞可被利用或被利用的可能性方面具有显著的机器学习能力。Snyk 是 SCA 扫描器的一个流行示例。

静态应用程序安全测试 (SAST)

SAST 工具通过扫描代码中指示漏洞的模式（例如 SQL 注入、XSS 和缓冲区溢出）来分析源代码中的潜在漏洞，而无需执行应用程序。AI 正在增强 SAST，以减少误报的发生，从而节省工程师的时间。SonarQube、Checkmarx 和 Fortify 都是 SAST 工具的例子。

容器扫描

这种类型的扫描通过分析容器镜像的内容来识别容器镜像及其依赖项中的漏洞和配置错误。

秘密检测扫描

这种类型的扫描检测代码仓库和配置文件中的敏感信息，例如 API 密钥、密码和令牌。借助 AI，秘密检测工具在检测混淆的秘密以及区分实际凭据和测试数据方面表现更佳，从而减少了误报和相关的手动工作。

动态应用程序安全测试 (DAST)

这种测试方法通过模拟外部攻击来分析运行中的应用程序以识别漏洞。它像真实用户一样与应用程序交互，检测注入缺陷、认证问题和配置错误等问题，而无需访问源代码。AI 增强的 DAST 工具根据应用程序行为而非固定模式生成测试用例。它们试图自动验证其发现，以解决误报问题。

基础设施即代码 (IaC) 扫描

这种类型的扫描分析 IaC 文件，以在部署前识别安全漏洞、错误配置和合规性问题。

这些类型的扫描器与左移方法一致，被集成到软件开发管道的早期阶段。秘密扫描是一种推荐的安全实践，它自动识别并提醒用户代码仓库和其他数据源中的敏感信息。

这从一开始就防止了敏感信息被纳入代码库。SCA 工具也通常在代码提交后、构建之前，被集成到管道的早期阶段。SAST 扫描可以是构建阶段的一部分。容器扫描通常在容器镜像构建之后、部署之前集成。

通过在您的开发管道中整合 SCA、SAST、容器扫描、秘密扫描、DAST 和 IaC 扫描，您可以有效地实施左移安全，并主动保护您的应用程序免受漏洞侵害。

您的测试工具识别出的每一个问题都必须进行分类。审查问题、判断其是否真实，然后进行修复，这都会产生代价。误报，即被报告但并非真实存在的问题，是一个严重的问题。它们浪费了审查人员的时间，耗费了其他安全工作和创新的资源。此外，它们通过“狼来了”效应降低了工程师对安全发现的信任，并可能减缓对其他真实问题的响应时间。有鉴于此，在许多扫描工具中，减少误报数量成为 AI 的一个关键优先事项也就不足为奇了。

分类问题因涉及的扫描器数量众多而加剧，这些扫描器可能以不同的方式发现相同的问题。在某些组织中，甚至可能在相同的代码库上使用多个 SAST 工具。在这种环境中，可以使用安全测试编排层来去除重复项并将发现结果规范化为一个单一的、可管理的列表。在 AI 原生环境中，AI/ML 在模式匹配以及减少开发人员繁重工作方面发挥着作用。

所有这些类型的扫描器都将检测到问题，并且需要进行修复。安全工具正越来越多地通过专业的 AI 编码助手提供自动化或半自动化的修复功能，从而为开发人员简化这一过程。

保护软件供应链

在本节中，我们将探讨当今软件供应链固有的常见安全风险。我们将审视与代码仓库、CI/CD 管道、制品仓库、开源依赖项以及支撑您软件开发过程的基础设施相关的风险。人工智能正在通过识别复杂供应链中手动大规模监控不可能发现的模式和异常，从而改变组织检测和响应这些风险的方式。我们将探讨可用于评估您的工具链安全性的各种框架和基准。在本节结束时，您将对潜在威胁以及如何缓解这些威胁有更深入的了解。

现代软件供应链的复杂性为人工智能创造了一个理想的用例。AI 系统可以持续监控跨仓库、构建系统和部署的异常模式。例如，机器学习模型可以检测可能表明开发人员帐户被入侵的异常提交模式，识别表明潜在供应链攻击的可疑包行为，或者发现可能导致安全漏洞的配置漂移。这些 AI 能力在相互连接的组件之间提供了前所未有的可见性和保护。

识别 CI/CD 的十大安全风险

开放全球应用程序安全项目 (OWASP) 是一个致力于提升软件安全的领先组织，它已识别出 CI/CD 的十大安全风险。如下列表所示，威胁范围多样。理解这些风险并实施推荐的缓解策略将有助于您保护和加强您的 CI/CD 生态系统：

不充分的流量控制机制

CI/CD 管道中不充分的流量控制机制可能会被获得管道访问权限的攻击者利用。通过绕过必要的审查和批准，恶意代码或制品可能会被推送到管道中，从而可能到达生产环境，造成严重后果。

身份和访问管理不足

在各种系统中管理众多身份的复杂性，加上账户权限过度宽松的趋势，可能导致泄露。如果任何用户账户被攻陷，攻击者可能会获得广泛的访问权限，甚至可能到达生产环境。

依赖链滥用

依赖链滥用是指利用您的开发和构建系统获取代码依赖项的方式中的漏洞。当这些系统被欺骗性地获取并执行恶意软件包而不是合法软件包时，就可能发生这种情况。攻击者通过发布与内部软件包同名的恶意软件包（依赖混淆）、劫持维护者账户（依赖劫持）或利用拼写错误（错字抢注）来欺骗开发人员下载他们的软件包，从而进行利用。

投毒管道执行

这是一种网络攻击，恶意代码被注入到 CI/CD 管道中，通常通过被攻陷的源代码控制系统。受污染的代码随后可以在管道内执行，可能赋予攻击者与构建作业相同的访问权限和特权。攻击者可以操纵构建配置文件或管道依赖的其他文件，导致凭据窃取、数据泄露或恶意制品部署等行为。

基于管道的访问控制不足

当管道执行节点对资源和系统拥有过度访问权限时，就会产生风险。攻击者可以利用这一点在管道内运行恶意代码，滥用授予管道的权限，在 CI/CD 系统内部或外部横向移动。

凭证管理不当

在凭据广泛用于不同系统和上下文的环境中，凭据管理不当是一个重大风险。例如，意外推送包含凭据的代码、在构建和部署过程中不安全地使用凭据、未轮换的凭据，以及凭据被打印到控制台输出或存储在容器镜像中。

不安全的系统配置

不安全的系统配置是常见的漏洞，原因在于典型工具链中存在众多系统和供应商。诸如过时软件、过度宽松的访问控制或不安全默认设置等错误配置，很容易被攻击者利用，从而获得未经授权的访问、操纵 CI/CD 流程，甚至危及生产环境。

未经治理的第三方服务使用

CI/CD 管道中的第三方服务虽然方便且对开发有价值，但很容易被授予对敏感资源的过度访问权限，从而有效扩大了组织的安全攻击面。这种治理和可见性的缺失使得难以维持适当的访问控制，一旦这些第三方服务中的任何一个遭到入侵，组织就容易受到攻击。

制品完整性验证不当

由于软件交付涉及多个阶段和来源，恶意行为者可能会在不发出警报的情况下篡改制品。如果未能检测到，这些受损制品可能会流经管道并最终部署到生产环境中，执行恶意代码并危及系统。

日志记录和可见性不足

如果没有健全的日志记录，您将对开发管道中发生的恶意活动视而不见，从而难以及时检测和响应攻击。

理解这些风险并实施推荐的缓解策略是构建安全且具有弹性的 CI/CD 生态系统的关键。

识别十大开源软件 (OSS) 风险

OSS 依赖项的使用无处不在，因此组织必须应对其带来的安全和合规风险。我们之前提到了两个例子。第一个是 Log4j 威胁，导致数千个系统受到影响。第二个是 XZ Utils 的例子，虽然发现得早，但它说明了恶意行为者如何通过入侵 OSS 组件来造成严重破坏。

常见漏洞和披露 (CVE) 是组织可用来识别已知安全问题并采取措施缓解这些问题的机制之一。CVE 监控工具可自动扫描您的软件并提醒您潜在风险。虽然勤奋的监控可以帮助您消除所用 OSS 中的已知威胁，但这并不能保证您的 OSS 组件是真正安全的。未维护的组件或过时的依赖项也会带来风险，而且由于 OSS 包会引入数十个依赖项，因此管理起来可能非常复杂。

尽管 CVE 管理有助于应对已知威胁，但还有其他类别的威胁需要应对。OWASP 基金会创建了以下十大列表，以更全面地涵盖您的组织需要防范的 OSS 风险：

已知漏洞

开源组件可能包含公开披露的安全缺陷，通常通过 CVE 或其他渠道。这些漏洞如果能在您的软件中被利用，可能会损害您系统的机密性、完整性或可用性。

合法软件包被入侵

攻击者可能通过劫持账户或利用漏洞，将恶意代码注入到现有项目或分发基础设施中。这可能导致在最终用户或组织系统上执行代码，从而危及机密性、完整性、和可用性。

名称混淆攻击

名称混淆攻击涉及恶意行为者创建与合法组件名称高度相似的组件，旨在欺骗用户安装它们。这些攻击可能导致在用户和组织系统上执行有害代码，从而损害机密性、完整性和可用性。

未维护的软件

由于未维护的 OSS 组件不再积极开发或支持，新漏洞的补丁可能不可用。这种情况可能导致需要自行创建补丁的下游开发人员的工作量增加和解决时间延长。

过时软件

在您的项目中使用过时的软件组件会带来重大挑战。这会使紧急更新变得困难，特别是当您使用的版本中发现漏洞时。旧版本在安全问题方面的测试可能也不如新版本彻底。

未跟踪的依赖项

未跟踪的依赖项可能会在开发人员不知情的情况下引入漏洞。这些依赖项可能由于 SBOM 不完整、SCA 工具功能有限或手动安装方法而被遗漏。

许可风险

开源组件的许可可能与预期用途不兼容、违反法律要求或完全没有许可。在没有许可的情况下使用组件或未能遵守许可条款可能导致法律后果。

不成熟的软件

不成熟的开源项目，缺乏标准版本控制、测试或文档等最佳实践，可能会给您的软件带来操作风险。这种不成熟可能导致意外行为和开发工作量增加，同时伴随漏洞。

未经批准的变更

未经批准的软件组件更改可能导致软件构建的完整性和可重现性受到损害。

过小/过大的依赖项

开源组件在大小和功能上可能差异很大，从而带来安全风险。小型组件提供的功能最少，但由于它们依赖于上游项目，仍然可能引入重大风险。大型组件虽然可能提供更多功能，但由于未使用功能和依赖项，其攻击面可能更大。

在下一节中，我们将探讨一个可以帮助应对这些风险的框架——SLSA。

通过软件制品供应链级别 (SLSA) 确保完整性

显然，开源软件 (OSS) 的风险众多。在我们自己的软件中利用 OSS 或任何第三方组件之前，我们必须问：这个软件是谁编写的？它是否是使用我们可以信任的工具和平台构建和发布的？它带来了哪些依赖项？它是否符合对我们重要的监管要求？

软件制品供应链级别 (SLSA，发音为“salsa”) 是一个框架，它提供了一种结构化的方法来回答这些问题。SLSA 旨在增强软件制品在整个软件供应链中的完整性。它增强了软件供应链的安全性，并有助于解决我们已讨论过的 OSS 威胁。

类似于实物证据的保管链，SLSA 强调了在软件制品整个生命周期中跟踪和验证其完整性的重要性。在本节中，我们将深入探讨 SLSA，并提供如何遵守其要求以保护您的软件免受潜在威胁的指导。

SLSA 概述

SLSA 是由开源安全基金会推动的一个开源项目。凭借其对实际实施和可衡量安全改进的关注，SLSA 获得了显著的关注。

SLSA 为 OSS 和供应商提供的软件的提供商和消费者带来了益处。在您的组织内部，您可以使用 SLSA 来帮助保护您的软件开发过程免受内部篡改。这确保您部署到生产环境的代码是您已构建、测试并批准的代码。

对于软件消费者而言，SLSA 提供了验证 OSS 真伪和完整性的机制。包注册表能够使用 SLSA 来保证上传的 OSS 包是基于合法仓库中的源代码构建的。作为 OSS 消费者，从受信任的注册表获取资源可确保您下载的包是有效的。此外，您可以要求您的供应商遵循 SLSA 原则。

验证信誉良好的第三方审计机构的供应商 SLSA 认证可以提供额外的信心。

SLSA 定义了一个分层框架，允许组织逐步增强其软件供应链的安全性。级别代表了对篡改的日益增强的保证和保护。一个没有采取任何保护措施的组织被视为处于 0 级。

SLSA 1 级是基础。1 级要求生成基本的溯源信息。此信息应详细说明构建过程、描述依赖项并提供源代码位置。1 级是组织开始其软件供应链安全之旅的起点。消费者可以使用此信息来决定与软件相关的风险。

2 级在 1 级的基础上，引入了更强的构建要求。您的构建环境必须是隔离且受控的。该级别还强制要求对制品进行签名以进行完整性验证，从而防止篡改。

最后，3 级要求源代码溯源和构建可重现性。溯源必须可审计，并且其完整性必须得到保证。

表 5-1 总结了 SLSA 1.0 定义的三个级别的要求。

使用 SLSA 确保完整性

以下原则指导了 SLSA 框架的设计决策：

信任少数平台；聚焦于制品

将信任延伸到少数核心平台，例如构建和打包工具，然后自动化验证这些平台生成的制品。例如，您受信任的构建平台为其构建的每个制品生成并签署溯源证明。下游平台随后验证由公钥签署的溯源，以自动确定制品是否符合 SLSA 级别。

将软件追溯到源代码，而非个人

在最终软件制品与其原始源代码之间建立直接且可验证的链接。这种方法与信任对包注册表具有写入权限的个人以及信任代码本身不可变和可分析的性质形成对比。通过建立直接链接，组织可以显著降低恶意代码注入或未经授权修改的风险。

偏好证明而非推断

依赖制品来源的直接证据，而不是基于对中间构建系统或其他系统的了解来推断制品的信任度。SLSA 并非推断完整性，而是要求明确证明制品的来源。这需要制品构建过程的具体证据。

在 SLSA 1.0 中，构建平台是确保制品完整性的核心。构建平台是指负责编译、打包和准备软件以供分发的系统。一个健壮的构建平台对于实现更高的 SLSA 级别至关重要。您选择的系统应支持隔离构建，这意味着每次构建都会创建新的基础设施，并且在构建运行后，基础设施会被删除。此外，系统应强制执行非特权、容器化的持续集成步骤，这些步骤不使用卷挂载。这可以防止在符合 SLSA 规范的情况下访问溯源密钥信息。通过一个强化的构建系统，您可以确保恶意行为者无法篡改您的构建。

除了选择一个能够保证制品完整性的构建平台之外，您的系统还应生成和分发证明（数字签名记录），以表明您的软件符合您所需的 SLSA 构建级别。SLSA 溯源证明是加密签名，提供关于软件制品来源和构建过程的可验证证据。它们充当数字护照，确保制品的完整性和真实性。

考虑一个使用 CI/CD 管道构建的容器镜像。该镜像的 SLSA 溯源证明可能包括以下信息：

构建者

用于构建镜像的 CI/CD 平台（例如，GitHub Actions、GitLab CI/CD）

调用

用于创建镜像的特定构建配置或脚本

材料

构建过程中使用的源代码仓库、依赖项和其他输入

主体

制品本身，由其唯一摘要（哈希值）标识

签名

由受信任实体生成的加密签名，验证证明的真实性和完整性

为了验证 SLSA 溯源证明，组织可以使用 SLSA 验证服务等工具。该服务验证证明的真实性，对照受信任签署者的公钥检查签名，并确保证明符合 SLSA 规范。

为了实现最大的安全性，SLSA 建议由构建平台而非个人开发人员生成溯源。如果您的组织没有使用构建平台，请考虑采用一个支持 SLSA 的平台。对于第三方平台，请检查其兼容性并在需要时请求 SLSA 支持。如果您维护自己的构建平台，请添加 SLSA 溯源生成功能。

同样，软件包生态系统应将 SLSA 溯源与软件包一同分发，将证明嵌入软件包内部或作为单独的元数据文件提供。如果您的组织使用第三方生态系统，请咨询 SLSA 支持并遵循其指南。对于直接分发，请在您的软件包制品中包含 SLSA 溯源。

通过利用 SLSA 溯源证明，您的组织可以对软件制品的真实性和完整性充满信心，并降低供应链攻击的风险。

超越 SLSA 增强供应链安全

尽管 SLSA 为构建完整性提供了一个出色的框架，但它主要侧重于制品溯源和构建系统完整性。为了应对 OWASP CI/CD 十大风险中识别出的所有供应链风险，组织需要额外的安全措施。

全面的供应链安全策略应包括：

持续行为监控

现代交付和安全平台，由人工智能和机器学习提供支持，正在不断改进，以检测跨仓库、构建系统和部署管道的异常活动。这些系统建立正常行为基线，并标记可能表明被入侵的偏差。Datadog CI 和 GitGuardian 等监控和安全工具是当今流行的选择。

高级依赖项分析

除了基本的漏洞扫描，智能分析工具可以评估包行为、代码模式和维护者活动趋势，以在恶意依赖项被公开报告之前识别它们。AI 驱动的系统可以通过传统扫描器无法实现的方式分析代码语义和行为，从而检测到细微的入侵迹象，帮助抵御复杂的供应链攻击，如依赖混淆或错字抢注。

自动化策略强制执行

在整个管道中实施自动化策略防护，以强制执行超出构建完整性范围的安全要求。这些系统可防止过度许可的访问、阻止危险配置，并确保正确的秘密管理——解决 SLSA 未完全涵盖的风险，如 RBAC 不足和凭据管理不当。目前，在交付平台中广泛实施策略仍不均衡。展望未来，这是一种强有力的方法，将受益于 AI，使其在适应不断变化的威胁方面更具适应性，并在 PaC 场景中通过 AI 代码生成协助快速创建策略。

供应链风险预测

预测分析和 AI 模型分析历史漏洞趋势和新兴威胁情报，以突出供应链中构成更高潜在风险的组件，帮助团队在漏洞成为关键问题之前主动解决它们。通过分析数千个项目和依赖项的模式，这些系统在安全事件发生之前识别您环境中的风险因素，从而实现对脆弱区域的主动加固。

通过将这些 AI 增强的能力与 SLSA 的构建完整性重点相结合，组织可以创建一个深度防御方法，解决供应链的全部风险。这种全面的策略不仅保护构建过程，还保护从开发到部署的整个软件交付管道。

解决 AI 生成的依赖风险

随着组织越来越多地采用 AI 编码助手，一种新的供应链风险已经出现：AI 幻觉抢注。当攻击者注册 AI 工具通过“幻觉”错误建议的包名时，就会发生这种情况，从而为恶意代码注入创造了一个途径。

尽管核心 SLSA 框架为传统供应链攻击提供了显著保护，但使用 AI 编码工具的组织应实施额外的保障措施：

已验证的注册表策略

配置包管理器，使其仅从官方审查的注册表和包含已知良好包的私有仓库拉取。这可以防止开发人员无意中从不受信任的来源安装包，即使 AI 助手建议了它们。

包年龄和流行度检查

实施工具，自动根据最小下载量和已建立的历史指标来验证推荐的软件包。使用量极少的新软件包应触发额外的审查。

AI 置信度验证

当使用提供推荐置信度分数的 AI 编码助手时，实施流程来标记低置信度的包建议，以便针对权威来源进行手动验证。

预安装验证

在您的开发环境中添加自动化检查，在允许将依赖项添加到项目文件之前，验证包在受信任仓库中的存在性和溯源信息。

这些额外的控制措施，结合 SLSA 实践和全面的 SBOM，创建了一种深度防御方法，既能抵御传统供应链攻击，又能防御新兴的 AI 辅助威胁。通过解决 AI 在依赖项选择过程中引入的特定风险，组织可以安全地利用 AI 编码助手，同时保持供应链的完整性。除了 AI 置信度验证外，这些实践中的每一项都对其他基于包的攻击（如错字抢注）有所帮助。

通过软件物料清单 (SBOM) 应对零日漏洞

在第一节中，我们回顾了 Log4j 漏洞利用事件，该事件允许攻击者通过利用日志消息中的特定模式远程执行任意代码，从而导致了大规模的数据泄露、勒索软件攻击以及对关键服务的干扰或中断。这是一个零日漏洞利用的例子，是 insidious 威胁类型之一，因为它利用了软件供应商未知的漏洞，使得攻击者在任何防御措施到位之前就拥有显著优势。在本节中，我们将探讨 SBOM 如何作为对抗此类漏洞的重要工具。SBOM 提供了软件制品中使用的所有组件和依赖项的详细清单。我们将研究 SBOM 的组成和特性，以及它们在 SDLC 中的管理方式。

尽管依赖管理工具和包管理器已经存在多年，用于跟踪和管理软件组件，但自 2018 年以来，SBOM 取得了显著进展。包括美国国家电信和信息管理局 (NTIA) 多方利益相关者流程在内的协作努力，已经为 SBOM 制定了最佳实践和建议。这项协作努力汇集了行业专家、政府机构和学术界人士，共同定义了 SBOM 的生成、共享和消费标准及指南。

因此，SBOM 已成为一个关键的组成部分。事实上，Linux 基金会最近的研究发现，2022 年有 78% 的组织正在生产或消费 SBOM，比上一年增长了 66%。

在为您的软件创建 SBOM 时，您有两个标准可供选择：

CycloneDX

CycloneDX 项目已成为 SBOM 的领先标准，它提供了一种机器可读的格式来表示软件组件、依赖项及其关系。CycloneDX 已经获得了广泛的采用和来自各种组织的支持。

SPDX

软件包数据交换 (SPDX) 是另一种流行的 SBOM 标准，由 Linux 基金会赞助并在 ISO/IEC 5962 国际标准中编纂。它提供了一种灵活且可扩展的格式来表示软件组件。SPDX 在开源社区中已广泛使用了多年。

SPDX 是一种更成熟、范围更广的格式，不仅包含组件信息，还包括 SBOM 本身的元数据，例如其创建者和创建日期。它特别适合管理开源软件 (OSS) 许可和共享包信息。

CycloneDX 是一种较新的格式，提供了更结构化和机器可读的方法，重点是提供软件组件及其关系的详细信息。CycloneDX 通常因其灵活性和适应性而受到青睐，使其适用于各种用例。您的特定用例可能会决定您采用哪个标准；您为软件供应链安全管理选择的工具和流程应能够支持这两种标准。

无论您选择哪种具体格式，评估 SBOM 质量的因素都是相同的。NTIA 已经开发了一套 SBOM 应该包含的最小元素，以提供关于软件组件及其依赖项的基本信息。确保这些元素的存在将促进在各种工具和平台之间对 SBOM 的有效分析，以及对底层 SPDX 或 CycloneDX 规范的遵守。

通过提供全面的组件清单，SBOM 提供了透明度和可追溯性，这有助于确保符合您组织的安全策略和法律要求。策略即代码 (PaC) 框架可以利用 SBOM 来自动化这种合规性。使用 PaC，您可以使用代码定义安全策略，这些策略可以像代码一样进行管理和版本控制。然后可以将这些策略应用于 SBOM，确保软件组件遵守组织对开源软件 (OSS) 的安全标准。自动化合规性降低了人为错误的风险并提高了效率。

例如，您的组织可以定义一项策略，只允许使用具有宽松许可（例如 MIT、Apache 许可证 2.0）的开源软件 (OSS) 组件，以确保与组织现有软件组合的兼容性并避免潜在的法律问题。

您可以定义一项策略，自动拒绝已知漏洞严重性高于某个阈值的 OSS 组件。或者，您可以建立评估 OSS 供应商声誉和可信度的标准。这可以包括供应商规模、安全实践和社区参与等因素。

将 SBOM 与策略即代码 (PaC) 结合起来，创建了一个强大的框架，用于管理开源软件 (OSS) 的使用、确保合规性并缓解安全风险。自动化强制执行安全策略可减轻安全团队的负担并提高整体效率。

使用 SBOM 修复依赖问题

在拥有无数依赖项的复杂代码库中，精确定位和修复受影响的制品可能是一项艰巨的任务。遵循以下最佳实践可以帮助您的组织快速应对零日漏洞利用和其他威胁：

保持 SBOM 最新

确保 SBOM 作为您的 CI/CD 流程的一部分自动生成。这确保您始终拥有关于您的软件依赖项的最新信息，涵盖您的组织支持的每个制品。

利用自动化漏洞扫描工具

使用自动化工具根据漏洞数据库扫描您的 SBOM。这些工具可以及时识别您的依赖项中的已知漏洞，从而使您能够优先安排修复工作并应对潜在的安全威胁。

建立健全的补丁管理流程

制定一个明确的流程，用于修补 SBOM 中识别出的漏洞。这包括设定修补优先级、与供应商协调以及在部署前测试补丁。通过维护一个最新且安全的软件供应链，您可以显著降低零日漏洞被利用的风险。

AI 显著增强了这些最佳实践。智能 SBOM 分析系统可以：

预测漏洞影响

AI 模型可以分析您的应用程序架构，以确定脆弱组件是否处于可利用的位置，区分理论漏洞和那些构成即时风险的漏洞。这种上下文分析有助于团队首先关注最关键的问题。

自动化依赖更新

当识别出漏洞时，AI 系统可以自动生成带有相应依赖项更新的拉取请求，测试与您的代码库的兼容性，并管理跨多个仓库的更新过程。这种自动化显著缩短了从漏洞披露到修复的时间。

识别隐藏依赖项

机器学习算法可以检测包清单中可能未明确捕获的未文档化或传递性依赖项，从而提供更完整的实际攻击面视图。

采纳 DevSecOps 原则

在本章中，我们已经看到了软件供应链是多么脆弱。持续以安全的方式交付软件，不仅仅需要对您使用的工具和第三方组件进行仔细审查。它还需要选择支持 SLSA 以及生成 SBOM 和证明的 CI/CD 工具和技术。为了确保持续的安全交付，您的团队必须维护一个安全的平台，进行彻底的漏洞测试，及时优先处理和修复问题，防止不安全代码的发布，遵守法规，并保证您的软件及其所有组件的完整性。

这不能是您团队中某个单一角色或组织内某个单一团队的工作。它需要一种协作方法，将安全集成到整个 SDLC 中。这就是 DevSecOps 方法所倡导的。与传统方法中仅在少数地方添加安全不同，DevSecOps 促进开发、安全和运营团队之间的持续协作，确保从一开始就考虑安全。

在本节中，我们将解释 DevSecOps 原则，并展示采纳这些原则如何帮助您更快地识别和修复漏洞，降低数据泄露风险，并提升软件的整体安全性。

建立协作文化，打破职能孤岛

成功实施 DevSecOps 的第一步也是最关键的一步是建立一种以安全优先为理念的协作文化。当然，这可能是最困难的一步，需要您组织领导团队的全力支持。安全必须成为组织的首要任务，并成为开发人员、运营团队、安全团队和其他人员共同承担的责任。

打破孤岛并建立共同所有权意识的一个简单方法是创建跨职能的 DevSecOps 团队。孤立的团队会限制沟通和知识共享，这可能导致重复工作和不一致的流程。相比之下，跨职能的 DevSecOps 团队能够促进协作和开放沟通。例如，在建立新的安全实践或选择新的安全相关工具时，通过纳入开发、运营和安全角色的视角，您可以更容易地获得成功所需的认同和协同。

此外，跨职能团队有助于防止导致瓶颈和生产力紧张的选择或建议。一个例子是单方面强制执行新的应用程序安全检查，而不考虑其对开发过程的影响。这不仅会增加开发人员的工作量，还会损害组织内部的信任和善意。

除了创建跨职能团队，您还应该在整个组织中识别和支持一些关键的安全倡导者，以帮助推广安全举措并在同事中提高安全意识。利用您的跨职能团队和安全倡导者，通过建立开放透明的沟通渠道来分享想法并传达您的进展，从而促进信息和思想的交流。这可以包括定期会议、团队聊天和知识共享会议。

AI 工具通过提供共享上下文并翻译安全与开发关注点之间的信息，充当安全团队和开发团队之间的协作桥梁。例如，当一个 AI 驱动的安全工具识别出漏洞时，它可以以开发人员友好的术语解释问题，同时提供安全团队所需的安全上下文。这种共同的理解减少了团队之间的摩擦，并有助于建立一种人人说相同语言的安全文化。

最后，投资于安全培训。识别技能差距，并为所有团队成员提供持续的安全培训，使他们掌握识别和缓解安全风险的知识和技能。这不仅提高了整个团队的标准，也表明了您组织对安全的优先承诺。

采纳并强制执行安全编码方法和左移

安全编码实践对于防止漏洞至关重要。OWASP Top 10 和常见缺陷枚举 (CWE) 为识别和解决常见的安全漏洞提供了有益的指导。此外，请确保您的方法能够解决以下常见威胁：

输入验证

始终验证用户输入，以防止恶意数据被注入到您的应用程序中。这有助于防止 SQL 注入、XSS 和其他注入攻击。

输出编码

正确编码输出以防止 XSS 攻击。这确保了用户生成的内容在页面上安全显示，而不允许恶意代码执行。

错误处理

实施健壮的错误处理，以防止信息泄露和潜在漏洞。避免显示可能为攻击者提供有价值信息的敏感错误消息。

会话管理

使用安全的会话管理技术来保护用户数据并防止未经授权的访问。这包括使用强大的会话标识符和实现超时。

认证和授权

实施强大的认证机制，并强制执行适当的授权控制，以限制对敏感资源的访问。

加密

使用安全的加密算法和实践来保护敏感数据。避免弱加密方法并确保正确的密钥管理。

依赖管理

保持依赖项最新并安全管理它们，以避免漏洞。使用依赖项扫描工具等工具来识别和解决第三方库中的已知漏洞。

尽管及时了解最新威胁和安全编码可以防止许多漏洞，但您组织的努力并非万无一失。静态和动态分析工具，以及早期安全测试，可以作为一道防线，捕获代码审查中可能被忽视的问题。这就是左移的意义所在。我们已经介绍了左移如何使您能够在早期阶段识别和解决漏洞。早期修复可以降低漏洞发布到生产代码中的风险。

总结

在现代软件开发中，安全不能是事后才考虑的问题。它必须是整个开发过程中不可或缺的一部分。正如我们在本章中看到的，AI 原生的安全方法改变了：

• 如何发现漏洞，使用智能分析而非仅仅静态规则
• 如何根据实际风险而非通用严重性评级来确定发现结果的优先级
• 如何实施修复，通过自动化指导和代码生成
• 如何通过持续监控和异常检测来保护供应链
• 团队如何协作，在安全与开发之间共享上下文和理解

通过将安全嵌入到从设计到部署的每个阶段，并通过培养一种由 AI 增强的共享责任文化，组织可以构建和交付能够抵御现代威胁的应用程序。

在 第 6 章 中，我们将把注意力转向通过混沌测试来揭示可能未被发现的弱点，从而提高应用程序的韧性。