CI/CD Manifest Validation

Expanded Definition

CI/CD manifest validation is the security review of pipeline-as-code before execution, focusing on what the manifest is allowed to trigger, which runners it can reach, which secrets it can inherit, and whether referenced actions, images, or scripts are pinned and trustworthy. In NHI and agentic delivery systems, the manifest often becomes the first policy boundary for automated identity use, because it controls how build jobs assume privileges and how toolchains obtain credentials. Guidance varies across vendors on how much validation should happen at commit time versus merge time versus runtime, but the core objective is consistent: stop unsafe automation before it becomes an execution path. Standards bodies do not yet define one universal manifest-validation model, so teams typically map the practice to broader governance controls such as NIST Cybersecurity Framework 2.0 and internal least-privilege policy. The most common misapplication is treating a syntax-only linter as security validation, which occurs when the pipeline file parses correctly but still grants excessive permissions or executes unreviewed third-party code.

Examples and Use Cases

Implementing CI/CD manifest validation rigorously often introduces friction for developers, because stronger checks can block fast merges and require explicit approval for changes that used to be automatic, so organisations must weigh delivery speed against reduced supply chain risk.

• Rejecting a GitHub Actions workflow that uses wildcard permissions and unpinned third-party actions, then requiring exact version pinning before merge.
• Flagging a build manifest that injects secrets into environment variables, a pattern linked to real-world leakage in the NHIMG Guide to the Secret Sprawl Challenge.
• Blocking a pipeline change that allows pull request code from forks to run with write access to release artifacts, which could expose signing identities or deploy keys.
• Scanning workflow files for shell interpolation that executes AI-generated content, then requiring human approval when an agent modifies the manifest.
• Investigating compromised pipeline definitions after incidents such as the Reviewdog GitHub Action supply chain attack, where trusted automation became the attack surface.

Many teams also compare manifest checks with supply chain guidance from the Secure Software Development Framework and the Supply-chain Levels for Software Artifacts model, especially when the manifest determines how build provenance is generated.

Why It Matters in NHI Security

CI/CD manifest validation matters because pipeline definitions increasingly decide which non-human identities are trusted to sign code, fetch secrets, promote artifacts, and deploy to production. When manifests are not validated, an attacker or overconfident AI assistant can introduce unsafe triggers, broaden token scope, or swap a pinned dependency for a mutable one, turning ordinary automation into credential theft or unauthorized release. NHIMG’s CI/CD pipeline exploitation case study shows how quickly a build system can become the entry point for lateral movement when controls are missing. This is especially important now that GitGuardian reported 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, underscoring that runners themselves are high-value targets. Organisational exposure often goes unnoticed until a pipeline is already modified, at which point manifest validation becomes operationally unavoidable to determine what was approved, what was executed, and which identities were abused.

Related resources from NHI Mgmt Group

• What breaks when mapping validation is missing from CI/CD pipelines?
• How should security teams implement dependency validation for npm installs in CI/CD pipelines?
• How should security teams implement repository origin validation in CI/CD pipelines?
• How should security teams implement redundancy and validation to reduce single points of failure in CI/CD pipelines?