Open Source Supply Chain Security

Your software consists to a significant extent of open source components. These components form a supply chain — and this supply chain has risks that differ fundamentally from those of traditional supplier relationships.

Why is the open source supply chain different? #

With a traditional supplier, you have a contract, a contact person, agreed quality standards, and liability provisions. With open source, you have none of this. The software is provided by individuals or small groups, often without any obligation towards users.

This means: you use software for which nobody is responsible towards you — but you are fully responsible towards your customers, supervisory authorities, and injured parties.

The five central risks #

1. Abandonment. A project is no longer maintained. The maintainer has stopped, burned out, or lost interest. Vulnerabilities are no longer fixed. Updates no longer come. Your dependency persists.

2. Deletion. A maintainer deletes their project — out of frustration, due to a dispute, or for other reasons. Your build pipeline breaks. Worse: someone else registers the same package name and injects malicious code.

3. Licence change. A project changes its licence — from permissive to restrictive or to proprietary. Suddenly, you may no longer use the software as before, or unexpected costs arise.

4. Supply chain attacks. An attacker takes over a project — through social engineering, by purchasing the namespace, or by compromising the maintainer's account. The malicious code is distributed through the normal update infrastructure. Your systems download it automatically.

5. Maintainer overload. A maintainer is not malicious but overwhelmed. Security reports remain unprocessed for weeks. Patches are reviewed with delay. Quality declines. The project becomes a risk even though it is officially still "active".

Not just runtime: development dependencies are included #

When people talk about "supply chain", many only think of components that end up in the final product — the runtime dependencies. But your supply chain also includes everything you use to build, test, and deliver your software: compilers, build tools, test frameworks, CI/CD pipelines, package managers and their plugins.

Why this matters: a compromised build tool can inject malicious code into your final product without a single line of your source code or runtime dependencies being changed. The XZ Utils attack in 2024 demonstrated exactly this — the malicious code was injected through the build process.

The laws make no distinction here: NIS2 Art. 21(2)(e) requires security measures in the development and maintenance of systems. DORA Art. 25(1) mandates open source analyses as a required test. CRA Art. 13(5) demands due diligence when integrating FOSS components — not only when deploying them.

What do the laws require? #

EU legislation treats open source dependencies as part of your supply chain — runtime and development dependencies alike:

DORA Art. 28(1): ICT third-party risk as an integral component — financial undertakings remain at all times fully responsible
DORA Art. 28(4): Due diligence before concluding agreements with ICT third-party service providers — also for OSS integration
DORA Art. 28(8): Exit strategies for ICT third-party service providers — also relevant for OSS dependencies
DORA Art. 25(1): Open source analyses as a mandatory test — covers all deployed components
NIS2 Art. 21(2)(d): Supply chain security as a mandatory measure
NIS2 Art. 21(2)(e): Security measures in the acquisition, development and maintenance, including vulnerability management
NIS2 Art. 21(3): Assessment of vulnerabilities and security of development processes of direct suppliers
CRA Art. 13(5): Due diligence when integrating FOSS components
CRA Art. 13(25): The EU may adopt a Union-wide dependency assessment for FOSS components

Outdated dependencies: the problem cascades #

The risk of outdated dependencies does not start with you. 90% of examined commercial codebases contain open source components that are more than four years outdated. 71.6% of dependencies in open source projects themselves are outdated. This means: when a commercial vendor uses outdated open source software, it pulls in yet more outdated software through the supply chain — the risk cascades through every layer. 95% of all vulnerabilities are found in precisely these transitive dependencies that nobody consciously chose. More on this under Why your SBOM is rotting.

No contract, no SLA #

Of over 7 million analysed open source components (as of 2024), fewer than 4,000 have a commercial support provider with whom you could conclude an SLA — that is less than 0.06%. For the mass of dependencies your software brings along, there is no provider, no contract, and no escalation path. More on this under Open source has no contractual partner.

What does this mean for you? #

Your open source supply chain is not an abstract concept. It consists of concrete projects, concrete maintainers, and concrete risks. The laws require that you know, assess, and manage these risks. "We only use established projects" is not a sufficient strategy — because established projects also become orphaned, and popular projects also get attacked.