泄露的凭证，即秘密，容易被不法分子利用，获取你的环境和数据。尽管没人希望将这些宝贵的 API 密钥、令牌和密码暴露在外，但现代软件开发生命周期的复杂性使得秘密泄露的机会很多。仅在 GitHub 上，GitGuardian 在 2023 年发现了超过 1270 万个硬编码凭证。这一问题正在不断增长。

　　秘密可能出现在一个意想不到的地方，那就是你用来证明安全构建制品的文件：SLSA 来源文件。我们来看看这是如何发生的，以及你可以采取什么措施。

　　SLSA 意味着文档的生成

　　你可能听说过软件制品供应链级别（SLSA[2]），这是由 OpenSSF 社区维护的框架，旨在提升软件供应链的安全性。项目方表示：“这是从‘足够安全’走向尽可能具有韧性的方式，链条中的任何环节。”这无疑是对抗 Log4Shell、SolarWinds 和 XZ Utils 后门等威胁的有力工具。

　　SLSA 的核心有两个概念：证明和构建来源。项目将其定义为：

　　证明是关于软件制品或软件制品集合的经过认证的声明（元数据）。

　　构建来源是对特定构建平台生成一组软件制品的证明，消费者可以验证该制品是否按预期构建，以便他人可以在需要时重建该制品。

　　来源文件中的内容

　　你的构建来源存储在来源文件中。这些文件包含构建过程中使用的源代码库标签、所有参数和所有配置步骤的输出。你可能会惊讶地发现凭证就出现在最后这一部分。

　　即使你使用了秘密管理平台或保险库系统，这些秘密在运行时最终还是会被暴露。很可能在记录构建过程时，来源文件中会包含一些 API 密钥或认证令牌。更糟糕的是，如果你的代码库中硬编码了凭证，这些秘密必定会出现在所有日志和证明中。

　　JSON 格式的来源文件示例，包含名为 BLAM 的数据库服务器的凭证

　　为 SLSA 实施秘密检测和编辑

　　你无法预知谁会访问你的 SLSA 文档，以及他们可能会如何利用这些信息。幸运的是，你可以采取一些步骤来最小化这些制品带来的风险，很可能你已经在处理日志文件时采取了类似措施。

　　为了防止攻击者从日志文件中直接读取明文凭证，你需要清理日志文件。希望你已经具备解决这一已知问题的工具。幸运的是，你可以利用这些工具扫描来源文件中的秘密，以便删除它们。

　　在解决与 SLSA 框架相关的文件中的秘密时，请考虑以下几点：

　　自动化秘密扫描：

　　集成自动化工具，扫描源代码、配置文件和构建制品中的秘密。

　　像 GitGuardian、TruffleHog 和 Detect Secrets 这样的工具可以识别代码库中的硬编码秘密。

　　自动化秘密编辑：

　　在构建过程中，自动将任何检测到的秘密替换为占位符值（例如）。

　　这可以在文件被写入磁盘之前作为文档创建过程的一部分完成。

　　避免将秘密纳入版本控制：

　　强制执行严格的版本控制实践，防止秘密提交到代码库。

　　实施预提交钩子，在代码提交之前扫描秘密。

　　在实施新框架时保持安全

　　如果你已经在项目中实施 SLSA，感谢你！SLSA 框架为保障软件供应链提供了稳健的方法，这是我们都应该努力追求的。不论你处于采用的哪个阶段，重要的是要记住，像任何新方法解决安全问题一样，我们需要关注新的攻击面和攻击者利用我们工作的方式。

　　在这个框架中，秘密检测和编辑的重要性不容忽视。不法分子正在积极寻找进入你环境的方法，而泄露的凭证为他们提供了便捷的途径。幸运的是，市场上有许多工具可以集成到你的工作流程中，自动扫描秘密。一旦发现，通过简单的脚本可以自动化编辑过程，帮助保持所有文件中不含明文凭证。

　　确保当有人阅读你的证明时，他们能信任你的制品，而不是意外进入你的系统。