将环境变量注入构建过程是一种 standard 现代实践 CI/CD pipeline团队会将环境变量注入构建过程，以便在不硬编码值的情况下将密钥、令牌和运行时配置传递到构建中。表面上看，这似乎是一种简单安全的模式。
然而，在实践中，它往往成为软件供应链中最被低估的风险之一。
因为一旦团队将环境变量注入到构建过程中，这些值就不再是隔离的了。所有在该过程中运行的程序都可以访问它们。 pipeline构建脚本、CLI 工具、第三方操作，甚至依赖项都可以读取它们。
事情就是从这里开始出错的。
本指南将详细介绍团队如何在实际构建过程中注入环境变量。 pipelines，泄漏实际发生在哪里，以及如何在不减慢开发速度的情况下保护构建过程。
将环境变量注入构建过程意味着什么
从本质上讲，注入环境变量意味着将值传递给一个 pipeline 在运行时，以便作业在执行期间可以访问它们。
这些值通常包括 API 密钥、数据库凭据、令牌或特定于环境的配置。它们并非直接存储在代码中，而是存储在云端。 CI/CD 系统会在构建开始时动态加载它们。
这解决了一个实际问题。它保持代码简洁，避免重复，并允许相同的操作。 pipeline 可在预发布环境、测试环境和生产环境中运行。
然而，这种模型依赖于一个不再成立的假设：构建环境是可控的、可预测的。
现代 pipeline它们既非配置也非依赖。它们包含多个步骤、外部集成和依赖项，能够动态执行代码。因此，一旦变量被注入，它就不再仅仅是配置，而是成为执行上下文的一部分。
构建过程中环境变量泄漏的位置
大多数泄密事件并非因为有人明确泄露秘密而发生，而是因为…… pipelines 的行为方式是开发者无法完全预料到的。
例如，开发人员可能会启用详细日志记录来调试构建失败的问题。命令行工具可能会在其输出中打印环境变量。依赖项可能会在执行过程中静默访问进程变量。
这些行为单独来看都不算可疑。然而，它们结合起来却会形成多条泄密途径。
秘密最终可能会落入以下境地：
- 构建日志将被存储和索引
- 团队间共享调试输出
- 运行外部代码的第三方 CI 操作
- 安装或运行时执行的依赖项
- 构建过程中生成的临时工件
一旦秘密信息出现在日志中，它就很难被完全控制。日志会被复制、存储并跨多个系统保留。此时，泄露的范围远远超出了最初的范围。 pipeline.
这就是为什么环境变量泄漏常常在造成损害之后才被发现的原因。
为什么团队会在构建过程中注入环境变量
尽管存在这些风险，团队仍然大量依赖环境变量注入。这并非没有道理。
它使 pipeline保持灵活性。单一工作流程可以适应不同的环境，针对多个服务进行身份验证，并在不修改代码的情况下动态改变行为。
在快速发展的DevOps环境中，这种灵活性至关重要。然而，灵活性总是伴随着权衡取舍。越是动态变化的…… pipeline 规模越大，就越难控制其内部发生的情况。每增加一个步骤、集成或依赖项，敏感数据可能被访问的地方就越多。
因此，环境变量注入从配置细节转变为安全问题。
将环境变量注入构建过程时常见的风险
这些风险并非理论上的，而是真实存在的。 pipeline每天都是如此。
秘密泄露到日志中
日志是其中之一 最常见的暴露来源调试标志、CLI 工具和堆栈跟踪经常会在开发人员不注意的情况下泄露敏感值。
一旦暴露出来，这些数值就会迅速在系统中传播。
过度宽松的访问权限
更多来自Google的 pipeline这会将所有变量暴露给所有作业，从而造成不必要的风险。
如果其中一步遭到破坏，它就能获取它实际上并不需要的凭据。
依赖和行为滥用
现代 pipeline严重依赖第三方工具和集成。这些组件与您的密钥运行在相同的环境中。
如果其中一个程序运行异常，它可以悄无声息地访问注入的变量。
根据 OWASP供应链攻击经常利用构建过程中的可信组件。环境变量往往成为最容易攻击的目标。
代码中的备用密钥
当构建因缺少变量而失败时，团队有时会添加备用值以保留 pipeline正在运行。
随着时间的推移，这些值会变得 commit已部署或已实施，造成长期影响。
将环境变量安全地注入构建过程的最佳实践
| 类别 | 最佳实践 | 为什么重要 |
|---|---|---|
| 秘密存储 | 使用密钥库或 CI 密钥管理器 | 防止代码泄露 |
| 访问控制 | 每个作业限制访问权限 | 减少攻击面 |
| 记录 | 掩蔽敏感值 | 防止泄漏 |
| 范围和寿命 | 使用短期凭证 | 限制爆炸半径 |
| 验证 | 如果缺少变量，则构建失败 | 避免不安全的备用方案 |
为什么有很多 CI/CD 安全工具遗漏环境变量泄漏
大多数安全工具都侧重于在构建完成后扫描代码或依赖项。
然而，环境变量泄漏发生在执行过程中。
A pipeline 即使能够正确注入密钥，仍然可以通过日志或运行时行为将其暴露出来。等到扫描器检测到问题时，密钥可能已经泄露。
这就造成了检测和预防之间的差距。
团队需要一些控制措施，以便在以下情况下发挥作用： pipeline 运行，而不是结束后。
我们如何建议保护环境变量注入
实际上，有效的保护归根结底取决于几个始终如一的原则。
将秘密存放在外面 pipeline仅在运行时注入。将访问权限限制在所需的最小范围内。尽可能使用短期凭据。
同时，监测如何 pipeline访问敏感数据。异常的访问模式通常预示着风险，甚至在泄漏显现之前就已出现。
这种方法将安全防护从被动检测转变为主动控制。
Xygeni如何帮助保护 CI/CD 秘密注射
Xygeni 不只是依赖于构建后的扫描，而是分析了以下情况： pipeline程序在运行时会使用环境变量。这包括密钥如何在作业之间传递、构建步骤如何访问它们，以及依赖项如何与执行环境交互。
例如，Xygeni 可以检测到何时 pipeline 过度暴露变量，导致某个步骤有可能将敏感值打印到日志中，或者某个依赖项试图意外地访问凭据。
在同一时间， guardrails 直接执行政策 pipeline团队可以阻止不安全的构建，限制对特定作业的秘密访问，并在风险配置进入生产环境之前阻止它们。
因为这种情况发生在 CI/CD 工作流程中，开发人员无需改变他们的工作方式。安全性成为工作流程的一部分。 pipeline不是一个单独的步骤。
因此，团队可以了解密钥的使用方式，控制密钥的泄露方式，并在不减慢交付速度的情况下降低泄露风险。
总结
然而，这也引入了一层常常被忽视的风险。
问题不在于是否使用环境变量，而在于如何在执行过程中控制它们的暴露。
在现代 DevOps 环境中，在构建过程中防止泄漏远比事后检测泄漏重要得多。
