In March 2025, a GitHub Action used by more than 23,000 repositories — tj-actions/changed-files — was compromised and quietly began dumping CI/CD secrets into public build logs. Weeks earlier, attackers had already used a similar trick to poison reviewdog/action-setup. Neither incident touched a firewall, a WAF, or a cloud misconfiguration. Both went straight through the pipeline that builds, tests, and ships code. That is the uncomfortable truth about modern software delivery: the CI/CD pipeline now holds more privileged access — to source code, cloud credentials, signing keys, and production environments — than almost any other system in the company, yet it is frequently the least monitored. This post breaks down what a CI/CD pipeline actually is, why it has become the top target for supply chain attackers, how platforms like Prisma Cloud approach the problem, and what real pipeline security requires.
What Is a CI/CD Pipeline?
A CI/CD pipeline is the automated sequence that takes a code commit from a developer's laptop to a running production system. "CI" (continuous integration) covers the steps where code is merged, compiled, and tested — typically triggered by a git push or pull request. "CD" (continuous delivery/deployment) covers everything after: packaging artifacts, scanning them, and pushing them to staging or production. A typical pipeline in tools like GitHub Actions, GitLab CI, Jenkins, or CircleCI runs through five to eight stages — checkout, dependency install, build, test, package, scan, and deploy — each executed by a runner that pulls in third-party actions, plugins, or container images. A single build of a mid-sized Node.js service can pull in over 1,000 transitive npm packages and a dozen third-party GitHub Actions, each one a potential entry point. The pipeline itself typically holds long-lived credentials: cloud IAM keys, container registry tokens, code-signing certificates, and database connection strings, often stored as CI/CD "secrets" that are available to every job that runs.
Why Does CI/CD Security Matter So Much Right Now?
CI/CD security matters because pipelines have quietly become the highest-leverage target in the software supply chain, and attackers know it. Compromising a single pipeline can propagate malicious code into every downstream customer automatically — this is exactly what happened in the December 2020 SolarWinds Orion attack, where a modified build process (not the source repository) injected the SUNBURST backdoor into signed updates shipped to roughly 18,000 organizations. In April 2021, attackers exploited a misconfigured Codecov Bash Uploader script, live for over two months, to exfiltrate CI environment variables and secrets from thousands of customer pipelines. In January 2023, CircleCI disclosed a full platform breach that forced every customer to rotate all stored secrets, tokens, and SSH keys — an incident that took the industry weeks to fully remediate. Gartner has estimated that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, up threefold from 2021, and pipeline compromise is consistently the fastest-growing vector because a single injected build step scales to every artifact the pipeline ever produces.
What Are the Biggest CI/CD Pipeline Security Risks?
The biggest risks are hardcoded secrets, poisoned dependencies, and overly permissive runner access, in that order of frequency. GitGuardian's 2024 State of Secrets Sprawl report found over 12.7 million hardcoded secrets exposed in public GitHub commits in 2023 alone, a 28% year-over-year increase, and CI/CD configuration files are among the most common places they leak from. Dependency and action poisoning is close behind: the March 2025 tj-actions/changed-files compromise and the earlier 2022 "PyPI typosquatting" waves both worked by getting a trusted-looking package or action to execute attacker code inside the build. Third, misconfigured runner permissions turn a minor compromise into a major one — self-hosted runners with broad cloud IAM roles, or GitHub Actions workflows granted write access to repository contents by default, let an attacker pivot from "ran a malicious test" to "pushed a signed release" in a single step. Finally, unsigned or unverified build artifacts mean that even if the source code is clean, nothing proves the binary that ships matches it — the exact gap the SLSA (Supply-chain Levels for Software Artifacts) framework, now at v1.0 under OpenSSF, was built to close.
How Does Prisma Cloud Approach CI/CD Security?
Prisma Cloud approaches CI/CD security primarily as an extension of its cloud-native application protection platform (CNAPP), scanning IaC templates, container images, and pipeline configurations for misconfigurations before they reach runtime. Its strength is breadth: it correlates a pipeline finding with the cloud resource it eventually deploys to, giving security teams a single view from commit to cloud. In practice, this means Prisma Cloud is strongest at catching known misconfiguration patterns — an S3 bucket set to public, a container running as root, an IAM policy with wildcard permissions — because that logic reuses the same policy engine built for cloud posture management (CSPM). Where teams often need to supplement Prisma Cloud is pipeline-native behavior: detecting anomalous runner activity in real time, verifying build provenance end-to-end, and catching secrets or dependency tampering the moment they occur in a running job rather than on the next scheduled scan. For organizations whose primary exposure is inside the pipeline itself — not just what the pipeline deploys — that gap matters, since a scan cadence of hours is too slow against an attack that exfiltrates secrets in the seconds a job is running.
What Does a Secure CI/CD Pipeline Actually Look Like?
A secure CI/CD pipeline enforces least privilege, verifies provenance, and treats every job as untrusted until proven otherwise. Concretely, that means short-lived, scoped credentials issued per job (OIDC federation instead of long-lived static keys) so a leaked token expires in minutes, not indefinitely. It means pinning third-party GitHub Actions and dependencies to a specific commit SHA rather than a mutable tag like @v4, which is the single control that would have blocked both the tj-actions and reviewdog incidents in 2025. It means generating and verifying SLSA provenance or Sigstore/cosign signatures on every build artifact, so a deployment step can cryptographically confirm the binary came from the expected pipeline run and source commit. And it means continuously monitoring the pipeline itself — build logs, runner network egress, secret access patterns — for the kind of anomaly that signals compromise, not just scanning the code that goes in.
How Safeguard Helps
Safeguard was built for exactly the gap that broad CSPM-first platforms like Prisma Cloud leave open: securing the pipeline as its own attack surface, not just as a stepping stone to the cloud. Safeguard continuously monitors CI/CD workflows across GitHub Actions, GitLab CI, and Jenkins for the specific patterns behind real incidents — unpinned third-party actions, secrets exposed in build logs, unexpected outbound network calls from a runner mid-job, and permission scopes that exceed what a workflow actually needs. Rather than waiting for a periodic scan, Safeguard evaluates pipeline behavior as it happens, so a compromised action attempting to exfiltrate a credential is flagged in the same run it occurs in, not in next week's report. Safeguard also verifies build provenance end-to-end, mapping every artifact back to the exact commit, workflow run, and dependency set that produced it, so teams can prove — not assume — that what shipped is what was built. For organizations already running Prisma Cloud for cloud posture, Safeguard is designed to slot in as the pipeline-native layer underneath it: closing the window between commit and cloud that a CSPM-centric scanner, by design, checks less frequently than a pipeline actually runs. The result is a supply chain where secrets, dependencies, and build provenance are enforced continuously, not audited retroactively.