Why do YAML anchors and aliases increase supply chain risk in CI/CD workflows?

Why This Matters for Security Teams

YAML anchors and aliases are attractive because they reduce duplication, but in CI/CD they also create shared state across jobs and pipelines. That matters when pipeline definitions are treated as code, because a single inherited block can change build behaviour, credential use, deployment targets, or approval paths without those changes being obvious in review. The issue is not just readability. It is control integrity.

Security teams often assume that separate jobs are independently governed, yet anchored configuration can make an apparently local edit propagate into unrelated execution paths. That becomes a supply chain problem when build steps trust reused snippets more than they trust policy enforcement. Current guidance from the NIST Cybersecurity Framework 2.0 emphasises governance, change control, and continuous monitoring, all of which are harder when configuration reuse hides effective behaviour.

In practice, many security teams encounter the issue only after a pipeline has already inherited an unsafe permission, secret reference, or artifact-signing exception rather than through intentional review of the shared YAML block.

How It Works in Practice

Anchors and aliases let one YAML node be defined once and reused elsewhere, which is efficient for pipeline templates, job matrices, and environment-specific overrides. The problem is that the effective configuration is assembled after parsing, so the human reviewer may only see a small override while the actual execution path inherits far more. In CI/CD, that can affect container image sources, script execution, cache paths, token exposure, or whether an approval gate is enforced before deployment.

From a supply chain perspective, the highest risk appears when anchors are used to share security-sensitive fields across jobs. A change to a base template can silently propagate into build, test, and release stages. That creates opportunities for:

• unexpected secret inheritance into jobs that do not need it
• weakening of signature validation or provenance checks in downstream stages
• accidental bypass of policy-as-code controls when an alias overwrites only part of a mapping
• deployment drift when protected branches and unprotected branches reference the same shared block

For control design, NHI governance is relevant because CI/CD pipelines often rely on non-human identities such as service accounts, tokens, and signing keys. The OWASP Non-Human Identity Top 10 is useful here because reused YAML can expand token scope or create hidden credential exposure across jobs. If the pipeline also handles regulated data or financial workflows, the FATF Recommendations remind teams that identity assurance and traceability are control expectations, not optional extras.

Best practice is to render or lint the fully resolved configuration before execution, compare it against policy baselines, and treat shared blocks as security-critical assets. These controls tend to break down in monorepos with many environment overlays because reused anchors multiply the blast radius while masking which job actually inherited the unsafe setting.

Common Variations and Edge Cases

Tighter pipeline governance often increases review overhead, requiring organisations to balance configuration reuse against visibility and approval cost. That tradeoff is especially sharp in large CI/CD estates where anchors are used to keep thousands of lines manageable.

Not every alias is risky. Reuse of harmless values, such as environment labels or non-sensitive defaults, is usually acceptable. The risk rises when the shared content controls authentication, artifact trust, release promotion, or secret injection. Current guidance suggests that teams should classify anchors by impact, with security-sensitive blocks handled like code dependencies rather than simple text reuse. There is no universal standard for this yet, so policy maturity varies by platform and release model.

Edge cases matter. Anchors can also obscure differences between development and production jobs, especially when one alias supplies the base and another adds a narrow override. That can make a production job inherit development-era exceptions. This is where NIST SP 800-53 Rev. 5 Security and Privacy Controls is useful for mapping change control, configuration management, and access enforcement to the pipeline itself.

Practitioners should also watch for tools that expand YAML differently, because parser behaviour, template engines, and platform-specific syntax can change what the alias actually resolves to. Best practice is evolving, but a consistent baseline is to inspect the final rendered pipeline, limit secret-bearing reuse, and require explicit approval for any shared block that affects signing, deployment, or credentials.

Related resources from NHI Mgmt Group

• Why do CI/CD tokens increase supply chain risk when they are over-scoped?
• Why do CI/CD service accounts increase supply chain risk?
• Why do package-manager bypasses increase supply-chain risk for CI/CD pipelines?
• Why do GitHub Actions workflows create supply chain risk for CI/CD credentials?