Design pipeline-as-code standards
Implementation Effort: Medium – Moving pipelines to version-controlled YAML, applying branch policies and CODEOWNERS, and optionally disabling Classic pipelines takes coordinated work across teams.
User Impact: Low – Pipeline authors and administrators manage the YAML and policies; end users are not affected.
Lifecycle Stage: Build
Overview
Define all CI/CD pipelines as version-controlled YAML so pipeline changes follow the same review, approval, and audit processes as application code. This task addresses OWASP CICD-SEC-1 (Insufficient Flow Control) by establishing version-controlled pipeline definitions.
Pipeline-as-code means defining CI/CD pipelines in version-controlled YAML files that live alongside your application code. In Azure DevOps, use YAML pipelines instead of Classic build and release definitions. In GitHub, define workflows as YAML files in the repository's .github/workflows directory. Every pipeline change is then captured in the same commit history as the application and is subject to the same branch policies, pull request reviews, and approval workflows.
Pipelines configured through a UI present a significant security and governance gap. Changes to Classic pipelines in Azure DevOps are logged in audit streams, but they are not peer reviewed, cannot be branched or diffed, and cannot be rolled back through standard source control operations. A single administrator can modify a production deployment pipeline — adding a step that exfiltrates secrets, disabling a security scan, or changing the deployment target — without any other team member reviewing or approving the change.
This lack of change control makes UI-configured pipelines an attractive target for threat actors who compromise a DevOps administrator account, because modifications to the pipeline are less visible than modifications to application code.
Defining pipelines as YAML improves governance because pipeline changes can be diffed, reviewed, and traced to a specific identity and pull request. Organizations should also consider disabling the creation of Classic pipelines in Azure DevOps to prevent teams from bypassing pipeline-as-code standards. On GitHub, protect workflow files using CODEOWNERS for .github/workflows/**. In Azure Repos, use branch policies with required reviewers and path filters targeting your pipeline YAML paths so security or platform reviewers must approve pipeline-as-code changes.
Pipeline-as-code makes unauthorized or risky changes easier to detect because every modification is tied to a commit, reviewer set, and pull request record. It also gives teams a practical rollback path and a consistent way to apply policy to pipeline changes. Subjecting pipeline changes to the same review as application code applies Verify explicitly, and treating every modification as something to be diffed, reviewed, and attributed reflects Assume breach.