What breaks when security teams review only the source YAML instead of the expanded CI/CD configuration?

Reviewing only the source file can miss inherited permissions, unsafe scripts, and other defaults pulled in through aliases. That blind spot makes it easier for a malicious or careless change in a shared anchor to propagate across pipelines unnoticed. The result is weaker assurance, poor stage isolation, and security decisions made on incomplete configuration context.

Why This Matters for Security Teams

Source YAML is often treated as the system of record, but the executable reality of a pipeline is the fully rendered configuration after anchors, aliases, templates, includes, and variable expansion are resolved. That distinction matters because policy review, segregation of duties, and approval gates all depend on what actually runs, not what is most readable in version control. NIST guidance on secure software development emphasizes verifying the build and deployment environment, not just the authored artifact, and the same logic applies to CI/CD config review. See NIST Secure Software Development resources for the broader control context.

When teams inspect only the source file, they can miss inherited permissions, unsafe shell steps, hidden environment variables, or stage-wide defaults introduced through shared components. That creates a false sense of assurance, especially in repositories that use reusable pipeline patterns across many services. The risk is not limited to obvious tampering; a legitimate edit to a shared anchor can alter dozens of pipelines at once, including ones that appear unchanged in code review. In practice, many security teams encounter the issue only after a build agent has already executed with broader privileges than the source YAML seemed to permit, rather than through intentional configuration scrutiny.

How It Works in Practice

A CI/CD parser usually combines several layers before execution: the main source file, imported templates, inherited anchors, default jobs, environment-specific overrides, and runtime variables. The security implication is simple: the review target should be the compiled or expanded pipeline graph, not only the author-facing YAML. Best practice is evolving here, but current guidance suggests treating the rendered configuration as the evidence of record for approvals, change control, and exception handling.

Practitioners should validate the pipeline at three levels:

• Structural expansion: confirm what each job inherits from shared anchors, templates, and includes.

• Privilege scope: inspect runner identity, secret injection, service connections, and token permissions after expansion.

• Execution behavior: review scripts, conditionals, and artifact handoffs as they will run in each stage and branch context.

For threat modeling and detection, it helps to map common abuse patterns to MITRE ATT&CK, especially where build systems become a pathway to credential theft, persistence, or deployment tampering. Supply chain integrity guidance from CISA supply chain resources is also relevant when pipeline reuse spans multiple repos or business units. The operational control is not just static review; teams should compare declared intent against rendered output and fail closed when expansion introduces privileges that were not explicitly approved.

These controls tend to break down when organisations allow opaque third-party pipeline templates, because reviewers cannot reliably see which defaults are inherited at execution time.

Common Variations and Edge Cases

Tighter pipeline inspection often increases review effort and tooling complexity, requiring organisations to balance release speed against assurance. That tradeoff is especially visible in monorepos, platform engineering setups, and highly parameterized delivery systems, where a single template may serve many products and environments. In those cases, the right question is not whether the source YAML is valid, but whether the expanded configuration matches the approved trust boundary.

There is no universal standard for every CI/CD platform, so teams should adapt the control to the implementation pattern. For example, some systems render config at build time, others at deploy time, and some combine repository YAML with policy-as-code and hosted defaults. Security review should capture the exact expansion point, because that is where inherited permissions and conditional execution become visible. Where a shared anchor controls secrets, deployment targets, or runner selection, change review should treat that anchor as a high-impact dependency rather than a harmless refactor.

Where financial controls or identity assurance are in scope, the question can intersect with FATF Recommendations — AML and KYC Framework only indirectly, through governance expectations for trusted change and accountability. The practical lesson is that source-only review is weakest in environments that rely on layered composition, because the meaningful security decision sits in the rendered output, not the authored fragment.

Related resources from NHI Mgmt Group

• How should security teams govern open source dependencies in CI/CD pipelines?
• What breaks when CI/CD security depends on workflow files instead of the runner image?
• What breaks when teams rely only on code review and CI to confirm a security patch worked?
• How should security teams govern machine credentials across cloud and CI/CD environments?