Supply Chain Security
Software supply chain security addresses threats that target the dependencies, build systems, and distribution channels that modern applications rely on. High-profile incidents like SolarWinds, Log4Shell, and the xz backdoor demonstrated that attackers increasingly target upstream components rather than applications directly. Supply chain attacks include dependency confusion (substituting malicious packages with names matching internal packages), typosquatting in package registries, compromised maintainer accounts, malicious code injected into build pipelines, and trojanized development tools. Defenses include software bills of materials (SBOMs), dependency pinning and lock files, signature verification, provenance attestation (SLSA framework), regular dependency auditing with tools like Dependabot, Snyk, or Socket, and careful evaluation of new dependencies before adoption.
| Date Added | Link | Excerpt |
|---|
Frequently Asked Questions
- What is a software supply chain attack?
- A supply chain attack targets the components, tools, or processes used to build software rather than the application itself. This includes compromising open-source packages, injecting malicious code into build pipelines, hijacking maintainer accounts, or distributing trojanized development tools — allowing attackers to affect thousands of downstream users simultaneously.
- What is dependency confusion?
- Dependency confusion (also called namespace confusion) exploits how package managers resolve dependencies. An attacker publishes a malicious package to a public registry with the same name as a private internal package. If the build system checks the public registry first or prefers higher version numbers, it installs the attacker's package instead of the legitimate internal one.
- How do you defend against supply chain attacks?
- Key defenses include maintaining a Software Bill of Materials (SBOM), using lock files and dependency pinning, enabling automated dependency scanning (Dependabot, Snyk, Socket), verifying package signatures and provenance, adopting the SLSA framework for build integrity, using private registries with allow-lists, and regularly auditing your dependency tree for known vulnerabilities.