7.1 软件制品的供应链等级

  随着软件供应链攻击的增加，很明显，需要一个全面的端到端框架来定义软件供应链袭击和缓解方法。2021年6月，谷歌开源安全团队推出了软件工件（SLSA）工作该工作的目标是确保软件工件的完整性在整个软件供应链生命周期中得到维护。
  SLSA包括四个级别，每个级别都提供更高级别的完整性保证，但实施者的成熟度和严格性水平相一致。组织根据其特定的行业和监管或安全要求，有各种需求来指导其追求的SLSA级别。 与其他安全工作一样，SLSA是一个需要时间和精力才能实现的过程。图7.1显示了四个级别，并对每个级别进行了描述。
  SLSA提供了一个框架，涵盖了从原始开发者到下游消费者和用户的整个软件路径，包括软件与源代码存储库、构建系统、包存储库的交互，以及其间的所有步骤。图7.2显示了 软件供应链，恶意行为者可能会损害消费者在生产环境中使用的下游软件工件的完整性。
  如果恶意者可以在源代码存储库中提交错误代码，则可能会在整个构建过程中执行的下游活动中引入漏洞。引入错误代码并不是与源代码管理相关的唯一问题，因为源代码管理（SCM）系统本身可能会受到攻击和破坏，从而影响存储在其中的代码以及它所促进的下游构建和分发活动。
  这种威胁既适用于自托管SCM，也适用于云提供的SCM。在自托管场景中，自托管SCM的组织从基础设施和托管的角度负责其安全性，而在基于云的场景中，如果作为软件即服务（SaaS）交付，则云服务提供商（CSP）拥有底层基础设施和平台的责任，在一定程度上还负起应用程序本身的责任。
  研究人员François Proulx在其文章《SLSA Dip-At The Source of The Problem！》中描述了与SCM折衷相关的攻击树(https://medium.com/boostsecurity/slsa-dip-source-of-the-problema1dac46a976)。 图7.3显示了恶意行为者的示例攻击向量 可以用于危害SCM存储库，如GitHub。
  持续潜在的软件供应链威胁模型，恶意行为者可能使用批准的构建过程和基础设施，但引入的代码与SCM本应使用的代码不匹配。这是一个代码来源信息对于确保所使用的代码来自预期来源并且没有受到篡改或完整性攻击至关重要的例子。SLSA将出处定义为“关于软件工件的可验证信息，描述在何处、何时以及如何生产。”SLSA级别越高，对出处的要求就越严格。
  构建平台是软件供应链的另一个关键部分，是攻击者的另一个主要目标。这个攻击向量被用于Solar-Winds事件，导致构建系统和恶意软件被插入SolarWinds Orion IT管理产品的软件构建中。随后，SolarWinds的下游客户下载并安装了它，其中包括18000多个组织，其中许多是政府实体，这一事实无疑促成了我们在我们在第一章“背景软件供应链威胁。”提到的网络安全行政命令。
  另一种潜在的攻击途径是，恶意行为者可以注入良性依赖，随后可以对其进行修改以产生恶意行为。一个真实的例子是事件流npm包，其中有人自愿承担项目的维护职责，但最终添加了一个名为flatmap流的恶意依赖项。这尤其有影响力，因为事件流包每周下载量超过190万次！
  恶意行为者还利用机会上传会让下游消费者下载并受到影响的恶意软件包。最引人注目的例子是Codecov事件，该事件涉及恶意行为者使用泄露的凭据将恶意软件包上传到Codecov的云存储中。从那时起，Codecov漏洞也影响了数百个客户网络，因为恶意行为者使用Codecov攻击下游客户网络。如果消费者一直在使用出处验证方法，他们可能会发现下载的工件与源代码存储库中预期的不一样。
  LSA还强调软件证明，他们将其定义为“关于软件工件或软件工件集合的经过验证的声明（元数据）”(https://slsa.dev/attestation-model)。
  SLSA列出了一个表示软件验证的通用模型，如图7.4所示。
  2023年初，SLSA推出了他们的候选版本（RC）规范，这是自2021年6月SLSA首次发布以来的首次重大更新。重大变化包括将SLSA划分为多个SLSA轨道，以衡量软件供应链的特定方面。RC规范 还简化和澄清了原始规范的各个方面，并为原产地验证提供了新的指导。也就是说，截至本文撰写之时，每个拟议曲目的具体内容尚未完全定义，将在SLSA的未来版本中解决。如果您有兴趣了解有关1.0候选版本的更多信息，请访问（https://slsa.dev/blog/2023/02/slsa-v1-rc）