Loading module...

Software Supply Chain Failures | Top 10 Dev Training

OWASP-03

Software Supply Chain Failures

Failures related to components, dependencies, and the software supply chain.

Audio overview (optional)

AI-generated summary. The Read tab has the full written content, which is the primary source and what the quiz is based on.

Transcript

Software supply chain failures is new in name, but not in spirit. This category replaces what the 2021 list called "Vulnerable and Outdated Components," and the rename is doing real work. The old name focused on "pin the right version." The new name acknowledges that the risk extends across the entire process of building, distributing, and updating software. And the 2025 data backs up the concern. Fifty percent of community survey respondents rated supply chain as their number one risk, and this category has the highest average incidence rate of any at five point one nine percent.

So let's talk about what supply chain failures actually look like, and the attacks that made this category impossible to ignore.

Four real-world attacks to ground the concept.

In 2019, the SolarWinds supply chain attack. Attackers compromised the build server for SolarWinds Orion, inserting malicious code into routine software updates. When roughly eighteen thousand organizations installed the "trusted" update, they unknowingly deployed backdoors into their networks. Government agencies. Fortune 500 companies. One of the largest supply chain attacks in history.

In 2021, Log4Shell. A zero-day remote code execution vulnerability in Apache Log4j, a library used by a staggering percentage of Java applications. Attackers could trigger the exploit by getting any part of an application to log a specially-crafted string, which would then execute arbitrary code. The vulnerability was blamed for ransomware, cryptomining, and widespread attack campaigns for months.

In 2025, the Bybit cryptocurrency theft. A wallet software vendor was compromised, and the malicious code was conditional. It only executed when a specific target wallet was in use. That patience paid off. The attackers stole one point five billion dollars in cryptocurrency.

Also in 2025, the Shai-Hulud npm worm. The first successful self-propagating worm in the npm ecosystem. Malicious versions of popular packages used post-install scripts to harvest developer secrets, detect npm tokens in the victim's environment, and automatically publish malicious versions of any package the victim had access to. It reached over five hundred package versions before the ecosystem could contain it. Not theoretical. Active, fast-moving, and specifically targeting developers.

So how do these attacks succeed? A few common patterns.

Lack of component tracking. Most applications depend on dozens of direct dependencies, which depend on hundreds of transitive ones. Without a software bill of materials, or SBOM, you don't actually know what's running in your production.

Trust in unvetted sources. Downloading packages from public registries without verifying signatures or provenance. Typosquatting, where a malicious package is named almost-but-not-quite like a popular one, waiting for a developer to mistype. Dependency confusion, where an internal package name is also registered on the public registry, and the build system grabs the wrong one.

Weak CI/CD security. The pipeline that builds your production artifacts often has less security than the production systems themselves. A compromised build pipeline can inject malicious code into every deployment from then on.

So how do you defend against this category?

Generate and maintain an SBOM. OWASP Dependency Track and OWASP Dependency Check are widely used. Track both direct and transitive dependencies. An SBOM isn't a one-time snapshot. It's a living inventory you update every build.

Verify what you're installing. Prefer signed packages. Pull from official registries over secure links. Deliberately choose dependency versions and only upgrade when needed, not automatically.

Harden your CI/CD. Enable MFA on every repository and registry. Protect branches. Enforce separation of duties so no single individual can write code and promote it to production without review. Use tamper-evident logs. Sign your build artifacts, and verify those signatures before deployment.

Monitor continuously. Subscribe to CVE feeds. Watch the Open Source Vulnerabilities database. When a new vulnerability affects a dependency you use, you want to know within hours, not weeks.

And stage your rollouts. Don't update every system simultaneously. Use canary deployments so a bad update hits a small slice before the blast zone widens.

Supply chain attacks are not going away. The attack surface is every package you import, every vendor you trust, every build system you run. The defense is discipline at every stage, plus an SBOM so you actually know what you're running.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.

Attestation not yet available

Complete and pass every module quiz in this course to unlock the final attestation. Once all modules are done, this tab will open for signing.

A03:2025 - Software Supply Chain Failures

Overview

Software supply chain failures are breakdowns or compromises in the process of building, distributing, or updating software. They are often caused by vulnerabilities or malicious changes in third-party code, tools, or other dependencies.

Impact: Top-ranked in community survey with 50% of respondents rating it #1. Highest average incidence rate at 5.19%. Includes famous attacks like SolarWinds, Log4Shell, and the Shai-Hulud npm worm.

Common Vulnerabilities

Lack of Component Tracking

Not carefully tracking versions of all components (both client-side and server-side), including direct dependencies and nested (transitive) dependencies.

Vulnerable or Outdated Software

Using software that is vulnerable, unsupported, or out of date, including OS, web/application servers, DBMS, APIs, components, runtime environments, and libraries.

No Vulnerability Scanning

Not scanning for vulnerabilities regularly or subscribing to security bulletins related to components in use.

Missing Change Management

No change management process or tracking of changes within the supply chain, including IDEs, extensions, code repositories, sandboxes, image/library repositories, and artifact creation.

Insufficient Supply Chain Hardening

Not hardening every part of the supply chain, especially access control and least privilege implementation.

No Separation of Duties

Supply chain systems lack separation of duties - single individuals can write code and promote it to production without oversight.

Untrusted Component Sources

Using components from untrusted sources across any part of the tech stack that can impact production environments.

Typosquatting / Package Name Squatting

Attackers publish malicious packages with names that look nearly identical to popular ones, relying on a developer's typo or muscle memory to pull the wrong package. The squatted name does not exist upstream, so the registry happily accepts it. Once installed, the package's install-time hooks (postinstall scripts in npm, setup.py in PyPI, etc.) run on the developer's machine or in CI with the same privileges as the build.

Common examples:

requets instead of requests (PyPI)
lodashs instead of lodash (npm)
python-sqlite instead of python3-sqlite3 (distro-like confusion)
Homoglyphs that swap visually similar characters (numpy vs. a unicode-lookalike)

This class overlaps with dependency confusion, where an attacker publishes a public package with the same name as a private internal package and exploits resolvers that prefer the public registry by default.

Mitigations:

Review every dependency addition in pull requests; reject additions whose names don't exactly match what was asked for.
Scope private packages (e.g., @yourorg/… on npm) and configure the installer to treat that scope as private-only.
Lock files checked into source control; require a PR to change.
Package signature or provenance verification (npm provenance, Sigstore, PyPI trusted publishers) where available.
Allowlist critical packages in CI so new direct dependencies cannot land without review.

Delayed Patching

Not fixing or upgrading platforms, frameworks, and dependencies in a risk-based, timely fashion, leaving organizations exposed for days or months.

Weak CI/CD Security

CI/CD pipeline has weaker security than the systems it builds and deploys, especially when complex.

Real-World Attack Scenarios

Scenario 1: SolarWinds Supply Chain Attack (2019)

A trusted vendor was compromised with malware, leading to customer systems being compromised during routine software updates.

Attack: Attackers inserted malicious code into SolarWinds Orion software updates. When ~18,000 organizations installed the "trusted" update, they unknowingly deployed backdoors into their networks.

Impact: One of the largest supply chain attacks in history, compromising government agencies and Fortune 500 companies worldwide.

Scenario 2: Bybit Cryptocurrency Theft (2025)

A trusted vendor was compromised to behave maliciously only under specific conditions.

Attack: Supply chain attack in wallet software that only executed when a specific target wallet was being used, stealing $1.5 billion in cryptocurrency.

Impact: Massive financial loss demonstrating conditional malware in supply chains.

Scenario 3: Shai-Hulud npm Worm (2025)

The first successful self-propagating npm worm demonstrated developers themselves are prime targets.

Attack: Malicious versions of popular npm packages used post-install scripts to:

Harvest and exfiltrate sensitive data to public GitHub repositories
Detect npm tokens in victim environments
Automatically push malicious versions of any accessible package
Self-propagate across the ecosystem

Impact: Reached over 500 package versions before disruption. Fast-spreading, advanced attack targeting developer machines directly.

Scenario 4: Component Vulnerabilities

Components run with the same privileges as the application, so flaws can have serious impact.

Examples:

CVE-2017-5638 (Struts 2): Remote code execution vulnerability enabling arbitrary code execution on servers, blamed for significant breaches.
CVE-2021-44228 (Log4Shell): Apache Log4j remote code execution zero-day, blamed for ransomware, cryptomining, and widespread attack campaigns.

How to Prevent

Patch Management Process

Software Bill of Materials (SBOM)

Centrally generate and manage SBOM of entire software
Track direct dependencies AND their transitive dependencies
Reduce attack surface by removing unused dependencies

Continuous Inventory

Continuously inventory versions of client-side and server-side components
Use tools like OWASP Dependency Track, OWASP Dependency Check, retire.js
Monitor CVE, NVD, and Open Source Vulnerabilities (OSV) databases
Use software composition analysis or security-focused SBOM tools
Subscribe to alerts for security vulnerabilities

Trusted Sources

Only obtain components from official sources over secure links
Prefer signed packages to reduce risk of modified, malicious components
Deliberately choose dependency versions and upgrade only when needed

Unmaintained Components

Monitor for libraries that are unmaintained or don't create security patches
If patching isn't possible, consider migrating to alternatives
Deploy virtual patches to monitor, detect, or protect against issues

Staged Rollouts

Update CI/CD, IDE, and developer tooling regularly
Avoid deploying updates to all systems simultaneously
Use staged rollouts or canary deployments to limit exposure

Change Management System

Track changes to:

CI/CD settings (all build tools and pipelines)
Code repositories
Sandbox areas
Developer IDEs
SBOM tooling and created artifacts
Logging systems and logs
Third-party integrations (SaaS)
Artifact repositories
Container registries

Harden Supply Chain Systems

Enable MFA and lock down IAM for:

Code Repository

Don't check in secrets
Protect branches
Maintain backups

Developer Workstations

Regular patching
MFA enabled
Monitoring

Build Server & CI/CD

Separation of duties
Access control
Signed builds
Environment-scoped secrets
Tamper-evident logs

Artifacts

Ensure integrity via provenance, signing, and time stamping
Promote artifacts rather than rebuilding for each environment
Ensure builds are immutable

Infrastructure as Code

Manage like all code
Use pull requests and version control

Ongoing Monitoring

Ensure an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.

Additional Resources

Content adapted from OWASP Top 10:2025, licensed under CC BY-SA 4.0