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

At a glance

What this is: TeamPCP is a 2026 supply chain campaign that compromised four popular developer tools and used them to steal credentials from CI/CD and runtime environments.

Why it matters: It matters because modern identity and access controls often trust pipeline and workload contexts that attackers can abuse before static detection or review cycles catch up.

👉 Read Oligo Security's analysis of the TeamPCP supply chain campaign

Context

Supply chain attacks against developer tooling are now an identity problem as much as a software integrity problem. When a trusted package, workflow, or scanner runs with elevated pipeline access, the attacker inherits the permissions attached to that execution context.

This campaign shows why CI/CD pipelines have become high-value identity targets. The issue is not only malicious code inside a dependency, but the speed at which stolen secrets can be validated, enumerated, and reused across cloud, container, and repository systems.

Key questions

Q: How should security teams reduce the blast radius of compromised CI/CD tools?

A: Limit each pipeline to the minimum credentials it needs, separate build from deploy permissions, and remove long-lived secrets from execution environments. The goal is to ensure that a poisoned package or workflow can only reach a narrow identity scope, not cloud administration, repository control, or broad data access. Review service accounts as privileged identities, not generic automation.

Q: Why do supply chain attacks on developer tools create such large identity risk?

A: Developer tools often run with trusted access to cloud, source control, and orchestration systems, so compromise turns one execution context into a multi-system identity event. Attackers can validate stolen secrets immediately and use them for discovery, lateral movement, and bulk extraction before normal review cycles respond. That is why pipeline trust must be governed like privileged access.

Q: What do security teams get wrong about detecting malicious packages?

A: They often focus on known-bad signatures and miss behaviour that looks legitimate until the package runs. A dependency can be harmless in static review but malicious at runtime, especially when it reads credential files, spawns subprocesses, or calls unexpected external endpoints. Behavioural telemetry is the control that closes that gap.

Q: Who is accountable when stolen pipeline credentials are used across cloud systems?

A: Accountability sits with the team that owns the pipeline identity, the secret lifecycle, and the runtime controls around it. If build jobs can access production systems, that access model must be formally governed and reviewed. Frameworks such as OWASP NHI Top 10 and NIST CSF are relevant because the issue is privileged non-human access, not just software supply chain hygiene.

Technical breakdown

Why CI/CD pipelines become privilege concentrators

Modern build and delivery pipelines routinely collect cloud credentials, repository tokens, deployment secrets, and environment variables in one execution path. That makes the pipeline itself a privileged non-human identity, even when the tools inside it are ordinary open-source utilities. In the TeamPCP pattern, compromise of a scanner or package did not need exotic exploit chains. The malware ran where trust already existed, then used that access to reach sensitive material adjacent to the build and runtime path. The core failure is that the pipeline is treated as infrastructure, when operationally it behaves like a powerful identity.

Practical implication: inventory every pipeline identity and treat its token scope, secret exposure, and runtime permissions as first-class access controls.

How credential-harvesting malware uses legitimate API calls

TeamPCP’s post-compromise behavior is instructive because it relied on ordinary tools and expected provider calls. After stealing secrets, the attackers validated them with live API requests, then enumerated IAM users, roles, storage, and orchestration services to map where the most valuable access sat. This pattern matters because behavioural detection has to distinguish legitimate developer activity from fast, unusual, high-volume use of the same APIs. A secret is not just stolen at the moment of exfiltration. It becomes dangerous when the attacker can prove it works and then use it for discovery, lateral movement, and bulk access.

Practical implication: alert on live validation and rapid enumeration sequences, not only on known-malicious package signatures.

Why runtime behaviour matters more than manifest state

Static manifest review tells you what should run. Runtime visibility tells you what is actually executing, which matters when malicious versions are injected after review or when dependency behaviour changes at execution time. TeamPCP exploited this gap by targeting the period between compromise and detection, then using the runtime context to access secrets, spawn processes, and reach cloud services. The architectural lesson is straightforward: supply chain defence cannot stop at source provenance or lockfile approval. It must observe process behaviour, outbound connections, file access, and secret access while the package is live.

Practical implication: pair build-time controls with runtime inspection that can flag unexpected secret access, process spawning, and outbound connections.

Threat narrative

Attacker objective: The objective was to turn trusted developer tooling into a credential collection and expansion point for broad cloud and repository compromise.

1. Entry occurred through compromised open-source tools and malicious PyPI or workflow updates that ran inside trusted developer and CI/CD contexts.
2. Escalation followed when the malware harvested cloud credentials, SSH keys, Kubernetes configuration files, and CI/CD secrets, then validated them with live provider calls.
3. Impact came from rapid discovery and lateral movement into cloud, repository, and orchestration systems, enabling bulk exfiltration of data and secrets.

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

CI/CD trust has become identity trust: The security boundary in modern supply chains is no longer the repository alone, but the runtime identity that executes inside build and deployment systems. TeamPCP exploited the fact that these systems routinely hold cloud and repository credentials as if they were ordinary application inputs. Practitioners should treat pipeline execution contexts as privileged NHI actors with explicit governance, not just tooling.

Pipeline secrets create an identity blast radius: Once a build workflow can reach cloud keys, container orchestration, and source-control tokens, a single poisoned dependency becomes a multi-system identity event. The campaign shows that compromise is not confined to the infected package; it inherits the access graph attached to the workflow. The implication is that access scope in pipelines now drives breach magnitude more than package popularity does.

Runtime validation compresses the response window: TeamPCP did not wait for defenders to finish scanning feeds or reviewing manifests. It validated stolen secrets within hours and began reconnaissance almost immediately. That makes “time to compromised-secret use” a more relevant governance metric than time to disclosure. Security programmes that still rely on delayed review cycles are measuring the wrong control boundary.

Legitimate tools are now the attacker’s camouflage: The campaign used normal APIs, expected developer actions, and ordinary cloud services to move from one compromised tool to many victim environments. That means defenders cannot assume malicious intent will appear as unusual malware behaviour. The failure mode is behavioural normality at the application layer combined with abnormal intent at the identity layer, which is exactly where classic perimeter thinking breaks down.

Ephemeral secret validation debt: Secrets stolen from build systems accrue value in minutes, while most governance processes assume disclosure and use will be separated by days. That assumption fails when attackers can test credentials immediately and reuse them at scale. The implication is that supply chain security must be judged by how quickly a stolen secret can become an active session, not just by how quickly a compromise is reported.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For deeper NHI context, read The 52 NHI breaches Report for recurring exposure patterns across real incidents.

What this signals

Ephemeral credential trust debt: The real risk in supply chain compromise is not only secret theft, but the lag between theft and containment. In environments where build systems can validate and reuse secrets immediately, that trust debt compounds faster than review cycles can resolve it.

Teams should expect more attacks that blend package poisoning, workflow abuse, and cloud credential harvesting into one operational path. The right response is to treat developer tooling as privileged identity infrastructure and to instrument it with runtime telemetry, secret lifecycle control, and provider-level verification.

This problem aligns closely with broader NHI governance themes covered in the 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10, because the same privilege and lifecycle failures repeat across workloads, pipelines, and service identities.

For practitioners

• Separate build identities from production access Remove broad cloud, repository, and cluster permissions from CI/CD identities. Use narrowly scoped, environment-specific credentials so compromise of a build tool does not automatically open deployment and data paths.
• Monitor for secret validation after theft Alert on sequences such as sts:GetCallerIdentity, rapid Secrets Manager lookups, unexpected IAM enumeration, and short-window bursts of repository or object-store access from a single token.
• Inspect runtime behaviour, not only manifests Pair package allowlisting with runtime detection of unexpected file reads, outbound connections, subprocess creation, and access to credential paths inside containers and build jobs.
• Reduce the credential payload in developer workflows Keep SSH keys, long-lived API tokens, and cloud secrets out of build contexts where possible. Where they are unavoidable, make them short-lived and tightly bound to the minimum required task.

Key takeaways

• TeamPCP shows that a poisoned dependency can become an identity breach when build systems carry broad cloud and repository access.
• The scale of the risk is driven by how quickly stolen secrets can be validated and reused, not just by how quickly malicious code is detected.
• Security teams need runtime behavioural controls and tighter pipeline identity scoping to reduce blast radius before compromise spreads.

Key terms

• Pipeline Identity: A pipeline identity is the non-human identity used by build, test, and deployment systems to authenticate to cloud, source control, and orchestration services. It often carries more privilege than a human operator would be given directly, which makes lifecycle control and scope reduction critical.
• 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.
• Runtime Dependency Risk: Runtime dependency risk is the gap between what a software manifest says will run and what a live workload is actually executing. It matters because malicious or altered packages can behave differently at runtime, especially when they touch secrets, spawn processes, or call external endpoints.

What's in the full article

Oligo Security's full research covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of the Trivy, KICS, LiteLLM, and Telnyx compromise sequence across the March 2026 campaign
• Observed examples of secret validation, including live checks against cloud providers and SaaS tokens
• Runtime detection patterns for malicious package behaviour, including outbound connections, credential-file access, and subprocess spawning
• Product-specific examples of how Oligo maps affected runtime dependencies and flags anomalous package behaviour

👉 The full Oligo Security post covers the compromise timeline, validation activity, and runtime detection details.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.