YAML Pipeline Definition

What a YAML pipeline definition does

A YAML pipeline definition is the machine-readable instruction set for a delivery pipeline. It tells the CI/CD platform what to run, in what order, under which conditions, and which build, test, release, or deployment steps belong in each stage.

Because it is code-like configuration, the file is both operationally important and security-sensitive. Small changes can alter execution paths, environment selection, artifact handling, or the way credentials are made available during the pipeline run.

Why YAML pipeline definitions matter in secure delivery

Pipeline definitions are often the place where security checks are added or removed, so they shape whether scanning, signing, dependency checks, and approval gates happen reliably. They also define the trust boundary between source control, build systems, deployment environments, and any secrets the pipeline can access.

In practice, the file becomes part of the delivery control plane. If a pipeline definition is weakly reviewed or broadly editable, an attacker who can change it may redirect builds, exfiltrate secrets, or weaken verification steps before release.

Common elements inside the definition

Most YAML pipeline definitions include triggers, stages, jobs, tasks, variables, and environment-specific steps. They may also reference templates or reusable fragments, which helps standardise delivery but can make change impact broader if a shared template is modified.

Security-relevant content often appears here too, such as secret references, service connection names, token handling, artifact publication, and scan actions. That makes the file a configuration object, but also a governance point for build integrity and environment access.

Security implications and failure modes

Because YAML pipeline definitions control what runs in the CI/CD system, they can be abused to insert malicious steps, weaken approvals, or expose sensitive values during execution. This is why pipeline security is closely tied to repository permissions, review discipline, and artifact provenance.

Pipeline content should be treated as trusted only to the extent that the repository, templates, and referenced dependencies are trusted. The best-known failures are not syntax errors, but privilege expansion, secret exposure, and supply-chain compromise through build logic.

Security controls for this layer often focus on provenance and build integrity, which is why supply-chain guidance such as SLSA is relevant when pipeline definitions shape how software is built and verified.

These risks are not theoretical in CI/CD environments. Shai Hulud npm malware campaign, Reviewdog GitHub Action supply chain attack, and CI/CD pipeline exploitation case study all illustrate how delivery logic, exposed secrets, and pipeline trust can become an attack path.

Practitioner Guidance

Why practitioners should care: The pipeline definition is not just build plumbing, it is a security control surface. Treat changes to it as production-sensitive because they can alter who can execute code, what checks run, and where secrets or artifacts flow.

Governance implication: Restrict who can edit pipeline files, require review for changes that touch execution, secrets, or deployment steps, and keep reusable templates under the same change-control discipline as application code. A pipeline definition should be governed like an operational policy document, not a convenience file.

Practitioner takeaway: The safest pipeline is the one whose YAML is explicit, tightly reviewed, and narrow in what it can reach. If the file can deploy, sign, or read secrets, it deserves the same scrutiny as the systems it controls.

Related resources from NHI Mgmt Group

• CI/CD Pipeline
• How do I implement secrets scanning in a CI/CD pipeline?
• When should organisations treat a pipeline compromise as a privileged access incident?
• When does a CI/CD pipeline become a security risk?