CI/CD pipeline secrets are leaking. This is how.

The CI/CD pipeline is the most trusted path in a software organization. It takes code from a developer’s laptop to production without a human reviewing every step. Attackers have understood this longer than most security teams have. A credential that lives in a pipeline environment variable, a build log, or a hardcoded configuration file is not just a credential. It is a key to production infrastructure that can be retrieved by anyone who can read the repository, the log output, or the artifact.

IBM’s 2026 X-Force Threat Intelligence Index documents a nearly 4x increase in large supply chain or third-party compromises since 2020, driven primarily by attackers exploiting trust relationships and CI/CD automation across development workflows and SaaS integrations. X-Force also notes that AI-powered coding tools are occasionally introducing unvetted code, increasing pressure on pipelines and supply chain integrity. The attack surface has expanded while the average developer’s mental model of where credentials can leak has not kept pace.

This post maps the four primary ways secrets escape CI/CD pipelines, the controls that close each vector, and the pipeline architecture decisions that determine whether a supply chain compromise stays contained or cascades across everything the pipeline touches.

How the Microsoft Cloud Security Benchmark categorizes CI/CD attack vectors

Microsoft’s Cloud Security Benchmark v2 DevOps Security guidance identifies four primary CI/CD attack vectors. Understanding the taxonomy before addressing any individual control prevents the partial remediation trap, fixing one vector while leaving the others open.

• Compromised CI/CD pipelines: attackers gain access through stolen credentials, exploited vulnerabilities, or insider access, enabling code injection, artifact tampering, or deployment manipulation that affects all downstream consumers. This is the supply chain attack pattern IBM X-Force identifies as accelerating
• Exposed secrets in build logs and artifacts: hardcoded credentials, API keys, certificates, and connection strings leak through pipeline logs, error messages, or compiled artifacts, providing attackers with direct access to production environments. This is the most common initial access vector because it requires no exploitation, just reading a log
• Unauthorized pipeline modifications: absence of change control and approval workflows allows malicious actors to modify pipeline definitions, inject malicious build steps, or alter deployment configurations without detection. The typosquat and NPM token attack pattern Microsoft documented in the Trivy compromise works exactly this way
• Insufficient access controls: overly permissive role assignments and lack of separation of duties enable lateral movement, privilege escalation, and persistent access within DevOps infrastructure. A pipeline token with write access to production that only needs read access to a test environment is a privilege escalation waiting to happen

Where secrets actually escape: the four most common leakage paths

Hardcoded credentials in source code and configuration files

• The most basic and most persistent problem. AWS access keys, database connection strings, API tokens, and OAuth secrets end up in .env files, configuration files, and occasionally in application source code committed to version control
• Git history is permanent. A credential committed and deleted is still readable in the git log. Rotation is required, not just deletion
• Secrets scanning tools, GitHub’s native secret scanning, TruffleHog, and Gitleaks, run at commit time and block pushes that contain known credential patterns. Microsoft’s CI/CD pipeline guide documents this as a baseline pipeline security control alongside SAST and dependency scanning

Secrets in build logs

• Environment variables printed to stdout during debugging, error messages that include connection string fragments, and verbose logging that captures authentication headers are the most common log-based leakage patterns

Over-permissive pipeline tokens

• GitHub Actions GITHUB_TOKEN, AWS IAM roles assumed during pipeline execution, and cloud provider service accounts are the primary runtime credentials a CI/CD pipeline uses. When these are provisioned with broader permissions than required for the specific pipeline step, a pipeline compromise grants attacker access to everything the token can reach
• Microsoft’s guidance documents this as insufficient access controls enabling lateral movement. The principle of least privilege applied to pipeline tokens means: the token that runs tests should not be able to push to production. The token that builds Docker images should not be able to modify IAM policies
• GitHub Actions supports per-job permission scoping, allowing the workflow file to specify the minimum permissions each job requires. Most pipelines do not use this feature, running all jobs with the default token permissions

Supply chain attacks via dependencies and pipeline actions

• Microsoft’s Trivy supply chain guidance documents the attack pattern directly: stolen NPM tokens are used to download legitimate packages, inject a malicious preinstall hook, bump the patch version, and republish, turning each compromise into a new supply chain vector. Teams that pin dependencies to specific versions and verify checksums break this attack chain
• Third-party GitHub Actions are a parallel attack surface. An action that runs in a workflow has access to the same secrets and permissions as the pipeline. Actions should be pinned to a specific commit SHA rather than a tag, because tags are mutable and can be updated to point to malicious code
• Dependency scanning and software composition analysis tools flag known vulnerable dependencies at build time. These should run on every pull request, not only in scheduled scans

The controls that close these vectors

GitHub Actions security: specific controls

GitHub Actions is the most widely deployed CI/CD platform and the most frequently targeted. The following controls apply specifically to GitHub Actions but have equivalents in Jenkins, CircleCI, GitLab CI, and other platforms.

• Use environments with required reviewers: GitHub Actions environments can require human approval before a job runs. Production deployments should always require at least one reviewer who did not author the change
• Scope GITHUB_TOKEN permissions: the default GITHUB_TOKEN has broad permissions. Workflow files should declare the minimum permissions required using the permissions key. Most workflows need only read access to the repository; only release workflows need write access
• Pin actions to commit SHAs: actions/checkout@v4 is a mutable tag. actions/checkout@abc123 (a specific commit SHA) is immutable. Pinning to SHAs prevents a compromised action publisher from updating a tag to point to malicious code
• Avoid storing secrets in workflow files: workflow files are readable by anyone with repository access. Secrets should be stored in the GitHub Secrets store and referenced as environment variables, never embedded in the workflow YAML
• Use short-lived credentials where possible: OIDC (OpenID Connect) allows GitHub Actions to obtain cloud provider credentials (AWS, Azure, GCP) for each job without storing long-lived access keys in the secrets store. This eliminates the entire class of leaked long-lived credential attacks

WebOsmotic’s DevSecOps engineering practice implements these controls as part of the initial CI/CD pipeline design for clients in fintech, healthcare, and SaaS. Secrets management architecture is scoped before the first pipeline is written, not added as a remediation after a security review.

Frequently asked questions

What are the most common ways secrets leak from CI/CD pipelines?

Microsoft’s Cloud Security Benchmark identifies four primary vectors: exposed secrets in build logs and artifacts, compromised pipeline credentials, unauthorized pipeline modifications, and insufficient access controls. The most common initial access point documented by security researchers is hardcoded credentials in source code or configuration files committed to version control. Git history is permanent, a credential committed and deleted is still accessible in the git log. The second most common vector is secrets printed to build log output through verbose logging or debugging statements. IBM X-Force 2026 documents that attackers are exploiting these basic security gaps at dramatically higher rates, now accelerated by AI tools that identify weaknesses faster.

What is a CI/CD supply chain attack?

A CI/CD supply chain attack compromises the build or deployment pipeline rather than the application itself, allowing attackers to inject malicious code or steal credentials that affect all downstream consumers of the pipeline’s output. IBM X-Force 2026 documents a nearly 4x increase in large supply chain or third-party compromises since 2020, driven by attackers exploiting trust relationships in CI/CD automation. Microsoft’s analysis of the Trivy compromise documents the specific pattern: stolen NPM tokens are used to inject malicious preinstall hooks into legitimate packages, which republish with bumped version numbers. Teams that pin dependencies to commit SHAs and verify checksums break this attack chain.

What is secrets scanning and which tools do it?

Secrets scanning tools analyze code commits, pull requests, and repository history for known credential patterns such as AWS access key formats, API key prefixes, private key file formats, and connection string templates. GitHub’s native secret scanning runs on every push to a GitHub repository and can be configured to block pushes that contain detected patterns. TruffleHog and Gitleaks are open-source alternatives that can be integrated as pre-commit hooks or pipeline stages. Microsoft’s CI/CD pipeline guide documents secret scanning as a baseline security control alongside SAST and dependency scanning. These tools reduce the likelihood of credentials reaching version control, but they require configuration, they do not block all secrets by default.

How should GitHub Actions tokens be secured?

GitHub Actions GITHUB_TOKEN permissions should be scoped to the minimum required for each workflow using the permissions key in the workflow YAML. The default token permissions are broader than most workflows require. Per-job permission declarations reduce blast radius when a workflow is compromised. Third-party actions should be pinned to specific commit SHAs rather than mutable tags. Production deployments should use GitHub Environments with required reviewers. Cloud provider credentials should use OIDC short-lived tokens rather than long-lived access keys stored in the secrets store, OIDC eliminates the entire class of leaked long-lived credential attacks for AWS, Azure, and GCP.

What is the principle of least privilege in CI/CD pipelines?

Least privilege in CI/CD means that every pipeline token, service account, and IAM role is provisioned with only the permissions required for its specific pipeline stage, no more. The token that runs unit tests should not be able to push to a container registry. The token that builds images should not be able to modify production infrastructure. Microsoft’s Cloud Security Benchmark identifies over-permissive role assignments as one of the four primary CI/CD attack vectors, specifically because they enable lateral movement and privilege escalation when a pipeline step is compromised. Applying least privilege to pipeline tokens reduces the blast radius of a compromise from all infrastructure the pipeline can reach to only the infrastructure the compromised step requires.

How does WebOsmotic approach CI/CD security?

WebOsmotic designs the secrets management architecture before the first pipeline is written, as part of the initial infrastructure design phase. This includes: selecting the secrets store (AWS Secrets Manager, HashiCorp Vault, or platform-native), configuring secrets scanning as a pre-commit control, designing per-job token permissions for GitHub Actions or equivalent, implementing environment isolation between dev, test, and production, and documenting the dependency pinning and SCA scanning requirements. For fintech and healthcare clients, the pipeline security architecture is included in the compliance documentation alongside application-level security controls.