Open Source Has No Contractual Partner

You use open source software in your products and systems. You are regulatorily responsible for it. But you have no contractual partner who shares this responsibility with you. This is the delegation paradox of the digital supply chain.

The problem #

In a traditional supply chain, responsibility works through contracts: you agree quality standards, response times, liability provisions, and escalation paths with your supplier. When something goes wrong, you have a contact person and a contractual basis.

With open source, none of this exists:

You cannot conclude SLAs. There is nobody who guarantees you a response time.
You cannot set deadlines. When a vulnerability appears in a dependency, you can ask the maintainer to fix it. Nothing more.
You cannot transfer liability. Open source licences typically expressly exclude liability and warranty.
You have no influence on development. Whether a project considers your security requirements is not in your hands.
You have no escalation path. There is no maintainer's manager, no complaints office, no contractual penalty model.

At the same time, you bear full responsibility. For you as a user, EU legislation knows no open source exception: the reliefs in the CRA are for the projects and their stewards, not for the companies that deploy their code.

How large is the gap really? #

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%.

A Linux server alone already comes with several hundred open source packages — before you have even installed a single application of your own. For the major end products such as the operating system itself, your database, or your web server, commercial support exists. For the mass of dependencies that these products and your own software bring along, there is no provider, no SLA, and no contract.

What do the laws say? #

DORA Art. 5(2a): The management body "bears ultimate responsibility" for ICT risk management
DORA Art. 28(1): Anyone obtaining ICT services under contract remains "at all times fully responsible" for complying with all DORA obligations
NIS2 Art. 20(1): Management bodies must approve the risk management measures and oversee their implementation — and can be held responsible for infringements
§ 38(1) BSIG: Management is obliged to implement the measures under § 30 and to oversee their implementation
§ 38(2) BSIG: If they breach that duty, they are liable to their own entity for culpably caused damage — under the company law rules applicable to its legal form

Responsibility cannot be delegated. Not to the IT department, not to a service provider, and certainly not to a maintainer who has no obligation towards you.

The delegation paradox #

Directors and managing directors face a situation that does not exist in traditional supply chains:

You must manage the risks (legal obligation)
You cannot delegate the risks to the source (no contractual partner)
You may not simply pass on the responsibility (personal liability)
You often do not even know the risks (because the IT department has never looked at the SBOM)

The result: personal responsibility for a situation you cannot oversee and cannot secure through contracts. And D&O policies typically exclude the knowing breach of duty — the gap remains with you.

What does this mean for you? #

You need a structured counterpart for your open source supply chain. Not someone who takes responsibility off your hands — that is regulatorily impossible. But someone who closes the gap between "full responsibility" and "zero influence": with documented processes, measurable outcomes, and audit-ready evidence.