Software supply chain security
The invisible dependency
In 2026, supply chain incidents increased by 95% compared to 2024, totaling 2,526 recorded incidents. Every modern software application depends on hundreds of third-party components: open source libraries, frameworks, build tools. Each one is a potential entry point.
The average Node.js application has over 1,000 transitive dependencies. A typical enterprise Java application carries several hundred. Most developers can name the 10-20 direct dependencies they intentionally selected; almost none can enumerate the 900 transitive packages those dependencies pull in. That hidden dependency tree is the supply chain attack surface.
Why this is critical
- Multiplier effect: compromising a single component reaches all its users simultaneously (XZ Utils, SolarWinds)
- Implicit trust: developers install packages assuming they are safe
- Complexity: modern dependency trees contain hundreds of nested levels
- Hard to detect: malicious code is often hidden in build scripts, not in the main source code
The multiplier effect is what makes supply chain attacks so attractive to sophisticated threat actors. A direct attack against an organization requires targeting that organization specifically. A supply chain attack against a widely-used component can compromise thousands of organizations with a single operation. The return on investment is orders of magnitude higher for the attacker.
SolarWinds demonstrated this at scale: compromising the build pipeline of a single network management software vendor provided access to approximately 18,000 customer organizations, including US government agencies and major technology companies. The attack went undetected for months because the malicious code arrived through a legitimate, trusted software update.
Types of supply chain attacks
- Package compromise: injecting malicious code into npm, PyPI, crates.io (Shai-Hulud campaign: 800 npm packages; GlassWorm: 72 VSCode extensions)
- Backdoors in legitimate projects: malicious contributions to trusted open source projects (XZ Utils backdoor)
- CI/CD compromise: injection into build pipelines (Trivy/TeamPCP incident)
- Typosquatting: packages with names close to popular legitimate packages
- SaaS integration compromise: stolen OAuth tokens used to access customer data (Drift, Salesloft incidents)
Typosquatting exploits the common tendency to mistype package names. Attackers register packages like lodahs (lodash), requesst (requests), or coloers (colors) and wait for developers to accidentally install them. These malicious packages typically contain code that exfiltrates environment variables, AWS credentials, or SSH keys at install time.
Dependency confusion attacks exploit the way package managers resolve private vs. public package names. If an internal package named company-utils exists in a private registry and an attacker publishes a malicious package with the same name to a public registry, some package manager configurations will install the public (malicious) version instead of the private one.
CI/CD compromise targets the build and deployment pipeline directly. An attacker who can inject code into a build step controls every artifact that pipeline produces. This can affect every application built by the organization and every customer receiving those artifacts.
The open source trust problem
Open source software is maintained by a diverse ecosystem ranging from corporations with dedicated security teams to individual developers maintaining critical infrastructure as a hobby in their spare time. The XZ Utils backdoor revealed that a critical compression library used in most Linux distributions was maintained by essentially one person, who was then targeted by a sophisticated social engineering campaign to accept malicious contributions.
Organizations that rely on open source dependencies — which is effectively all organizations — bear shared responsibility for the ecosystem they depend on. Identifying critical open source dependencies, supporting their maintainers financially or through contribution, and assessing the maintenance health of key dependencies are all elements of responsible supply chain security.
Code signing and verification
Code signing establishes a verifiable link between a software artifact and the identity that produced it. When properly implemented, it provides assurance that an artifact has not been modified after it was signed by the authorized publisher.
Modern signing infrastructure using tools like Sigstore and cosign enables transparent, auditable signing that does not require managing long-lived private key material. The Sigstore model uses ephemeral certificates tied to identity provider authentication, creating a public log of signing events that enables retrospective verification and detection of unauthorized signing activity.