In March 2023, attackers compromised the build pipeline of VoIP vendor 3CX by first poisoning an upstream dependency, turning a routine CI job into a distribution channel for malware that reached hundreds of thousands of endpoints. It was the second software supply chain compromise of its kind within two years, following the April 2021 Codecov Bash Uploader breach, which sat undetected for roughly two months while exposing CI secrets across thousands of customer environments. Both incidents share a common thread: the pipeline itself, not just the application source code, was the attack surface. Yet most DevSecOps programs still lean on tooling built for an earlier threat model — static analysis of first-party code — while treating build servers, package registries, and deployment credentials as an afterthought. Checkmarx, one of the most widely deployed SAST and SCA platforms, exemplifies this gap well. This post breaks down where CI/CD pipeline security actually needs to live in a modern DevSecOps pipeline, what Checkmarx covers, what it misses, and how Safeguard closes the difference.
What Makes CI/CD Pipelines a Distinct Attack Surface From Application Code?
CI/CD pipelines are a distinct attack surface because they hold privileged, long-lived credentials and execute untrusted code from dozens of third-party sources on every run. A single GitHub Actions workflow can pull in a base container image, a dozen marketplace actions, hundreds of npm or PyPI packages, and a deployment token with production access — all before a human reviews anything. The 2024 tj-actions/changed-files compromise, disclosed in March 2025, showed exactly how this plays out: a popular GitHub Action used in over 23,000 repositories was modified to dump CI runner memory into build logs, exposing secrets like AWS keys and GitHub tokens in plaintext. SAST tools scan the application repository; they do not scan the workflow YAML, the third-party actions it invokes, or the runner environment those actions execute in. That's the blind spot pipeline attackers exploit.
Why Isn't Checkmarx's SAST Coverage Enough to Secure a Pipeline?
Checkmarx's SAST coverage isn't enough because it analyzes code you wrote, not the code and infrastructure your pipeline trusts at runtime. Checkmarx One is strong at finding SQL injection, XSS, and insecure deserialization patterns in first-party source, and its SCA module flags known-CVE dependencies from a manifest file. But a manifest scan doesn't verify that the package actually installed at build time matches what was published, catch a malicious postinstall script, or detect that a workflow step has pull_request_target combined with a checkout of untrusted fork code — a misconfiguration pattern that enabled multiple GitHub Actions script-injection attacks documented throughout 2022 and 2023. Checkmarx customers frequently pair the platform with separate secrets-scanning and infrastructure tools precisely because pipeline-layer risks — build provenance, runner isolation, dependency confusion, artifact tampering — sit outside SAST's design center. This isn't a bug in Checkmarx; it's a category mismatch between what SAST was built to do in the early 2010s and what a 2026 CI/CD environment needs.
How Common Are CI/CD-Specific Breaches, and What Do They Cost?
CI/CD-specific breaches are now common enough that they've become a distinct incident category, not an edge case, and they carry costs well above the industry's average breach figure. IBM's Cost of a Data Breach Report has put the global average breach cost around $4.88 million in 2024, but supply chain compromises tend to run higher because remediation requires rotating every credential the pipeline ever touched, re-signing artifacts, and notifying every downstream consumer. The 2020 SolarWinds Orion compromise, where attackers inserted malicious code (SUNBURST) directly into the build process, ultimately affected roughly 18,000 organizations that had downloaded trojanized updates and cost SolarWinds tens of millions of dollars in direct incident response, plus an SEC enforcement action in 2023. The 2022 CircleCI breach, disclosed in January 2023, forced every customer to rotate all secrets stored in the platform — API keys, tokens, and SSH keys — regardless of whether their specific project was targeted, because CircleCI could not confirm the blast radius. That "rotate everything" outcome is the defining cost signature of pipeline compromises: they don't stay contained to one repo.
What Did the 2023 Codecov and 3CX Incidents Actually Teach the Industry?
As a devsecops pipeline example, the Codecov and 3CX incidents taught the industry that pipeline trust is transitive — you inherit the risk of every tool your build process calls, whether or not you wrote it. In the Codecov case, attackers modified the Bash Uploader script hosted on Codecov's own infrastructure; because thousands of customer CI jobs pulled that script directly via curl | bash on every run, one compromised script became a credential-harvesting operation across HashiCorp, Confluent, and hundreds of other engineering organizations. 3CX's compromise traced back further still — to a poisoned build of Trading Technologies' X_TRADER software, meaning 3CX was the second link in a double supply chain attack. Neither company caused its own breach through a code defect Checkmarx-style SAST would catch; both were breached because their pipelines implicitly trusted an external artifact's integrity without verifying it cryptographically at execution time.
What Should a DevSecOps Pipeline Security Program Actually Include in 2026?
A DevSecOps pipeline security program in 2026 needs to cover four layers that SAST alone doesn't touch: build provenance, dependency integrity, secrets hygiene, and runner isolation. Concretely, that means generating SLSA-compliant provenance attestations for every build artifact so downstream consumers can verify what produced it; pinning GitHub Actions and CI dependencies to immutable SHA hashes instead of mutable version tags (a control OpenSSF's Scorecard project has flagged as commonly missing in its scans of over 1 million repositories); scanning for hardcoded and leaked secrets in commit history, not just the current diff; and isolating third-party action execution from steps that touch production credentials. Google's SLSA framework, formalized as a v1.0 spec in April 2023, exists specifically because framework-level guidance for source, build, and dependency integrity was missing from prior AppSec standards. None of this replaces SAST — it sits alongside it, closing the gap between "the code we wrote is clean" and "the pipeline that shipped it can be trusted."
How Safeguard Helps
Safeguard is built around the assumption that the pipeline, not just the source repository, is where software supply chain attacks actually land. Where a SAST-centric stack like Checkmarx stops at static analysis of first-party code and known-CVE dependency matching, Safeguard continuously monitors the CI/CD layer itself: it tracks which GitHub Actions and third-party build steps run in your workflows, flags unpinned or newly-modified actions before they execute against production credentials, and verifies artifact provenance so a build output can be traced back to the exact source commit and dependency set that produced it. Safeguard also scans for exposed secrets across commit history and CI logs — the same failure mode that turned the tj-actions incident into a mass credential-exposure event — and surfaces dependency confusion and typosquatting risks before a malicious package ever reaches a build server. For teams running Checkmarx for SAST and SCA, Safeguard doesn't ask you to rip anything out; it fills the specific gap between "our code has no known vulnerabilities" and "our pipeline can't be silently hijacked," giving security and platform teams one place to see pipeline risk the way attackers already see it: as a single, continuous chain from commit to production.