Defending Your Software Supply Chain: What Every Engineering Team Should Do Now | Docker

Secure, minimal container images for every team, free with enterprise features, if needed.
The software supply chain is under sustained attack. Not from a single threat actor or a single incident, but from an ecosystem-wide campaign that has been escalating for months and shows no signs of slowing down.
This week, axios, the HTTP client library downloaded 83 million times per week and present in roughly 80% of cloud environments, was compromised via a hijacked maintainer account. Two backdoored versions deployed platform-specific RATs attributed with high confidence to North Korea’s Lazarus Group. The malicious versions were live for approximately three hours. That was enough.
This follows the TeamPCP campaign in March, which weaponized Aqua Security’s Trivy vulnerability scanner, a security tool trusted by thousands of organizations, and cascaded the compromise into Checkmarx KICS, LiteLLM, Telnyx, and 141 npm packages via a self-propagating worm. Before that, the Shai-Hulud worm tore through the npm ecosystem in late 2025, and GlassWorm infected 400+ VS Code extensions, GitHub repos, and npm packages using invisible Unicode payloads.
The pattern is consistent across all of these incidents: attackers steal developer credentials, use them to poison trusted packages, and the compromised packages steal more credentials. It is self-reinforcing, it is accelerating, and it now has ransomware monetization pipelines behind it.
If you look at what actually failed in each of these compromises, the answer is the same every time: trust was assumed where it should have been verified. Organizations trusted a container tag because it had a familiar name. They trusted a GitHub Action because it had a version number. They trusted a CI/CD secret because the workflow was authored by someone on the team. In every case, the attacker exploited the gap between assumed trust and verified trust.
The organizations that came through these incidents with minimal damage had already begun replacing implicit trust with explicit verification at every layer of their stack: verified base images instead of community pulls, pinned references instead of mutable tags, scoped and short-lived credentials instead of long-lived tokens, and sandboxed execution environments instead of wide-open CI runners. None of these are new ideas, and none of them are difficult to implement. What they require is a shift in default posture, from “trust unless there’s a reason not to” to “verify before you trust, and limit the blast radius when verification fails.”
Here is what we recommend every engineering organization should do, and what we practice ourselves at Docker:
Don’t build on artifacts you can’t verify. Docker Hardened Images (DHI) are rebuilt from source by Docker with SLSA Build Level 3 attestations, signed SBOMs, and VEX metadata, free and open source under Apache 2.0. DHI was not affected by TeamPCP because its controlled build pipeline and built-in cooldown periods mean short-lived supply chain exploits (typically 1 to 6 hours) are eradicated before they ever enter the image. There is no reason not to use these today. Docker Hardened Images for Node.js, Python, and Rust also include Socket Firewall, which blocks malicious dependencies at install time intercepting supply chain attacks like CanisterWorm or the Axios compromise during npm install or pip install before they ever execute.
Mutable tags are not a security boundary. This is exactly how TeamPCP hijacked 75 of 76 trivy-action version tags. Pin GitHub Actions to full 40-character commit SHAs. Pin container images by sha256 digest. Pin package dependencies to exact versions and remove ^ and ~ ranges. If a reference can be overwritten without changing its name, it will be. For GitHub Actions you maintain, enable Immutable Releases – this locks release tags after publication and generates signed attestations, preventing the tag-rewriting attack that powered TeamPCP’s hijack of trivy-action. Inventory every third-party GitHub Action in use across your org and enforce an allowlist policy as you cannot pin what you haven’t cataloged. Enable two-factor authentication on every package registry account in your organization like npm, PyPI, RubyGems, Docker Hub as account takeover of a single maintainer is how most of these attacks begin. Commit your lock files and use npm ci (or the equivalent in your package manager) in all CI pipelines – this prevents builds from silently pulling new versions that aren’t in your lock file.
Both npm and Renovate support minimum release age settings that delay adoption of new versions. Most supply chain attacks have a shelf life of hours, and a 3-day cooldown eliminates the vast majority of them. We maintain a collection of safe default configurations for common package managers and tooling. Use it. Contribute to it.
When an incident hits, the first question is always: “are we affected?” If you use docker buildx to build your images, you can generate and attach SBOMs and provenance attestations during the build. Sign them. Store them alongside your images. When the next axios or Trivy happens, you check the build metadata rather than having to exec into live Kubernetes pods to figure out what’s running. Docker Scout can then continuously monitor those SBOMs against known vulnerabilities and policy violations.
TeamPCP’s credential stealer ran inside CI/CD pipelines, dumping process memory and sweeping 50+ filesystem paths for secrets. Anything accessible to a workflow step is accessible to an attacker who compromises a dependency in that step. Avoid pull_request_targe triggers in GitHub Actions unless absolutely necessary and with explicit security checks as this is the exact mechanism TeamPCP used to execute code in the context of the base repository with access to its secrets. Audit what secrets each workflow step can reach. If a scanning step has access to your deployment credentials, that is a blast radius problem, not a scanning problem.
The ro