CI/CD Workflows: Is your Environment at Risk of a New Attack?

CI/CD (Continuous Integration/Continuous Deployment) pipelines automate the software build, test, and release process, but they also run with elevated privileges, store production secrets, and ingest untrusted code from external sources. Security researchers demonstrated that gaining contributor access to a major open-source project required nothing more than correcting a typo, after which a malicious pipeline workflow could persist on build infrastructure and exfiltrate authentication tokens. The recommended action: audit pipeline permissions, move secrets into dedicated secrets management, enforce code signing on all pipeline outputs, and treat build infrastructure as production-equivalent systems with the same access controls.

Quick Answer: Are CI/CD Environments at Risk of Attack?

Yes, and the attack surface is broader than most organizations realize. A CI/CD pipeline is not just a build tool: it runs with elevated permissions on build infrastructure, has access to code signing keys, production deployment credentials, and cloud API tokens, and is triggered by events such as pull requests that can be initiated by anyone with a minimum of repository access. The attacks are not theoretical: self-hosted runner compromise, dependency poisoning, secrets exposure through build logs, and malicious workflow injection have all been exploited in documented incidents affecting widely-used open-source projects and enterprise environments. Sonatype’s 2026 State of the Software Supply Chain Report found over 454,600 new malicious open-source packages in 2025, a 75% year-over-year increase, most targeting automated dependency resolution in build pipelines.

What Is CI/CD?

CI/CD stands for Continuous Integration and Continuous Deployment (or Continuous Delivery). It is an automated workflow that takes code from a developer’s commit through build, test, and deployment stages without requiring manual handoffs between steps.

Continuous Integration (CI) automates the process of merging code changes and running tests against them. Every commit to a shared repository triggers an automated build and test run, catching integration failures early rather than discovering them at release time. Continuous Deployment (CD) extends this by automatically deploying code that passes testing to production or staging environments, enabling organizations to release multiple times per day rather than on fixed release cycles.

Common CI/CD platforms include GitHub Actions, Jenkins, GitLab CI, CircleCI, and Buildkite. All of them share the same fundamental security challenge: to do their job, they need privileged access to build systems, deployment environments, signing keys, and production credentials.

Why CI/CD Pipelines Are a High-Value Attack Target

A successful attack on a CI/CD pipeline does not just compromise one application. It compromises the trust infrastructure that all downstream consumers depend on. If an attacker can inject code into a build pipeline, every artifact that pipeline produces is potentially malicious, and every user or organization that installs those artifacts receives the malicious code through a legitimate, trusted channel.

The PyTorch incident directly demonstrated this. PyTorch is a machine learning framework with approximately 21% market share in the ML space. When researchers attacked its CI/CD pipeline as part of a security research project, they demonstrated how wide the blast radius of a single pipeline compromise could reach: every project, company, and model that depends on PyTorch would potentially have been affected had the researchers been malicious rather than responsible.

CI/CD pipelines concentrate several properties that make them attractive targets. They run automated processes with elevated privileges that human operators do not continuously monitor. They ingest code and dependencies from external sources as part of their normal function. They store credentials that provide access to production systems. And they are often configured with permissive defaults designed for developer convenience rather than security.

CI/CD Threat Model: Attack Vectors and Controls

Attack vector	How it works	Real-world example	Primary control
Self-hosted runner compromise	Attacker gains contributor access, submits pull request with malicious workflow; runner executes it before merge approval due to default settings	Researchers demonstrated this against PyTorch’s GitHub Actions pipeline using self-hosted runners	Disable self-hosted runner access for fork pull requests; require manual approval before running workflows from external contributors
Dependency poisoning	Malicious package published to public registry (typosquatting, account compromise, or dependency confusion); CI pipeline downloads and executes it	Sonatype identified 454,600+ malicious open-source packages in 2025 (75% YoY increase)	Dependency pinning with hash verification; private package mirrors; Software Composition Analysis (SCA) in pipeline
Secrets exposure in build logs	Pipeline logs API keys, tokens, or credentials in plaintext during build steps; logs accessible to all repository collaborators	GitHub researchers identified 13 million API secrets exposed through public repositories in March 2024	Use platform secrets management; never echo secrets to stdout; scan build logs for credential patterns
Malicious workflow injection	Attacker modifies workflow YAML files in a branch or fork to add steps that exfiltrate secrets or modify build outputs	Similar pattern to the self-hosted runner attack; workflow files in forks are executed before review	Protect workflow files with branch protection rules; require code owner approval for workflow changes
Compromised third-party actions	CI/CD workflow references an external action that is later modified by a compromised maintainer account	Documented pattern in supply chain research; pinning by commit SHA rather than tag is the mitigation	Pin all third-party actions to specific commit SHAs; audit all external actions before use
Build infrastructure persistence	Malicious code executed by runner persists on the host machine, affecting future builds without requiring re-triggering the initial attack	Demonstrated in the GitHub Actions research: runners persist on the host and continue affecting builds	Ephemeral runners that are destroyed and recreated for each build; runner isolation using containers or VMs

How the Self-Hosted Runner Attack Works: Step by Step

Security researchers demonstrated a specific attack chain against GitHub Actions self-hosted runners that illustrates the structural vulnerability in default pipeline configurations. The attack proceeds as follows:

1. Achieve contributor status: the researchers gained contributor access to a major open-source project by correcting a typographical error in documentation. A typo fix is sufficient to receive contributor status on many large projects.
2. Submit a pull request with a malicious workflow: with contributor status, the attacker creates a fork and adds a malicious GitHub Actions workflow file. By default settings, a contributor’s pull request triggers the project’s CI/CD workflow, including access to the self-hosted runner, before the pull request is reviewed or approved.
3. Execute malicious code on the runner: the malicious workflow runs on the self-hosted runner, which operates on the host machine with elevated privileges. The runner cannot distinguish between a legitimate workflow and a malicious one because both are expressed in the same YAML format and submitted through the same pull request mechanism.
4. Log authentication tokens: the malicious workflow captures the authentication tokens available in the runner environment. These tokens provide full access to the repository, including the ability to push code, modify releases, access secrets, and trigger additional workflows.
5. Persist on the build machine: because runners persist on the host machine between builds, malicious code can remain active and affect future builds without requiring the attacker to trigger the attack again. This enables silent, ongoing compromise of all subsequent pipeline outputs.
6. Tamper with pipeline artifacts silently: with persistent access, the attacker can insert backdoors into build artifacts, modify dependency resolution, or exfiltrate signing keys, affecting all downstream consumers of the project’s releases.

The attack targeted a public repository, but similar vulnerabilities exist in private repositories where any employee or contractor with minimum repository access can trigger the same chain.

Access Controls: Locking Down Pipeline Permissions

• Disable fork pull request access to self-hosted runners: in GitHub Actions, the default setting allows fork pull requests to use self-hosted runners. This should be disabled for all repositories using self-hosted runners. Use GitHub-hosted ephemeral runners for pull request workflows from external contributors, reserving self-hosted runners for workflows that run only after merge.
• Require manual approval for external contributor workflows: configure the repository to require an authorized maintainer to approve workflow runs from new or external contributors before they execute. This adds a human gate between untrusted code submission and pipeline execution.
• Apply least-privilege permissions to pipeline tokens: GitHub Actions workflow tokens are granted permissions defined in the workflow file. Explicitly scope each workflow’s token permissions to only what that workflow requires (for example, read-only access to repository contents for a test workflow; write access only for a deployment workflow). Avoid using the default all-permissions token.
• Protect workflow YAML files with branch protection and code owners: require code owner approval for any modification to workflow files. This prevents an attacker who gains commit access to a feature branch from modifying the CI/CD configuration without a maintainer reviewing the change.
• Use ephemeral runners: configure runners to be destroyed and recreated as a clean environment for each build. This eliminates the persistence vector: malicious code executed in one build cannot affect future builds because the runner environment is replaced.

Secrets Management in CI/CD Pipelines

Secrets (API keys, deployment credentials, signing keys, database passwords, cloud access tokens) stored in CI/CD environments are the primary exfiltration target in pipeline attacks. Effective secrets management requires treating every secret as a potential breach target and minimizing both the number of secrets in the environment and the surface area of their exposure:

• Never hardcode secrets in source code or configuration files: hardcoded credentials are permanently exposed to anyone who can access the repository, including external contributors, forked repositories, and anyone who ever clones the project. Use platform secrets stores (GitHub Actions secrets, GitLab CI variables, Jenkins credentials) or dedicated solutions such as HashiCorp Vault to inject secrets at runtime only.
• Scope secrets to the minimum required pipeline step: a secret needed only by the deployment step should not be available during the build or test steps. Stage-scoped secrets reduce the window during which a compromised step can access a given credential.
• Rotate secrets on a defined schedule and immediately on suspected compromise: long-lived secrets that are never rotated are permanently compromised if exfiltrated. Define a rotation schedule for all pipeline secrets and automate rotation where possible.
• Scan build logs for credential patterns: pipeline steps that accidentally echo environment variables or print debug output may expose secrets in build logs. Use log scanning tools to detect and alert on credential patterns in pipeline output.
• Store code signing keys in an HSM, not in the pipeline environment: signing keys that are stored as files or environment variables in the build environment are exfiltrable. HSM as a Service stores signing keys in FIPS 140-3 validated hardware, performing signing operations inside the HSM so the private key never enters the pipeline environment.

Code Signing as a CI/CD Security Control

Code signing in a CI/CD pipeline serves two security functions. First, it provides artifact integrity verification: every binary, container image, or package produced by the pipeline is cryptographically signed, and downstream consumers can verify the signature to confirm the artifact is authentic and unmodified since the pipeline produced it. If an attacker compromises the build environment and modifies an artifact after signing, the signature verification fails at installation time.

Second, it provides build provenance attestation: the signing event records metadata about the build, including the pipeline stage, commit SHA, build timestamp, and signing identity. This creates an auditable record of where each release artifact came from, which is essential for supply chain security investigations and compliance audits.

Encryption Consulting’s CodeSign Secure integrates directly with GitHub Actions, Jenkins, and Azure DevOps pipelines. It performs all signing operations inside an HSM so private keys never enter the pipeline environment, applies role-based access control over which pipeline stages and users can trigger a signing event, and logs every signing action for the audit trail that both security teams and compliance frameworks require. For GitLab CI and other platforms, CodeSign Secure also provides integration paths that maintain the same HSM-backed key protection model regardless of the CI/CD platform in use.

Dependency Security and Software Supply Chain Controls

• Pin dependencies to specific versions and hash values: specifying an exact version number is insufficient because a malicious actor can publish a new package under the same version. Pin dependencies to cryptographic hash values (SHA-256 digests) so that the build fails if the downloaded package does not match the expected hash, regardless of version number.
• Use Software Composition Analysis (SCA) in the pipeline: SCA tools scan dependency trees for known vulnerabilities and malicious packages, comparing against databases of known-bad packages before they are installed. Integrate SCA as a required pipeline step that blocks builds when high-severity vulnerabilities are detected.
• Use private package mirrors for critical dependencies: a private mirror caches approved versions of packages that have been reviewed and validated. The pipeline resolves dependencies from the private mirror rather than directly from public registries, preventing typosquatting and dependency confusion attacks.
• Audit third-party CI/CD actions and plugins: CI/CD workflows that reference third-party actions are executing code from external maintainers with the same privileges as the workflow. Pin all external actions to specific commit SHAs rather than mutable tags or branches, and audit the code of each action before use.
• Maintain a Software Bill of Materials (SBOM): generate and publish an SBOM for every release artifact documenting all dependencies by name, version, and hash. An SBOM enables downstream consumers to assess their exposure when a vulnerability or malicious package is identified, and is increasingly required by government procurement requirements and frameworks like NIST SSDF.

Compliance Mapping: CI/CD Security Requirements

Framework	Relevant requirement	CI/CD implication
NIST SP 800-218 (SSDF)	Secure software development practices including secure build environments, artifact integrity, and dependency management	Requires organizations to protect build tools and environments, verify integrity of build artifacts, and manage third-party software components
SLSA (Supply Chain Levels for Software Artifacts)	Four levels of build provenance guarantees, from basic build process documentation (L1) to HSM-backed signing and hermetic builds (L3+)	Provides a roadmap for progressively hardening pipeline security; Level 2 requires signed provenance; Level 3 requires isolated, hardened build environments
PCI DSS v4.0 (Req. 6)	Protect web-facing applications and software development processes; Req. 6.3 requires security vulnerabilities to be identified and addressed	CI/CD pipelines producing software that processes cardholder data must implement secure development practices and vulnerability management
SOC 2 Type II	Trust Service Criteria for Security: logical access controls, change management, and monitoring	CI/CD access controls, approval workflows for code changes, and pipeline audit logs are evaluated as part of SOC 2 change management controls
HIPAA Security Rule	Technical safeguards for software accessing ePHI; audit controls and access management	CI/CD pipelines producing software that accesses ePHI must have access controls, audit logging, and artifact integrity controls

Limitations: What Pipeline Security Controls Cannot Do

• Code signing verifies integrity, not correctness: a signed artifact proves it came from the pipeline unmodified after signing. It does not prove the code the pipeline built is free of vulnerabilities or malicious logic. Code signing and application security testing are complementary, not substitutes.
• Secrets management does not prevent insider threats from authorized users: an authorized developer with legitimate access to pipeline secrets can still misuse them. Secrets management combined with access logging, least-privilege scoping, and secrets rotation reduces but does not eliminate insider risk.
• SCA tools depend on known-bad databases: Software Composition Analysis catches packages with known vulnerabilities or known malicious behavior. A novel malicious package published the same day it is ingested by a pipeline will not yet be in the SCA database. Defense in depth, including dependency pinning and hash verification, is required alongside SCA.
• Ephemeral runners reduce persistence risk but add infrastructure complexity: creating a new runner environment for every build eliminates the persistence attack vector but requires infrastructure automation and increases build times. The trade-off is appropriate for high-sensitivity pipelines but may not be practical for all environments.

How Encryption Consulting Can Help

• CodeSign Secure: CodeSign Secure integrates code signing directly into CI/CD pipelines with HSM-backed key storage, role-based signing access control, mandatory timestamping, and complete audit logging. It supports GitHub Actions, Jenkins, Azure DevOps, GitLab CI, and other platforms, maintaining the same key protection model across all pipeline integrations.
• CertSecure Manager: CertSecure Manager manages the certificate lifecycle for certificates used in pipeline authentication, mTLS between pipeline services, and code signing, including automated renewal to prevent certificate expiry from disrupting pipeline operations.
• HSM as a Service: HSM as a Service provides FIPS 140-3 validated hardware key storage for code signing keys and pipeline authentication credentials, ensuring that even a full compromise of the build server cannot extract the private keys that sign pipeline outputs.
• Encryption Advisory Services: our Encryption Advisory Services assess pipeline security architecture, identify access control gaps and secrets management weaknesses, and build a remediation roadmap covering authentication, artifact integrity, dependency security, and compliance alignment.

Conclusion

CI/CD pipelines are not a peripheral part of the software supply chain. They are the most privileged automated system in most organizations: they build, sign, and deploy the software that users and customers trust. A compromised pipeline produces compromised software through a trusted channel, and the downstream blast radius, as the PyTorch research demonstrated, can encompass an entire industry ecosystem.

The controls that reduce pipeline risk are well understood: disable default runner access for external contributor workflows, enforce least-privilege permissions on pipeline tokens, move secrets into dedicated management systems, sign all pipeline artifacts with HSM-backed keys, pin dependencies to hash-verified versions, and audit all third-party pipeline components. These are not theoretical best practices: they are the specific gaps that documented attacks have exploited.

If your organization uses CI/CD and needs a security assessment of your pipeline architecture, access controls, and artifact integrity controls, contact Encryption Consulting. Our team can evaluate your current configuration, identify the highest-priority gaps, and integrate code signing and cryptographic controls that protect your pipeline without slowing your release velocity.

Frequently Asked Questions

What is a CI/CD pipeline and why is it a security risk?

A CI/CD pipeline is an automated build, test, and deploy workflow that runs with elevated privileges, stores production secrets, and ingests external code through dependencies. It is a security risk because a compromise produces malicious builds delivered to downstream users through a trusted channel, with a blast radius that can extend to every consumer of the compromised project.

What is a self-hosted runner attack on GitHub Actions?

By default settings, a contributor’s pull request triggers the self-hosted runner before the PR is reviewed. An attacker who achieves contributor status (demonstrated to require only a typo correction) can submit a pull request with a malicious workflow that executes on the runner, captures authentication tokens, and persists on the build machine to affect all subsequent builds.

What is dependency poisoning in a CI/CD context?

Dependency poisoning occurs when a malicious package is published to a public registry under a name that the build pipeline will download, through typosquatting, maintainer account compromise, or dependency confusion. The pipeline executes the malicious package as part of its normal build process. Sonatype identified 454,600+ malicious packages in 2025 alone.

How does code signing protect a CI/CD pipeline?

Code signing provides artifact integrity verification (downstream consumers can confirm the artifact came from the pipeline unmodified) and provenance attestation (an auditable record of what pipeline stage produced the artifact, at what commit). Keys must be stored in an HSM rather than in the build environment to prevent key exfiltration in a pipeline compromise.

What is the difference between secrets management and hardcoded credentials?

Hardcoded credentials are embedded in source code or config files and permanently exposed to anyone with repository access. Secrets management stores credentials in an encrypted secrets store and injects them at runtime only to the authorized pipeline step that requires them, so they never appear in source code, build logs, or pipeline artifacts.

What compliance frameworks address CI/CD pipeline security?

NIST SP 800-218 (SSDF) requires secure build environments and artifact integrity. SLSA defines four levels of build provenance guarantees. PCI DSS v4.0 Requirement 6 requires secure software development processes. SOC 2 Type II evaluates CI/CD access controls and change management. HIPAA requires access controls and audit logging for pipelines producing software that accesses ePHI.