TeamPCP shows how supply chain attacks now target CI/CD trust

At a glance

What this is: This is a supply chain attack analysis showing how TeamPCP used compromised open-source tools and packages to steal secrets from CI/CD and developer workflows at speed.

Why it matters: It matters because pipeline identities now concentrate enough privilege to turn one poisoned dependency into broad cloud, repository, and runtime exposure for NHI and IAM teams.

Context

Supply chain attacks now target the trust relationships embedded in CI/CD pipelines, not only the code published through them. In this campaign, compromised developer tools and package releases were used as delivery points for credential-harvesting malware that ran inside privileged workflow contexts.

That shift matters for identity governance because pipeline identities, build runners, and workload credentials often carry more access than the teams managing them realise. When a trusted tool becomes the delivery mechanism, the security problem is no longer just malicious code review, but runtime trust, secret exposure, and delegated access control.

TeamPCP is an atypically fast and coordinated example of a pattern practitioners increasingly have to plan for: compromise at the tool layer followed almost immediately by secret validation and operational abuse.

Key questions

Q: What happens when a trusted CI/CD workflow is compromised through a malicious or broken action?

A: A compromised workflow can exfiltrate secrets, tamper with build outputs, or propagate bad code through downstream releases before the issue is detected. Because CI/CD often has broad access to repositories and deployment credentials, one abused action can become an entry point into multiple systems. The practical response is to combine detection, baseline review, and tighter egress control.

Q: Why do supply chain attacks against CI/CD environments create broader enterprise risk than attacks limited to endpoints?

A: CI/CD environments amplify risk because they sit upstream of many systems and can distribute malicious code, artifacts, or credentials at scale. A compromise can affect multiple downstream workloads, runners, and repositories at once, turning one intrusion into repeated exposure. That makes pipeline integrity, runner hardening, and artifact verification central controls for reducing blast radius.

Q: What are the signs that a CI/CD pipeline is being abused through living-off-the-pipeline techniques?

A: Warning signs include unexpected plugin execution, tools reading configuration from the wrong location, unexplained dependency changes, unusual shell behaviour from environment variables, and secrets appearing in logs or standard output. Teams should also watch for builds that succeed while silently performing extra actions, because LOTP abuse often hides inside normal pipeline activity rather than crashing jobs outright.

Q: How should security teams respond when a secret is exposed in code or logs?

A: Start by identifying what the secret can access, not by rotating it immediately. Then isolate affected systems, revoke the credential, update dependent configurations, and verify the replacement works. A safe response sequence depends on blast radius, because the same secret may unlock multiple services or environments.

Technical breakdown

Why CI/CD trust is the real target in supply chain attacks

Modern CI/CD systems grant workflow runners, package install steps, and build plugins access to cloud tokens, repository permissions, deployment keys, and environment secrets. That makes the pipeline itself a high-value identity, not just a delivery channel. When a trusted open-source tool is compromised, malicious code executes inside the same privileged context that developers rely on for ordinary builds and scans. The attacker does not need to break authentication if the workflow already runs with delegated access. In this campaign, the infected tools sat directly inside developer and build paths, which is why the malware could collect credentials from runtime contexts rather than waiting for a separate exploit.

Practical implication: Treat CI/CD runners, GitHub Actions, and package execution as privileged identities with their own access scope and monitoring.

How stolen secrets turn into rapid environment discovery

Secret theft becomes materially worse once the attacker can verify and reuse the material almost immediately. TeamPCP validated keys and tokens with live API calls, then used them to enumerate AWS users, roles, EC2 instances, Lambda functions, databases, buckets, and hosted zones. That sequence matters because a stolen secret is only a file until it is proven live. Validation converts uncertainty into an operational foothold. At that point, discovery shifts from a code compromise to a cloud identity problem, because the attacker is now using legitimate APIs and access paths to map the environment from the inside.

Practical implication: Correlate secret-detection with live-use telemetry so validation and post-theft discovery are visible as one incident chain.

Why runtime behavior matters more than static scanning

Static scanning can tell you a package exists in a manifest, but not whether the version loaded at runtime is malicious or whether it begins touching credential paths after installation. TeamPCP’s malware used ordinary tools, expected API calls, and legitimate workflow mechanisms, which makes it difficult to detect before execution. Runtime inspection is therefore the only layer that can expose behavior such as unexpected secret-file access, outbound connections to unapproved infrastructure, subprocess spawning, or bulk repository cloning. The mechanism is simple: attackers abuse normal execution paths, so defenders need visibility into what actually runs, not just what was approved in source control.

Practical implication: Add runtime package and workflow inspection to catch malicious behavior that build-time controls will miss.

Threat narrative

Attacker objective: The objective was to turn trusted software distribution into a high-speed path for stealing and reusing operational secrets across cloud and CI/CD environments.

1. Entry occurred through compromised open-source tools and packages that executed inside trusted CI/CD and developer workflow contexts.
2. Credential harvesting followed as the malware collected cloud credentials, SSH keys, Kubernetes configuration files, and CI/CD secrets from those privileged environments.
3. Escalation and lateral movement came from validating the stolen material, then using live tokens and workflow access to enumerate AWS services, run ECS Exec, and create malicious pull requests.
4. Impact was bulk exfiltration of private repositories and cloud data, with the stolen secrets also serving as a map for further compromise.

Breaches seen in the wild

• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.
• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD trust has become the new supply chain attack surface: The important control boundary is no longer only the package registry or source repository. It is the privileged execution context where workflows can read secrets, assume cloud roles, and interact with deployment systems. That means a compromised tool can matter more than a compromised artifact because it runs where the real credentials live. Practitioners should treat workflow trust as an access-control problem, not just a software integrity problem.

Ephemeral code trust debt: This campaign shows that organisations still assume trusted execution contexts remain trustworthy for the duration of the job. That assumption fails when a malicious package can harvest secrets, validate them, and trigger downstream access before the job is complete. The implication is that CI/CD governance has to account for runtime trust decay, not just approved inputs.

Blast radius is now a pipeline property: TeamPCP demonstrated that a single poisoned dependency can expose cloud credentials, repository tokens, Kubernetes configuration, and infrastructure access paths in one move. That is not just credential theft, it is delegated infrastructure exposure through the build system. The practitioner conclusion is that blast-radius reduction belongs in pipeline design, inventory, and monitoring.

Security tooling is now a prime target because it inherits trust by design: Tools such as scanners and proxies are attractive precisely because organisations grant them broad visibility and access inside development workflows. When that trust is weaponised, the compromise can bypass normal suspicion and look like routine automation. Teams need to review which security tools execute with elevated permissions and what secrets they can touch.

Runtime validation outpaces static assurance: The gap between compromise and exploitation collapsed to hours in this campaign. That means build-time policy and manifest review remain necessary, but they are no longer sufficient to govern operational risk. Practitioners need runtime assurance as the control that decides whether a compromised package becomes a live incident or just a bad artifact.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

CI/CD trust now behaves like an identity layer: When workflows can read secrets, assume cloud roles, and run package code in the same execution path, the security question shifts from provenance to delegated access. Practitioners should map those paths as identities, not as implementation detail, because the exposure is in who or what can execute with privilege.

The operational lesson is that static controls still matter, but they no longer define the whole defence. Runtime detection, access scoping, and secret-use telemetry are the controls that determine whether a compromised dependency becomes a breach or just a blocked execution event.

For practitioners

• Map CI/CD workflow identities Inventory every runner, action, package hook, and build step that can read cloud tokens, repository secrets, or deployment credentials. Treat those execution paths as privileged identities with explicit ownership and review.
• Isolate secret-accessing build steps Split secret-reading steps from ordinary builds so package installation, scanning, and deployment do not share the same trust boundary. Reduce the number of contexts that can see cloud keys, SSH material, or Kubernetes configs.
• Add runtime secret-use detection Alert when a package, workflow, or runner begins reading credential files, calling metadata services, enumerating IAM resources, or cloning repositories in bulk. Detection needs to focus on live use, not only on known-bad hashes.
• Revoke and rotate exposed tokens Use incident playbooks that assume compromise once a trusted workflow has executed malicious code. Prioritise GitHub tokens, cloud access keys, service account credentials, and Kubernetes secrets that were reachable from the affected execution path.
• Constrain privileged workflow reuse Remove broad reuse of the same tokens across build, deploy, and maintenance pipelines so one poisoned dependency cannot open multiple downstream systems. Separate access scope by function and by environment.

Key takeaways

• This campaign shows that supply chain compromise in CI/CD is really a delegated-access problem, because trusted workflows can expose the same secrets that attackers want.
• The attack progressed from initial tool compromise to immediate secret validation and cloud discovery, which collapsed the normal response window.
• Teams that only scan manifests or review package provenance will miss the runtime secret use that turns a poisoned dependency into operational compromise.

Key terms

• CI/CD privilege boundary: A CI/CD privilege boundary is the point where untrusted repository content meets elevated execution rights. If that boundary is weak, a build or review workflow can become a route from ordinary contribution activity to token exposure, repository compromise, or supply-chain publishing.
• Runtime Secret Retrieval: Runtime secret retrieval is the practice of fetching credentials from a vault or controlled service only when they are needed. It reduces secret exposure in repositories and configs, but it only works when the retrieval path is scoped, logged, and tied to a specific workload or agent.
• Workflow Identity: A workflow identity is the non-human identity represented by an automated CI/CD process when it authenticates, accesses secrets, or performs actions in other systems. In practice, it is the authority carried by the pipeline itself, and it must be governed with explicit scope, review, and revocation.
• Secret Validation: Secret validation is the attacker practice of testing stolen credentials against the target provider to confirm that they still work. In supply chain attacks, this turns a stolen token from a possibility into an active access path, often within minutes or hours of theft.

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.