随着大家的意识逐渐增强， 保护您的软件供应链 应该成为每个组织网络安全战略的重要组成部分。
创建减轻软件供应链威胁的综合策略的主要困难之一是供应链的复杂性和多样性。每个供应链都是独一无二的，并且涉及的元素不断变化，因此很难信任自己的供应链，更不用说它生产的软件了。
在本文中，我们将描述一个持续合规平台，该平台使软件消费者和生产者能够透明地展示信任和合规性，以确保 SDLC 安全、推广安全最佳实践、满足监管要求并缓解 网络风险 运用 a证明.
我们提出的模型由集合块组成，无论您首选的平台或用例如何，这些块都可以轻松扩展并集成到您的堆栈中。最后，我们将使用以下方法演示基本验证策略 Scribe 的 Valint 工具 表明这个过程并不像您首先担心的那么复杂。
供应链混沌理论
确保供应链安全的主要挑战之一是所涉及系统的复杂性。您的软件供应链包括创建最终产品所涉及的每一个软件，无论是作为环境的一部分还是作为集成到代码库中的软件。从这个描述中你可以看出，这些供应链是巨大的，包括从开发人员开始编写代码的那一刻起，一直到编译、测试、集成，一直到最终产品运行并整合每一个部分的一切。一路上使用的软件和库。
为此类系统定义安全模型需要了解大量的编程 语言、包管理器、产品、技术堆栈、CI 服务、云提供商、依赖项导入、VM、操作系统以及给定供应链中可能包含的其他组件。必须考虑此类系统中可能面临风险的各种资产，包括应用程序、令牌、密钥和其他形式的访问权限。
策略验证模型概述
我们提出的模型包括多个构建块，这些构建块协同工作以确保供应链的安全性和合规性. 需要这些构建块来持续验证软件安全方面以及软件供应链监管的合规性。
- 证据：旨在由策略自动使用的不可变对象。这些对象包含启用策略执行和满足合规性要求所需的元数据。证据内容包括有关工件、事件和设置的元数据，但也可以收集实际报告、配置或扫描。
证据 可以采用签名和未签名两种形式。我们建议遵循 i正托托 认证规范 利用签名的 证明 并且未签名 声明 格式，分别。- 证明（又名可验证的签名证据）： 与特定相关的可验证证据 环境背景，使用某种形式的 PKI 签名来传达信任。
- 环境背景：上下文信息将模型联系在一起。
它回答了证据从何而来以及包含哪些信息的问题。重要的是，上下文与证据相关联，而不是成为证据的一部分，因为您可以将多个证据链接到同一上下文，并且此模型允许更轻松、更高效地搜索和检索证据。
用基本术语来说，环境上下文是一个标签系统，其中大多数标签是从环境、平台或工件中读取的。标签提供对开发流程和 CI/CD 管道的许多流程的标准化访问。与证据来源相关的方面，例如 Git 存储库、标签和提交，还包括工作流名称、作业名称、runID 等。环境上下文还可以包括主题的各个方面，例如工件哈希、名称和标签。
上下文可以被视为整体的延伸 认证规范，集成到签名的有效负载中。利用标签系统，我们可以为政策评估阶段提供多种方面的通过标签查询证据的方式。此外，背景数据可以用作政策评估过程的一部分，为证据添加“情境意识”。
- 政策： 一组用户配置的策略模块，用于定义所需的合规性报告。策略可能会指定构建管道或开发过程中包含的不同类型的产品或系统的最低安全标准或所需的合规级别。最重要的是，由此产生的政策评估会创建合规报告，这些报告 证明 以及。这使我们不仅可以管理合规报告（例如，向利益相关者公开您的合规状态），还可以利用合规报告制定更复杂的策略，这些策略可能包含组织更大范围的合规监管。政策可以分为 政策模块。这些插件实现了共享某些特征的策略规则集（类似于软件模块）。这些插件由策略提供商提供（稍后会详细介绍）。
策略模块的评估提供的结果包括评估、合规性详细信息以及涉及相关安全法规的判决。此外，结果包括回溯评估合规性的证据模块所需的证据历史记录。 - 商店：提供托管、上传/下载和证据查询功能的服务（稍后详细介绍）。它们可以通过图像注册表（OCI 作为存储）、专用服务（即 Scribe 服务）或简单的本地文件系统来使用。
- 政策提供者： 这些是负责签署和提供政策模块的实体（公司、组织）。通过提供策略作为一种证明，提供商向策略本身传达了信任和透明度。例如，OPA 捆绑证明可以授权监管机构发布和签署实施政策模块的官方 OPA 捆绑。
通过利用这些构建块，我们的模型使组织能够相对轻松地验证其构建管道和开发生命周期的安全性和合规性。
它是如何工作的
此工作流程的起点是开发人员或系统，为软件产品或组件生成证据。收集证据内容以及上下文信息、主题和签名并将其上传到证据存储。
另一方面，合规报告是通过评估适合组织需求和要求的策略来创建的。
使用上下文信息，政策评估可以查询供应链产生的证据，并确保它们包含监管可能需要的所有信息.
作为额外的好处，政策和合规报告本身可以作为证据访问，提供透明度和信任以及所有涉及证据的历史追踪。这使得组织不仅可以管理合规性报告，还可以将其用作可信证明，以向软件消费者传达信任.
通过利用此流程，组织和利益相关者可以降低风险、提供透明度并确保其供应链内的合规性，从而减少混乱的影响并提高对其产品的整体安全性和信任度。
政策评估
这款 评估 政策的审核是通过验证一组政策模块来完成的，每个模块都支持特定的法规和合规性需求。
政策评估向每个模块提出两个简单的问题：
- 遵守该模块需要什么证据？
- 证明合规的证据标准是什么？
例如，在以下背景下 SLSA（软件工件供应链级别）框架，策略模块可能会指定签署的 SLSA 来源证据和构建管道的安全态势扫描都需要符合安全要求。然后将验证这些模块提供的证据，以确保其满足 SLSA 的所有要求。
- 遵守 SLSA 要求需要什么证据？
- 构建工件的 SLSA 出处证明（签名证据）。
- 对生成工件的 CI 管道进行安全态势扫描。
- 证明符合 SLSA 要求的证据标准是什么？
- 这两份证据都必须包含满足所有 SLSA 要求的信息。
对于此示例，SLSA 来源证明需要完整地描述您的映像构建过程，而安全态势证明需要验证存储映像源的 SCM 是否使用分支保护规则。
- 这两份证据都必须包含满足所有 SLSA 要求的信息。
策略模块的另一个例子是 验证工件模块，它指定某些工件必须由可信来源签名。利用证明（可验证的签名证据）PKI（公钥基础设施）签名，以满足需要对工件进行签名的特定个人/实体的要求，并证明工件源自何处的上下文。
这款 验证工件模块 回答以下问题：
1. 需要什么证据来证明符合安全要求？
- 描述包含 PKI 签名（证明）的工件的证据。
2. 如何验证这些证据以确保合规？
- 证明PKI签名有效。
- PKI证书身份符合用户需求。
- 证据主题符合用户要求。
- 格式和来源符合用户要求。
从理论到实践
让我们深入研究一下 Valint 工具目前支持的这个模型的实现。
让我们看一个简单的策略示例，该策略指定如何验证图像的签名和来源。
具体来说，我们需要验证证据是否满足以下标准：
- 证据类型是描述图像的 CycloneDX SBOM 证明。
- 该工件的签名者为 我的公司网站.
- 该图像源自由以下内容触发的 Circle-CI 工作流程 我的图像源 回购。
模板政策
在前面的示例中，策略是静态的，仅检查名为的特定图像 我的公司/我的图像。然而，通常最好有支持模板/变量功能的策略。这允许您定义可应用于 CI/CD 构建管道中的多个类似流程或工件的需求。
要模板化策略，您可以使用变量而不是将策略静态锁定到产品。在上面的例子中，您可以更改 工件名称 值到`$MY_IMAGE相反，允许评估人员为需要相同合规性法规的大量图像配置一项策略。
展望未来
At 刻划式打标系统，我们的最终目标是通过证据驱动的可验证合规模型来降低供应链中的风险。最先尝试此模型的地方之一是 CI/CD 构建管道。我们相信，这种证据验证方法是确保供应链透明度和问责制的关键，并使所有相关利益相关者受益。我们的模型封装了软件供应链社区中的许多新兴想法，定义了它们之间的关系。我们致力于创新和提高软件供应链透明度。如果这个模型引起了您的兴趣，我鼓励您查看我们的 Valint CLI 文档 我们扩展了该工具的功能和用途。请随意尝试一下。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
