使用 Valint 将策略应用于您的 SDLC

Valint 是用于创建、管理、签名和验证证据的主要 Scribe 工具。在一个 以前的帖子，我们介绍了使用签名和验证证据作为验证 CI/CD 管道安全性的主要工具的理论。简短提醒一下，Scribe 提出的模型包括几个构建块，可以根据您的需求以任何方式对这些构建块进行洗牌和堆叠。构建模块包括收集的证据（物料清单, 萨尔瓦多 出处、您希望包含的任何第三方测试结果）、所收集证据的环境背景（谁创建了它、地点、时间等），以及您希望应用于该证据的政策。

由于您希望应用于证据的策略是此模型中的关键因素，因此我们认为我们应该专门撰写一篇博文来更详细地探讨我们提供的策略引擎的潜力。

在本文中，我们将回顾我们设计的最基本的策略（签名和验证信息）。我们将介绍更复杂的策略模板是什么样的，并提供一些标准的策略示例，例如如何验证特定用户是否是创建最后一个“主”分支的用户，或者如何验证管道是否运行包括必须包含的第三方工具测试。

从这里开始：签署和验证证据

瓦林特 是一个非常通用的工具，但为了使本文简单起见，我们将主要使用 Valint 的 CLI 界面作为示例。

第一步是下载 Valint：

curl -sSfL https://get.scribesecurity.com/install.sh | sh -s -- -t valint

从存储库或映像创建 SBOM 的命令是“bom”。所以，举例来说，如果你想 bom 的形象 busybox:latest 该命令将如下所示：

$HOME/.scribe/bin/valint bom busybox:latest -o attest -f

需要注意的是 attest 是的别名 attest-cyclonedx-json.

默认情况下，Valint 使用 登录 交互流作为 Scribe 的 Cocosign 库中嵌入的签名机制背后的引擎。该库处理用于签名和验证的数字签名。应用该命令后，您需要首先批准您希望使用 Y/[N] 选项签署证据：

您还可以使用标准 PKI 进行签名（我们支持 x509 证书）。有多种用于存储签名密钥的选项 - 例如 KMS、GitHub 秘密存储，并且您可以轻松配置 Valint 以使用您希望的任何签名机制。

假设您批准签名，您将被定向到浏览器中的 Sigstore，您需要使用 GitHub 帐户、Google 帐户或 Microsoft 帐户登录：

登录后您将看到登录成功：

此时您可以关闭浏览器并返回 shell，您可以在其中看到证据已成功创建。

默认情况下，证明会写入本地缓存，其位置由 --output-directory 配置文件中的flag标志。您还可以使用 -输出文件 标志来提供认证的自定义路径。

现在我们已经创建了签名证明，让我们尝试验证它是否存在并且已签名。验证证据的命令是 verify. 使用方法和上面几乎一样 bom 命令，但我们将使用标志 -i这是短的 --input-format 它的默认值是，就像 bom, attest-cycledx-json。 verify 命令将首先在 Valint 使用的默认位置查找所需的证据。如果您既想保存证据又想稍后查找，您可以指定不同的位置。

所以，如果我们想验证 busybox:latest 我们在前面的示例中生成并签名的图像证明命令将如下所示：

$HOME/.scribe/bin/valint verify busybox:latest -i attest

假设您所做的一切都是正确的，结果应该如下所示：

您可以看到包含原始证明上的签名者电子邮件的电子邮件列表，还可以看到已验证的证明的类型，在本例中为 cyclonedx-json。 

看起来很简单吧？让我们把它提升一个档次。

策略模板

A 政策 由一组 模块。 如果策略包含的所有模块都经过评估和验证，则该策略已得到验证。如果发现任何符合模块配置和设置的证据，则验证模块。  

策略配置为 Valint 配置文件的一部分，位于策略部分下。这是 Valint 配置文件的一部分的示例，该部分包含潜在的策略。 

请记住，您不必在项目中包含配置文件 - Valint 可以在仅启用默认选项的情况下正常工作。此外，由于此文件中的所有内容都是可选的，因此拥有这样一个仅包含您的策略的文件是完全有效的。 

默认命名为 .valint.yaml 的配置文件应包含在存储库的根目录中。当您运行命令时，根据您在此文件中包含的任何策略 valint verify 它将运行启用的任何策略和模块。由于基本“验证”策略是默认策略，因此您无需为 verify 即使没有 .valint.yaml 文件，命令也能正常工作。

无论您添加到配置文件中的策略是什么，都取决于是否有证据可供查找。默认情况下，当您在管道中运行“bom”命令时，生成的证据将上传到 Scribe 证据存储。同样，当您运行“验证”命令时，它将在 Scribe 证据存储中查找证据。您可以更改此默认值并使用 OCI 或缓存作为证据存储，但对于本文，我们将假设使用默认值，并且所有证据均从 Scribe 证据存储中上传和提取。

因此，基于此示例，我们来看看策略的组成部分。这 政策 支持以下字段：

• 姓名，策略名称（必填）。
• enable，启用模块（默认为 false）。
• 模块，策略模块配置列表。  

 

这款 模块 部分支持以下字段：

• 姓名，策略模块名称（必需）。
• enable，启用模块（默认为 false）。
• 类型，模块类型，目前支持 验证工件 和 git 所有者.
• 匹配，将证据与特定上下文进行匹配。
• 输入，模块特定配置。

一个策略可以有多个模块，一旦执行“验证”命令，所有启用的模块都将运行。 

因为我知道枯燥的字段列表并不能提供太多信息，所以让我们直接进入下一部分，即示例策略。

政策样本

图像验证政策

让我们从最简单的策略开始，即表达 Valint 签名验证流程的策略。 

证明：cocosign：策略： - 名称：verify_policy 启用：true 模块： - 名称：signed_sbom 类型：verify-artifact 启用：true 输入：签名：true 格式：attest-cycledx-json 身份：电子邮件： - barak@scribesecurity.com

同样，此策略应包含在存储库根目录下的 .valint.yaml 文件中。为了让它工作，您需要通过运行以下命令提前创建一个签名的 SBOM valint bom 命令。准备好验证后，您需要运行 valint verify 命令。

查看此示例，我们可以看到该策略已启用，并且它有一个启用的模块类型 ‘verify-artifact‘. 该模块检查输入是否已签名，格式是否正确 ‘attest-cyclonedx-json’, 并且它是由电子邮件所代表的身份签名的 ‘barak@scribesecurity.com’.

要运行此策略，我们需要执行 verify我们的管道中的命令如下：

valint verify busybox:latest

由于 verify 命令现在基于我们提供的策略，它将寻找 busybox:latest Scribe 证据存储中的证据。它将寻找格式为签名的 SBOM `cyclonedx-json` 它将检查签署 SBOM 的身份是否使用策略中规定的电子邮件 `barak@scribesecurity.com`.

您可能会说，证据存储中可能存在多个类似的图像，您是对的。这就是上下文发挥作用的地方。默认情况下， verify 命令将寻找最接近的可用匹配。但是，您可以指定该命令需要与管道运行 ID 的上下文或创建工件的构建系统相匹配。为此，您需要使用该字段 match: 具有适当的上下文类型。例如：

            匹配： context_type：github git_url：github.com/my_org/myimage.git 分支：main

在这种情况下，证据必须是由 Github 生成的，由 GitHub 命名的存储库生成。 git_url 并且由 main 该存储库的分支。在需要时使用正确的上下文非常重要，以确保您的策略准确验证您希望他们验证的内容。 

二进制验证政策

让我们看另一个例子。此策略旨在验证我们正在检查的 exe 文件是否来自特定存储库，并且由几个已知个人之一签名。 

证明：cocosign：策略：-名称：verify_policy启用：true模块：-名称：binary_module类型：verify-artifact启用：true输入：签名：true格式：attest-cycledx-json身份：电子邮件：-barak@scribesecurity.com- mikey@scribesecurity.com - adam@scribesecurity.com match: target_type: file context_type: azure git_url: https://dev.azure.com/mycompany/somerepo # 环境的 Git url。输入名称：my_binary.exe

查看此示例，我们可以看到该策略已启用，并且它有一个启用的模块类型 ‘verify-artifact‘ 该模块检查输入是否已签名以及格式是否正确 ‘attest-cyclonedx-json’, 并且它是由模块中列出的 1 个允许的电子邮件地址之一签署的。此外，它还检查 verify 命令接收一个输入以验证该输入是否已命名 ‘my_binary.exe’，输入是在 Azure 中创建的文件，并且它来自特定的 git URL： https://dev.azure.com/mycompany/somerepo.

正如您所看到的，此示例中对于要验证的策略有更多要求。

要运行此策略，我们需要执行 verify 我们的管道中的命令如下：

valint verify file:my_binary.exe

为了确保您的 Scribe 证据存储具有该二进制文件的签名版本，您应该首先创建如下证据：

valint bom file:my_binary.exe -o attest

第三方证据验证政策

在我们的最后一个示例中，让我们看看如何验证我们使用的第三方工具是否在我们的管道中正常运行，并以 JSON 文件的形式创建了我们期望的结果。 

证明：cocosign：策略： - 名称：verify_policy 启用：true 模块： - 名称：第 3 方规则类型：验证工件 启用：true 输入：签名：false 格式：attest-generic 身份：电子邮件： - bob@scribesecurity。 com 匹配： target_type：通用 context_type：azure git_url：https://dev.azure.com/mycompany/somerepo git_branch：主要 input_name：3rd-party-scan.json

在此示例中，我们假设在管道中的某个时刻，我们运行了一个第三方工具，该工具创建了“3rd-party-scan.json”文件。为了满足文件应源自 Azure DevOps 的策略，由`触发https://dev.azure.com/mycompany/somerepo` 存储库并由 ` 签名bob@scribesecurity.com`. 

为了生成我们正在寻找的证据，在运行第 3 方工具后，我们需要捕获生成的文件并使用 Valint 将其转换为证据：

valint bom 3rd-party-scan.json -o attest-generic --predicate-type https://scanner.com/scan_format

证据证明了什么？ 

所以我们已经看到我们可以使用 Valine 来验证管道中的各种内容。这个能力到底能用来做什么呢？

让我们想象一下，我们的管道已被破坏，一些坏人已经开始在其中做一些我们不希望他们做的事情。通过验证管道的不同步骤是否按预期进行、产生预期结果并由批准人员签署，我们使坏人更难欺骗我们。

一种潜在的攻击是替换管道末端的二进制文件，以便您的客户端获得的版本是恶意版本而不是原始版本。通过签署您的版本并要求您的客户对照该主副本进行验证，您可以确保他们都使用您生成的相同文件，而不是巧妙的伪造文件。

这种创建证据然后验证证据的模式才刚刚开始。我们不断努力为 Valint 添加额外的功能，使其更加强大和多功能。与此同时，我鼓励您查看我们的 文件 详细了解 Scribe 所提供的功能以及您可以使用 Valint 做哪些事情。 Valint 可以免费下载和使用，所以今天应该没有什么可以阻止您尝试这个工具。