// ELUSIVE THOUGHTS — APPSEC / SUPPLY CHAIN

The CI/CD Pipeline Is the Crown Jewel: Why Every 2026 Supply Chain Attack Targets the Same Thing

Posted by Jerry — May 2026

If you list the named supply chain attacks of the last twelve months and look at what each one was trying to steal, the answer is identical across the list.

Trivy. KICS. LiteLLM. Telnyx. Axios. Bitwarden CLI. SAP CAP. PyTorch Lightning. Intercom Client. PGServe. Different ecosystems, different threat actor groups in some cases, identical objective in every case: extract the secrets and tokens that live inside CI/CD pipelines and developer environments.

GitHub Actions secrets. AWS access keys. GCP service account JSON. Azure managed identity tokens. npm publish tokens. PyPI API tokens. Docker Hub credentials. SSH keys for deploy targets. Kubernetes service account tokens. Cloud database credentials. The same shopping list, every time.

// the math the attackers worked out first

Phishing one developer to compromise their personal machine yields one set of credentials. Phishing a hundred developers yields a hundred sets, with proportional cost and detection risk.

Compromising one widely-used build tool, GitHub Action, or npm package yields the credentials of every CI/CD pipeline that uses it. The blast radius scales with the popularity of the package, not the effort of the attack.

TeamPCP, the threat actor group behind the Trivy, KICS, LiteLLM, and Telnyx campaigns, internalized this math. So did the Shai-Hulud worm operators behind the Bitwarden CLI compromise. The attacks of 2026 are not opportunistic. They are systematic, with each compromise feeding the next via stolen npm publish tokens that allow lateral movement across packages.

The PyTorch Lightning compromise of late April 2026 demonstrated the secondary effect: the malicious version was live for forty-two minutes before quarantine. The infection vector was not even direct download — it spread through a transitive dependency in pyannote-audio, infecting downstream consumers who never directly installed Lightning.

// the structural weakness

CI/CD pipelines were designed for trust. Build them, watch them work, deploy what they output. The historical threat model assumed the build environment was clean and the inputs were trusted. That assumption no longer holds.

The specific structural failures that supply chain attacks exploit, in approximate order of impact:

FAILURE 1 — TAG MUTATION

GitHub Actions and npm both allow tags to be reassigned to different commits or versions. uses: aquasecurity/trivy-action@master and uses: aquasecurity/trivy-action@v1 both resolve dynamically. When TeamPCP compromised the Trivy action repository, they force-pushed tags to point at malicious code. Every workflow that referenced the action by tag silently received the malicious version on the next run. The fix is to pin to commit SHA. Adoption remains low.

FAILURE 2 — STATIC LONG-LIVED CREDENTIALS

A static AWS access key with broad permissions stored in GitHub Actions secrets is the most common pattern in 2026. It is also the most exploitable. AWS, GCP, and Azure all support OIDC federation that issues short-lived tokens scoped to specific workflows. Adoption requires changing the IAM model, which is real work, which is why most organizations have not done it.

FAILURE 3 — UNCONSTRAINED EGRESS FROM BUILD RUNNERS

Build runners typically have unrestricted internet access during dependency installation. The malicious postinstall script can exfiltrate to any HTTPS endpoint. The CanisterSprawl campaign used Internet Computer Protocol canister endpoints specifically because they look like generic HTTPS traffic and survive most network filtering. Egress allow-listing on build runners is operationally hard but eliminates an entire category of exfiltration.

FAILURE 4 — INSTALL-TIME CODE EXECUTION

npm postinstall scripts and Python setup.py scripts execute arbitrary code as part of dependency resolution. The original ecosystem decision to allow this was a developer convenience that became a permanent attack surface. npm install --ignore-scripts and pip's PEP 517 build isolation reduce this surface but break enough legitimate workflows that they are not universally adopted.

FAILURE 5 — SCANNER AS ATTACK VECTOR

Security scanners like Trivy and Checkmarx KICS are run early in the pipeline with broad access to source code and credentials. When the scanner itself is compromised, it has access to everything the pipeline has access to. The Trivy compromise specifically exploited this: a tool intended to find vulnerabilities was used to deliver malware. Treat scanners as untrusted dependencies. Pin them. Sandbox them. Audit their network access.

// hardening checklist for this week

The full hardening of a CI/CD environment is a multi-quarter project. The list below is what is achievable in a focused week of work and produces the largest reduction in attack surface per hour invested.

1. Audit every uses: reference in every workflow. Replace tag references with commit SHAs. Tools like StepSecurity and Renovate can automate the SHA-pinning and the subsequent maintenance.
2. Enable npm audit signatures and PyPI attestations on every install command in CI. Sigstore-backed verification is no longer optional.
3. Replace one long-lived cloud credential with OIDC federation as a proof of concept. The first one is the hardest. The rest follow the pattern. Start with the deployment role for the highest-traffic service.
4. Add npm publish --provenance to publishing workflows. Free signal that downstream consumers can verify.
5. Implement an egress allow-list on the build runner network for production-deployment workflows at minimum. Define the legitimate egress destinations. Block everything else. Audit the alerts. Adjust.
6. Document the rotation procedure for every secret in your CI environment. Practice it. Test the runbook. The first time you rotate a deeply-embedded production credential under incident pressure should not be the actual incident.
7. Inventory the security scanners running in your pipelines. Pin their versions. Read the security advisories of the scanner vendors. Subscribe to their disclosure feeds.
8. Add a workflow that scans for unintended secret usage — accidental references to secrets in unprotected branches, secrets in PR builds, secrets in fork builds. The default GitHub configuration leaks secrets to fork builds in some scenarios.

// the principle

The CI/CD pipeline now contains more privilege than the people who use it. Production deployment credentials. Cloud admin tokens. Package publish authority. Database access. The pipeline is a service identity with broader access than most service accounts in your organization.

The defensive posture must match the privilege level. Most organizations are running their CI/CD environment with the security maturity of a printer. The supply chain attacks of 2025 and 2026 have made the cost of that mismatch concrete.

The good news: the controls that close this gap are well-documented and ecosystem-supported. SHA pinning, OIDC federation, Sigstore verification, egress control, and scanner sandboxing are not exotic. They are operational discipline. The work is the work.

$ end_of_post.sh — what's the worst credential you found in your CI? no judgment, just curiosity.