The software supply chain is under sustained assault. Recent incidents like the axios compromise—where a widely used HTTP library was backdoored by Lazarus Group—and the TeamPCP campaign that weaponized security tools have shown that attackers are systematically exploiting implicit trust. The pattern is consistent: stolen credentials, poisoned trusted packages, and self-reinforcing credential theft. In this listicle, we outline 10 critical actions every engineering team should take to move from assumption to verification, limit blast radius, and protect against ecosystem-wide campaigns.

1. Understand the Escalating Threat Landscape

Attackers are no lonelier sticking to single incidents; they now orchestrate campaigns that cascade through the ecosystem. For example, the axios compromise (83 million weekly downloads) deployed RATs in under three hours, while the TeamPCP worm used Trivy—a security scanner—to infect Checkmarx KICS, LiteLLM, and 141 npm packages. The Shai-Hulud worm and GlassWorm (400+ VS Code extensions) further demonstrate a pattern of credential theft, package poisoning, and even ransomware monetization. Teams must recognize that these are not isolated events but a coordinated, accelerating threat landscape driven by stolen credentials and automated propagation. Awareness of these tactics is the first step to building defenses.

2. Never Assume Implicit Trust

The common thread across every major supply chain attack is that trust was assumed where verification was missing. Organizations trusted container tags because they looked familiar, GitHub Actions because they had a version number, and CI/CD secrets because they were written by a teammate. Attackers exploit this gap. Replace implicit trust with explicit verification: interrogate every dependency, tag, and credential as if it could be malicious. Adopt a “verify before trust, limit blast radius when verification fails” mindset. This shift in default posture is the foundation of all subsequent steps.

3. Use Verified Base Images

Start with base images you can verify. Docker Hardened Images (DHI), for example, are rebuilt from source with SLSA Build Level 3 attestations, signed SBOMs, and VEX metadata. They are free and open source under Apache 2.0. In the TeamPCP incident, organizations using DHI were unaffected because the images did not rely on mutable tags or unverified artifacts. By pulling verified images from trusted publishers and verifying their cryptographic signatures, you eliminate a major attack vector. Always check for attestations and refuse any image that lacks them.

4. Pin Dependencies and Use Immutable References

Mutable tags like latest or even v1.0 can be overwritten by attackers. Instead, pin to immutable digests (SHA256 hashes) for container images, npm packages, and GitHub Actions. This ensures you always get the exact artifact you—and your auditors—have verified. Also use package lock files (e.g., package-lock.json) to freeze transitive dependency versions. Immutable references make it impossible for backdoored updates to slip into your builds without manual review. Combine this with periodic re-verification of pinned versions against known-good hashes.

5. Implement Scoped and Short-Lived Credentials

Long-lived tokens and broad-scope credentials are a goldmine for attackers who steal them via compromised packages. Replace them with short-lived, scoped credentials that expire after each build or task. Use OIDC-based authentication for cloud access, and minimize the permissions granted to CI/CD workflows. For example, limit secrets to the exact repositories or environments needed. Attackers often rely on stolen developer credentials—making them short-lived and scoped reduces the window of opportunity and blast radius of any theft.

6. Sandbox CI/CD Execution Environments

CI/CD runners should not have unrestricted access. If a malicious package runs in your pipeline, it can exfiltrate secrets or inject code into artifacts. Use ephemeral, isolated environments for each job—such as Docker containers with no network access to internal services unless necessary. Apply read-only root filesystems and drop capabilities. The organizations that survived the recent campaigns had sandboxed runners that prevented even compromised workflows from causing widespread damage. Combine sandboxing with network segmentation and egress controls.

7. Enforce Multi-Factor Authentication for Maintainers

Account hijacking is the primary entry point for supply chain attacks. Enforce MFA (preferably hardware-backed or app-based) for all developer accounts, especially those with write access to repositories, registries, and CI/CD configurations. Attackers have repeatedly stolen credentials via phishing or session hijacking—MFA makes that much harder. Additionally, require signed commits and tags to verify identity. Use services that enforce MFA at the organizational level and regularly audit access logs for anomalies.

8. Automate Dependency Scanning and Vulnerability Checks

Continuous scanning of your software bill of materials (SBOM) and dependencies is non-negotiable. Integrate tools like Trivy (post-TeamPCP, with caution) or Docker Scout that automatically flag known vulnerabilities, malicious packages, and unexpected license changes. But don’t stop at detection: set policies that block builds or deployments when critical vulnerabilities are found. Since attackers often backdoor packages that are themselves security tools, ensure your scanning tools are sourced from verified channels and have their own SBOMs signed.

9. Maintain Signed SBOMs and VEX Metadata

A signed software bill of materials (SBOM) provides a cryptographically verifiable list of all components. Vulnerability Exploitability eXchange (VEX) metadata adds context—which vulnerabilities are exploitable and which are not. Docker’s Hardened Images include both, allowing teams to verify integrity and assess risk without manual inspection. Generating and signing your own SBOMs gives you the ability to audit every dependency and respond quickly when a vulnerability like those in axios or Shai-Hulud emerges. It also builds trust with downstream consumers.

10. Establish Incident Response Playbooks for Compromise

Even with the best defenses, compromises can happen. Prepare incident response playbooks specifically for supply chain incidents: how to detect a backdoored package, how to revoke rotated credentials, and how to notify affected users. Practice tabletop exercises based on real-world attacks like TeamPCP or GlassWorm. Include steps to isolate affected systems, roll back to known-good builds, and publish transparency reports. Quick, coordinated response has been the difference between minimal damage and catastrophic data breaches.

In conclusion, the software supply chain threat landscape is not slowing down. The pattern of credential theft, package poisoning, and self-propagation demands a proactive shift from trust to verification. By implementing the ten steps above—starting with verified base images and ending with incident response playbooks—your team can significantly reduce risk. Remember: it’s not about eliminating all threats, but about ensuring that when verification fails, the blast radius stays small and recovery is swift.