Checkmarx supply chain compromise shows CI/CD secret theft risk

At a glance

What this is: This is an analysis of a Checkmarx supply chain compromise that exposed CI/CD credentials through poisoned workflows and malicious extensions.

Why it matters: It matters because CI/CD pipeline identities, secrets, and developer tooling now sit on the same attack path, so IAM, PAM, and NHI teams must treat build systems as credential-bearing assets.

By the numbers:

• (CVE-2026-33634
• The affected components include ast-results v2.53.0 and cx-dev-assist v1.7.0.

👉 Read Orca Security's analysis of the Checkmarx supply chain compromise

Context

A supply chain compromise in CI/CD is not just a software bug. It is a trust failure in the identity layer around build systems, where GitHub Actions, extensions, and runner environments can all become paths to credential exposure.

In this case, the problem is the combination of trusted developer tooling, poisoned updates, and secrets available at execution time. For NHI teams, the lesson is that pipeline identities and machine credentials need the same governance attention as production workloads, because attackers only need one compromised integration point to start moving across repositories and infrastructure.

Key questions

Q: What breaks when CI/CD workflows can read production secrets?

A: The break is trust separation. When build jobs can read production credentials, a compromise in developer tooling becomes a path to cloud access, repository control, and deployment abuse. Security teams should assume the pipeline is an identity-bearing environment and limit which secrets ever reach a runner.

Q: Why do CI/CD secrets create such a large lateral movement risk?

A: Because the same secret can often authenticate to multiple services. A token exposed in a runner may be valid across repositories, cloud control planes, and artifact systems, so one theft can become many access paths. That is why rotation and scope reduction matter together.

Q: How do security teams know whether pipeline secret exposure is contained?

A: Containment is real only when exposed credentials have been revoked everywhere they were accepted and no automation still references them. Teams should confirm new tokens are in place, old ones are disabled, and dependent jobs no longer rely on the compromised secret.

Q: Who should own response when a build tool compromise exposes credentials?

A: Ownership should sit with IAM, platform engineering, and security operations together, because the issue spans identity, build infrastructure, and downstream cloud access. The right response is cross-functional containment, not a tooling-only patch.

Technical breakdown

How poisoned workflows steal secrets from CI/CD runners

The attack path starts when a trusted workflow or extension is replaced with malicious code that executes during pipeline runs. Because CI/CD runners often load tokens, API keys, and cloud credentials into memory or filesystem paths, the malicious payload can harvest secrets without needing interactive login. This is especially dangerous in automated security scanning and developer tooling, where trust in the package or action often substitutes for runtime inspection. Once secrets are captured, the attacker can reuse them outside the pipeline and widen access across connected systems.

Practical implication: treat pipeline execution environments as secret-bearing systems and verify the trust chain for every action, extension, and update.

Why developer tooling becomes a supply chain multiplier

Developer tooling extends the blast radius because it is embedded in multiple repositories, teams, and automation paths. A compromised action or extension can propagate through shared workflows, which means one poisoned artifact may reach many environments before detection. The real issue is not the vulnerability alone, but the distribution mechanism: trusted updates are often consumed automatically, and that makes malicious code harder to distinguish from routine maintenance. In identity terms, the same credentials that support fast delivery also create a reusable compromise surface when they are exposed inside runners.

Practical implication: inventory every CI/CD dependency and enforce release provenance checks before trusted updates are allowed into build paths.

How lateral movement follows credential theft in build systems

Once attackers steal cloud tokens or repository credentials, the next step is lateral movement across pipelines, repositories, and infrastructure. In CI/CD environments, access often spans source control, artifact stores, cloud control planes, and deployment targets, so a single secret can unlock multiple layers of control. That makes revocation timing critical. If compromised credentials remain valid after exposure, attackers can pivot from one project to another and eventually reach production systems. The incident also shows that partial mitigations are not enough when the original secret remains usable.

Practical implication: rotate exposed secrets immediately and validate that revocation covered every downstream system that accepted the credential.

Threat narrative

Attacker objective: The attacker aims to steal reusable CI/CD credentials and convert trusted developer tooling into a path for broader infrastructure compromise.

1. Entry occurred through compromised CI/CD workflows and malicious updates delivered via trusted GitHub Actions and OpenVSX extensions.
2. Credential access followed as the malicious payload harvested secrets from runner memory and filesystem paths during pipeline execution.
3. Escalation happened when stolen cloud credentials and tokens were reused to move laterally across repositories, infrastructure, and build pipelines.
4. Impact included potential full control of build environments, production disruption, and downstream supply chain compromise.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Pipeline trust is now an identity problem, not only a software provenance problem. CI/CD runners routinely hold credentials that are valid outside the build process, so a compromised action can convert build-time access into broader enterprise access. The governance failure is that teams often treat the pipeline as a delivery mechanism while ignoring its role as a credential executor. Practitioners should treat build infrastructure as part of the identity estate.

Secret exposure in automation breaks the assumption that developer tooling is low-risk by default. Trusted updates, extensions, and actions are frequently allowed to execute with broad runtime reach, which makes the pipeline a high-value identity target. That means the control boundary is not the repository alone, but the entire execution path from source to runner to downstream cloud service. Security teams need to govern that full chain.

Standing credentials in CI/CD create a reusable compromise surface that attackers can turn into lateral movement. Once a token or API key is exposed, it often remains valid long enough to be reused across repositories and environments. That is why revocation timing matters as much as detection. Practitioners should assume any pipeline secret may already be part of an active attack path.

Identity blast radius is the right concept for this class of compromise. The same workflow that accelerates delivery can also multiply exposure if one trusted component is poisoned. The issue is not just one vulnerable integration, but how far a single credential can travel once it leaves the pipeline. The practical conclusion is to map where one secret can unlock many systems.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, showing how quickly new operational surfaces can become credential reservoirs.
• To go deeper on pipeline compromise patterns, see the CI/CD pipeline exploitation case study for the full attack path and remediation logic.

What this signals

Identity blast radius: the new metric for CI/CD governance is not only whether a secret exists, but how many downstream services it can unlock before revocation. In practice, teams should map that blast radius alongside runner privilege and token lifetime, using the OWASP Non-Human Identity Top 10 as a control lens.

The article's core signal is that pipeline security and NHI governance are converging. When build tooling can exfiltrate reusable credentials, security teams need tighter provenance controls, shorter-lived secrets, and better offboarding of automation identities before the next exposure reaches production.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025, secret exposure is no longer an edge case. Teams that still rely on detection-only response will keep inheriting valid credentials into their attack surface.

For practitioners

• Inventory every workflow and extension with secret access Map which GitHub Actions, OpenVSX extensions, and runner jobs can reach cloud tokens, repository credentials, or deployment secrets. Prioritise any path that can read runner memory or filesystem paths, because those locations were used in the compromise.
• Rotate credentials that passed through affected pipelines Replace exposed secrets immediately and verify that revocation reaches all dependent cloud services, repositories, and artifact systems. Partial mitigation is not enough when older tokens may still remain valid.
• Enforce provenance checks on trusted updates Require signed releases, pinned versions, and review gates for pipeline actions and developer extensions before they are consumed in production workflows. Automated consumption of updates should never bypass release integrity checks.
• Reduce runner privilege and isolate build identities Separate build-time credentials from production access, shorten token lifetime, and limit each runner to the narrowest repository and cloud scope required. If one job is compromised, the credential should not unlock unrelated systems.

Key takeaways

• This compromise shows that CI/CD systems can become credential theft infrastructure when trusted workflows and extensions are allowed to execute with broad secret access.
• The public severity is amplified by the fact that leaked secrets can remain usable long after disclosure, which turns detection into only the first step.
• The control that matters most is fast, verified revocation across every system that accepted the exposed credential, not just patching the vulnerable component.

Key terms

• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Secret revocation: Secret revocation is the process of invalidating exposed credentials so they can no longer be used. In practice, it must include every system that trusts the secret, because a credential that remains valid after disclosure is still an active attack path.
• Supply chain compromise: A supply chain compromise occurs when trusted software, updates, or dependencies are altered so attackers can reach downstream environments. In identity terms, the compromise often succeeds because the trusted path already carries privileged access and broad execution rights.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.

This post draws on content published by Orca Security covering the Checkmarx supply chain compromise: CVE-2026-33634, credential theft, and lateral movement in CI/CD environments. Read the original.