Securing Your Software Supply Chain: Proactive Steps for Engineering Teams

The software supply chain is under continuous, sophisticated attack. These are not isolated incidents but part of a coordinated, escalating campaign that targets the very tools and libraries developers rely on. Recent events demonstrate a clear pattern: attackers compromise maintainer accounts, inject malicious code into trusted packages, and then use those compromised packages to steal more credentials, creating a self-reinforcing cycle that now includes ransomware monetization.

In one notable incident, the widely used Axios HTTP library, downloaded over 83 million times weekly and present in about 80% of cloud environments, was backdoored via a hijacked maintainer account. The two malicious versions deployed platform-specific remote access trojans (RATs) attributed with high confidence to North Korea's Lazarus Group. Although the backdoored versions were live for only three hours, that window was sufficient for significant damage.

This follows the TeamPCP campaign, which weaponized Aqua Security's Trivy vulnerability scanner—a trusted security tool—and cascaded the compromise into other npm packages via a self-propagating worm. Earlier, the Shai-Hulud worm tore through npm, and GlassWorm infected over 400 VS Code extensions, GitHub repositories, and npm packages using invisible Unicode payloads. The common thread across all these incidents is clear: attackers exploit gaps where trust is assumed rather than verified.

The Escalating Threat Landscape

The frequency and sophistication of software supply chain attacks are accelerating. Attackers are no longer content with simple credential theft; they now build self-reinforcing ecosystems that amplify their reach. By poisoning trusted packages, they can compromise downstream users, who in turn become sources of further compromise. This pattern—steal credentials, poison a package, steal more credentials—is now the norm.

For engineering teams, this means that the traditional approach of trusting components based on name, version number, or source is no longer sufficient. Every link in the chain must be verified, and blast radius must be minimized.

The Core Vulnerability: Implicit Trust

In each major compromise, the root cause was the same: trust was assumed where verification should have occurred. Teams trusted container tags because of familiar names, trusted GitHub Actions because they had version numbers, and trusted CI/CD secrets because a team member authored the workflow. Attackers exploit these gaps between assumed and verified trust.

Organizations that weathered these incidents with minimal damage had already shifted to a posture of explicit verification. They replaced mutable tags with pinned references, swapped long-lived tokens for short-lived, scoped credentials, and refactored CI/CD pipelines to run in sandboxed environments. None of these measures are new, but they require a fundamental mindset shift from "trust unless there's a reason not to" to "verify before trust, and limit the blast radius when verification fails."

Practical Defense Strategies

Here are the key actions every engineering team should implement, based on best practices we follow at Docker.

Secure Your Foundations

Start with trusted base images. Do not build on artifacts you cannot verify. Docker Hardened Images (DHI) are rebuilt from source by Docker with SLSA Build Level 3 attestations, signed SBOMs, and VEX metadata. They are free and open source under Apache 2.0. DHI was not affected by the TeamPCP compromise, demonstrating the value of verifiable supply chain artifacts.

Additionally, enforce the use of images from trusted registries and ensure every image layer can be accounted for. Consider using image signing and verification tools to enforce that only approved images enter your environment.

Implement Explicit Verification

• Pin dependencies: Use exact version hashes (SHA256) for all dependencies, including base images, npm packages, and GitHub Actions. Do not rely on mutable tags like latest or v1.
• Short-lived credentials: Replace long-lived API tokens with short-lived, scoped credentials that expire automatically. Use tools like OIDC to connect CI/CD systems to cloud providers without storing permanent secrets.
• Sandboxed runners: Run CI/CD workflows in isolated, ephemeral environments. Do not give workflows access to more than they need, and ensure each run starts from a clean state.
• Verify signatures: Use tools that support cryptographic verification of packages and images. For example, enforce that all pulled images have valid signatures from trusted parties.

Monitor and Respond

Even with strong prevention, assume compromise is possible. Implement continuous monitoring of your supply chain for anomalies: unexpected changes in dependency hashes, unusual network traffic from CI runners, or new maintainer additions to packages you consume. Have an incident response plan specifically for supply chain incidents, including steps to roll back to known good states and revoke all potentially compromised credentials.

Conclusion: A Shift in Default Posture

The tools and techniques to defend against software supply chain attacks exist. The challenge is cultural: moving from implicit trust to explicit verification. By securing foundations, enforcing verification, and monitoring continuously, engineering teams can significantly reduce their risk. Start today: audit your current dependency sources, implement pinned references, and educate your team on the importance of verifying before trusting. The attackers are not slowing down, so your defenses must accelerate.