Your CI/CD pipeline can deploy to production. That makes it one of the highest-privilege systems you run. Most teams treat it like a build server.
A pipeline with production deployment capability has the same blast radius as a compromised administrator account. In many environments it has more, because it can modify infrastructure, update access controls, and rotate credentials automatically, all without requiring human interaction. Five attack surfaces in a modern Azure DevOps pipeline, from the one that gets exploited most often to the one almost nobody thinks about:
Full DevSecOps security model: service connection scoping with OIDC federation, SAST and IaC scanning gates, artifact signing with Key Vault, SBOM generation, and the branch protection settings that satisfy both security and DORA change management.
Why the Pipeline Is a Priority Target
A pipeline that can deploy to production has write access to production infrastructure. A compromised pipeline can modify resources, install backdoors, change access controls, or exfiltrate data . All under the cover of a legitimate deployment. The pipeline’s credentials are often more powerful than any individual user’s credentials because the pipeline was provisioned with broad permissions to “make deployments work.”
Attack Surface 1: Secrets in YAML (Most Common)
Connection strings, API keys, and service principal credentials committed to pipeline YAML files or repository configuration files. This is the most common finding. It happens because storing a secret in a variable group or Key Vault reference requires more steps than just pasting it into the YAML.
Mitigation: enable secret scanning on every repository (GitHub Advanced Security or Azure DevOps credential scanning). Use Azure DevOps secure variable groups with Key Vault backing. For service authentication, use Workload Identity Federation , the pipeline authenticates to Entra ID using an OIDC token and receives a short-lived access token. No credential is stored anywhere.
Attack Surface 2: Over-Scoped Service Connections
Service connections in Azure DevOps hold the credentials or identity used to deploy to Azure. They are frequently provisioned at the subscription level with Contributor because that was the easiest way to “make it work.” A compromised service connection then gives an attacker Contributor across the entire subscription.
Mitigation: scope service connections to the minimum required resource. A service connection for deploying to a specific resource group needs Contributor on that resource group, not the subscription. Review and tighten all service connection scopes as a quarterly practice.
Attack Surface 3: Pull Request Execution
Pipelines configured to run on pull requests from forked repositories execute untrusted code with the pipeline’s credentials. An external contributor submits a PR with a malicious pipeline modification. The pipeline runs, exfiltrates the pipeline secrets, and calls the PR legitimate.
Mitigation: require approval from a maintainer before pipeline execution on PRs from forked repositories. Review which pipeline variables are accessible in PR contexts versus push contexts. Use separate, lower-privilege service connections for PR validation pipelines.
Attack Surface 4: Dependency Poisoning
Open-source packages used in the build are updated with malicious versions by compromised maintainers or through namespace confusion attacks. The malicious code executes during the build with pipeline credentials.
Mitigation: pin all dependencies to specific versions with hash verification. Use Azure Artifacts with upstream caching to create a controlled supply of packages. Enable Software Composition Analysis (Defender for DevOps) to scan for known-malicious package versions before they are included in the build.
Attack Surface 5: Artifact Tampering
An artifact is produced by the build pipeline and stored in an artifact registry. Between the build and the deployment, the artifact is replaced or modified. The deployment pipeline deploys the tampered artifact to production.
Mitigation: sign build artifacts using a key stored in Azure Key Vault. The deployment pipeline verifies the signature before deploying. A signature mismatch fails the deployment. This creates a cryptographic chain of custody from the trusted build pipeline to the production deployment.
OIDC Federation — No Stored Credentials
Workload Identity Federation eliminates stored credentials from the deployment pipeline entirely. Azure DevOps requests an OIDC token from its own identity provider. It presents this token to Entra ID, which exchanges it for an Azure access token. No client secret, no certificate, no managed identity, the credential exists only for the duration of the pipeline run and cannot be stolen from storage because it was never stored.
For more information, visit these links:
https://learn.microsoft.com/en-us/azure/security/develop/secure-dev-overview
#DevSecOps #AzureDevOps #PipelineSecurity #CICD #SupplyChain
Be the first to comment
Leave a Comment
💡 Comments are reviewed before publishing.