TL;DR: TeamPCP compromised four open-source tools in nine days, then harvested cloud credentials, SSH keys, Kubernetes configs, and CI/CD secrets from trusted developer workflows, according to Oligo Security. The campaign shows that supply chain compromise now turns on runtime trust and speed, not just malicious code placement.
NHIMG editorial — based on content published by Oligo Security: TeamPCP Campaign: The Evolution of Modern Supply Chain Attacks
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Separate build identities from production access Remove broad cloud, repository, and cluster permissions from CI/CD identities.
- 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.
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
👉 Read Oligo Security's analysis of the TeamPCP supply chain campaign →
Supply chain attacks in CI/CD pipelines: what teams missed?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: TeamPCP shows how supply chain attacks now target CI/CD trust