Attackers have shifted from targeting applications to targeting the tools that build them. Here is how to protect your software supply chain.
Traditional application security focused on defending the application in production. Supply chain attacks attack the software before it ever reaches production, compromising the tools, dependencies, and pipelines that build it. A single successful supply chain attack can propagate to thousands of downstream victims, which is why attackers have invested heavily in this vector. SolarWinds, event-stream, ua-parser-js, and many other high-profile incidents have demonstrated that the build process is now a prime target. Defending it requires a new set of disciplines.
Understanding the Attack Surface
A modern software supply chain includes far more than the code a team writes. It includes:
- ▸Open-source dependencies pulled from public registries
- ▸Container base images and their transitive dependencies
- ▸Build tools including compilers, linkers, and package managers
- ▸CI/CD systems that execute builds with significant privileges
- ▸Source code repositories that host the code and its history
- ▸Development machines where engineers work
- ▸Signing keys and secrets used to verify artifacts
- ▸Artifact registries that store and distribute outputs
A compromise at any of these stages can inject malicious code into the final product, often in ways that are very hard to detect.
Common Attack Patterns
Supply chain attacks take many forms:
- ▸Typosquatting where attackers publish malicious packages with names similar to popular ones
- ▸Dependency confusion exploiting how package managers resolve between public and private registries
- ▸Maintainer compromise where a legitimate package is hijacked through credential theft
- ▸Malicious updates where a legitimate maintainer is bribed or coerced
- ▸Build system compromise where the CI server itself is breached
- ▸Signing key theft enabling attackers to publish updates that look official
Each pattern requires different defenses, and a complete program addresses all of them.
Software Bill of Materials
You cannot defend what you do not know. A software bill of materials (SBOM) is an inventory of every component in a piece of software, including dependencies, their versions, and their origins. Modern SBOM standards like SPDX and CycloneDX have become widely adopted, and regulatory frameworks increasingly require them.
Generate SBOMs automatically during builds, store them alongside the artifacts they describe, and use them to track vulnerabilities and licensing. When a new vulnerability is disclosed in a popular library, you should be able to answer "are we affected?" within minutes, not weeks.
Dependency Management
Open-source dependencies are where most organizations have the least visibility. Good practices include:
- ▸Lockfiles that pin exact versions of every transitive dependency
- ▸Dependency update policies that balance security and stability
- ▸Vulnerability scanning integrated into CI
- ▸License compliance checks to catch problematic licenses
- ▸Package reputation analysis flagging new or unmaintained dependencies
- ▸Private registries that mirror upstream packages and provide a single chokepoint for controls
Do not update dependencies blindly, but do not neglect them either. Automated tools help you keep up with the flood.
Hardening the Build
The build environment itself must be treated as a high-value target:
- ▸Isolate builds from the internet and from each other where possible
- ▸Use ephemeral runners that are destroyed after each job
- ▸Enforce least privilege for build credentials
- ▸Record provenance including what was built, from what, by whom, and when
- ▸Sign artifacts and verify signatures at deployment time
- ▸Monitor build systems for unauthorized access and configuration changes
Frameworks like SLSA (Supply-chain Levels for Software Artifacts) provide a roadmap for progressively hardening the build process. Most organizations can reach SLSA level 2 or 3 with modest investment, and the return in resilience is significant.
Code Signing and Verification
Signing artifacts with trusted keys allows consumers to verify that an artifact came from where it claims. Modern tools like Sigstore make signing practical and free, with transparent logs that make key misuse detectable. Every organization should sign its production artifacts. Every organization should verify signatures before deploying.
Developer Endpoint Security
Developer laptops are often the weakest link in the supply chain. They have privileged access to source code and sensitive secrets, yet they often run with fewer controls than production systems. Harden them with:
- ▸EDR tools to detect and respond to threats
- ▸Disk encryption and strong authentication
- ▸Separation of duties between development and sensitive operational tasks
- ▸Regular patching and configuration baselines
- ▸Monitoring for suspicious activity
Incident Response for Supply Chain
When a supply chain incident happens, speed is critical. Response playbooks should include:
- ▸Quickly identifying affected builds using SBOMs and provenance data
- ▸Rolling back to known-good versions where possible
- ▸Rotating credentials and signing keys that may have been exposed
- ▸Notifying downstream consumers of affected artifacts
- ▸Investigating root cause to prevent recurrence
A Growing Priority
Supply chain attacks will continue to grow as traditional defenses improve. They offer attackers unmatched leverage: compromise one target, gain access to thousands. Defenders must catch up, and the good news is that the tools and frameworks to do so are maturing rapidly. Organizations that invest now will be ready for the attacks of the next several years. Those that do not will eventually learn the hard way.