Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Artikel 21 der NIS2-Richtlinie schreibt die Sicherheit der Lieferkette als Mindestmaßnahme vor und verpflichtet die betroffenen Stellen, die Schwachstellen jedes einzelnen direkten Lieferanten zu bewerten.
- Die ENISA, die EU-Agentur für Cybersicherheit, führt in ihren unverbindlichen Leitlinien für die Beschaffung im Krankenhausbereich aus, dass Open-Source-Betreuer möglicherweise nicht als direkte Lieferanten gelten.
- Bei von Entwicklern hinzugefügter Open-Source-Software gibt es möglicherweise keinen Anbieter, den man befragen könnte, sodass die Überprüfung Ihrem Team obliegt.
- Die Leitungsgremien genehmigen Maßnahmen gemäß Artikel 21 und können haftbar gemacht werden; stellen Sie daher sicher, dass diese Maßnahmen auch von Entwicklern hinzugefügte Open-Source-Komponenten abdecken.
Ein auf der Grundlage von Verträgen erstelltes Lieferantenverzeichnis kann zwar vollständig erscheinen, dennoch den Open-Source-Code in Ihrer Software außer Acht lassen. Die Maßnahmen zur Sicherheit der Lieferkette in der zweiten Richtlinie über Netz- und Informationssicherheit (NIS2) beziehen sich speziell auf Ihre direkten Lieferanten. Für den Open-Source-Code, den Ihre eigenen Entwickler hinzufügen, gibt es jedoch möglicherweise keinen Lieferanten, an den ein Fragebogen gesendet werden könnte.
Wer gilt also als Ihr Lieferant, wenn es sich um Open-Source-Code handelt? Die Antwort darauf bestimmt, welche Fragen Sie einem Lieferanten stellen können und welche Prüfungen weiterhin Ihrem Team obliegen.
Unabhängig davon, wie die Antwort lautet: Durch den Einkauf bei einem Lieferanten werden Ihre NIS2-Verpflichtungen nicht auf diesen Lieferanten übertragen. Die Richtlinie verlangt von den betroffenen Organisationen, das Lieferantenrisiko durch eigene Maßnahmen zu steuern, und die Europäische Agentur für Cybersicherheit (ENISA) stellt in ihren unverbindlichen technischen Umsetzungsleitlinien fest, dass die Auslagerung eines Risikos Ihre Verantwortung dafür nicht aufhebt.
Was die NIS2-Maßnahme zur Sicherheit der Lieferkette von Ihnen verlangt
Die Maßnahme gilt für wesentliche und wichtige Einrichtungen – die beiden Kategorien, die in der NIS2-Richtlinie definiert sind – und richtet sich nach der Kritikalität eines Sektors oder einer Dienstleistung sowie nach der Größe der Organisation. In der Praxis bedeutet dies im Allgemeinen mittelgroße und größere Organisationen in den aufgeführten Sektoren sowie einige kleinere, sodass nicht jedes Unternehmen erfasst wird.
In Artikel 21 Absatz 2 sind zehn Maßnahmen aufgeführt, die ein Unternehmen mindestens ergreifen muss. Die unter Buchstabe d genannte Maßnahme betrifft die Sicherheit der Lieferkette. Sie umfasst den Sicherheitsaspekt der Beziehungen jedes Unternehmens zu seinen direkten Lieferanten oder Dienstleistern. In Artikel 21 Absatz 3 wird dann dargelegt, was bei dieser Maßnahme zu berücksichtigen ist: die spezifischen Schwachstellen jedes direkten Lieferanten und Dienstleisters; die Gesamtqualität der Produkte und die Cybersicherheitspraktiken der Lieferanten, einschließlich ihrer Verfahren zur sicheren Entwicklung; sowie die Ergebnisse etwaiger auf Unionsebene koordinierter Risikobewertungen kritischer Lieferketten.
Das sind die in der Richtlinie festgelegten Anforderungen an die Sicherheit der Lieferkette. Eine Richtlinie ist für die Mitgliedstaaten verbindlich, nicht jedoch für Unternehmen; daher werden diese Vorschriften über das nationale Recht der einzelnen Länder auf die Unternehmen übertragen. Artikel 21 Absatz 1 verlangt zudem Maßnahmen, die den Risiken angemessen und verhältnismäßig sind, womit ein Teil der Ausgestaltung Ihnen überlassen bleibt.
In einer Erwägungsgrund der NIS2 sowie in mehreren anderen EU-Rechtsakten ist ebenfalls von Anbietern die Rede. Die einzige verbindliche Regelung ist eine von der Europäischen Kommission verabschiedete Verordnung, die aufgrund der Anforderungen der NIS2 erlassen wurde: die Durchführungsverordnung (EU) 2024/2690. Sie legt detaillierte Vorschriften gemäß Artikel 21 fest, darunter auch eine Anbieterpolitik für bestimmte digitale Diensteanbieter wie Cloud- und Managed-Service-Anbieter.
| Dokument | Was dort über Lieferanten steht | Für wen gilt dies? | Verbindlich? | Grundlage |
|---|---|---|---|---|
| NIS2 (Richtlinie (EU) 2022/2555), Artikel 21 Absatz 2 Buchstabe d und Artikel 21 Absatz 3 | Sicherheit der Lieferkette, einschließlich der Beziehungen zu direkten Lieferanten; Schwachstellen bei direkten Lieferanten; Produktqualität, Cybersicherheitsmaßnahmen und sichere Entwicklungsverfahren der Lieferanten | Wesentliche und wichtige Einheiten | Ja, durch nationales Recht | EU-Richtlinie |
| NIS2, Erwägungsgrund 85 | Nennt Software-Anbieter; empfiehlt Vertragsbedingungen mit Direktlieferanten; andere Lieferantenebenen könnten in Betracht gezogen werden | Wesentliche und wichtige Einheiten | Nein | Erwägungsgrund – eine Hilfestellung bei der Auslegung |
| Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 | Richtlinie zur Sicherheit in der Lieferkette für Direktlieferanten mit Auswahlkriterien | Aufgeführte digitale Unternehmenstypen, wie beispielsweise Cloud- und Managed-Service-Anbieter | Ja, für diese Typen | Durchführungsrechtsakt |
| Technischer Leitfaden der ENISA zur Umsetzung, Version 1.0, Juni 2025 | Praktische Hinweise und Beispielbelege zur Durchführungsverordnung | Aufgeführte digitale Entitätstypen; können andere informieren | Nein | ENISA-Leitlinien |
| EU-Toolbox zur Sicherheit der IKT-Lieferkette, Februar 2026 | Einheitlicher Ansatz zur Bewertung und Minderung von Risiken in der IKT-Lieferkette | Mitgliedstaaten sowie öffentliche und private Akteure | Nein, freiwillig | Leitfaden der NIS-Kooperationsgruppe |
Open-Source-Betreuer gelten möglicherweise nicht als direkte Lieferanten
In Erwägungsgrund 85 der NIS2 werden Softwarehersteller als zu den Lieferanten gezählt, deren Risiken von Bedeutung sind, und es wird darauf hingewiesen, dass Unternehmen auch über die direkten Lieferanten hinausblicken könnten. Erwägungsgründe begründen jedoch für sich genommen keine Verpflichtungen, und die in Artikel 21 genannten Lieferantenbeziehungen beziehen sich auf direkte Lieferanten.
In den im Juli 2026 veröffentlichten Beschaffungsrichtlinien der ENISA zur Cybersicherheit von Krankenhäusern und Gesundheitsdienstleistern wird die Frage behandelt, ob ein Open-Source-Betreuer – zumindest im Gesundheitswesen – als direkter Lieferant gilt.
Aus einer Mitteilung der ENISA: „Bei freier und quelloffener Software (OSS) gelten die Stellen, die die Software offen pflegen und verbreiten, möglicherweise nicht als direkte Dienstleister.“
Dies gilt, so heißt es in den Leitlinien weiter, wenn über eine standardmäßige Urheberrechtslizenz hinaus kein Vertragsverhältnis mit dem Projekt besteht oder wenn der Vertrag mit einem Open-Source-Software-Steward geschlossen wurde. Dieser Begriff ist in einem anderen Gesetz, dem Cyber Resilience Act, definiert und bezeichnet eine juristische Person – mit Ausnahme eines Herstellers –, die die Entwicklung bestimmter Open-Source-Produkte nachhaltig unterstützt.
Die Leitlinien sind unverbindlich und für die Beschaffung im Gesundheitswesen verfasst; sie legen daher nicht fest, wie eine nationale Behörde Artikel 21 auslegen wird. Sie stehen im Einklang mit dem Wortlaut der Richtlinie, der an keiner Stelle ausdrücklich vorschreibt, dass eine Stelle die Betreuer eines Open-Source-Projekts überprüfen muss. Das mit dem Code selbst verbundene Risiko fällt weiterhin unter Ihre Maßnahmen gemäß Artikel 21, wenn auch nicht unbedingt unter die Maßnahmen zur Sicherheit der Lieferkette.
Ein Anbieter kann Open-Source-Software in einem Produkt ausliefern, ein Dienstleister kann sie als Teil einer Dienstleistung bereitstellen, oder Ihre eigenen Entwickler können sie in die von Ihnen entwickelte Software integrieren. Der Anbieter oder Dienstleister ist in der Regel Ihr direkter Lieferant, sodass die in Artikel 21 Absatz 3 genannten Faktoren, einschließlich der sicheren Entwicklung, für ihn gelten. Wenn Ihre eigenen Entwickler Open-Source-Software integrieren, gibt es möglicherweise keinen Lieferanten im vertraglichen Sinne. Artikel 21 Absatz 2 Buchstabe e über die Sicherheit bei der Beschaffung, Entwicklung und Wartung von Netzwerk- und Informationssystemen, einschließlich des Umgangs mit Sicherheitslücken, passt besser zu diesem Fall als die Sicherheitsmaßnahme für die Lieferkette.
Wenn Sie Software verkaufen, sind Sie möglicherweise der direkte Lieferant, nach dem Ihre Kunden fragen. NIS2 gilt für Organisationen unabhängig von Branche und Größe; die Tatsache, dass Sie der Lieferant eines anderen Unternehmens sind, bedeutet also nicht automatisch, dass Sie in den Geltungsbereich dieser Verordnung fallen. Sie haben eigene Verpflichtungen, wenn Ihr Unternehmen selbst eine wesentliche oder wichtige Einrichtung ist. Unabhängig von Ihrem Status können die eigenen Maßnahmen Ihrer Kunden dazu führen, dass diese fragen, wie Sie die von Ihnen gelieferten Produkte entwickeln und warten.
Wo Fragebögen aufhören und Ihre eigenen Überprüfungen beginnen
NIS2 schreibt keine spezifischen Prüfungen für Open-Source-Pakete vor. Bei den nachstehenden Prüfungen handelt es sich um praktische Maßnahmen, die unter Artikel 21 Absatz 2 Buchstabe e und die darin geregelte Behandlung von Sicherheitslücken fallen.
Eine Lieferantenprüfung funktioniert, weil man nachfragen kann. Man verschickt einen Fragebogen, hat einen Vertrag abgeschlossen, und der Anbieter hat einen Grund, zu antworten. Wenn die eigenen Entwickler Open-Source-Software einbinden, trifft das auf den Betreuer kaum zu, der den Code unter einer Lizenz veröffentlicht hat und vielleicht noch nie von Ihnen gehört hat. Ein Fragebogen allein kann nicht überprüfen, ob das von Ihnen verwendete Paket mit dem von den Betreuern veröffentlichten Code übereinstimmt, und da es keinen Lieferanten gibt, an den man ihn senden könnte, gibt es in der Regel niemanden, der dafür verantwortlich ist, ihn zu überprüfen, bevor er bei Ihnen ankommt. Ein Betreuer, der keine Korrekturen mehr veröffentlicht, beantwortet möglicherweise auch keine Sicherheitsfragen.
Damit bleiben noch die Überprüfungen des Pakets selbst. Stimmt es mit dem veröffentlichten Quellcode überein? Könnte es schädliche Inhalte enthalten? Wird die von Ihnen verwendete Version noch weiterentwickelt? Ihr Team muss sicherstellen, dass diese Überprüfungen durchgeführt werden – unabhängig davon, ob es sie selbst durchführt oder einen entsprechenden Dienst nutzt.
Außerdem sollten Sie dokumentieren, was Ihre Software enthält und woher die einzelnen Komponenten stammen, denn Sie können keine Fragen im Stil von Lieferanten zu Komponenten beantworten, die Sie nicht auflisten können. Die üblichen Aufzeichnungen sind eine Software-Stückliste (SBOM) und Herkunftsdaten, aus denen hervorgeht, woher ein Artefakt stammt und wie es erstellt wurde. Eine VEX-Erklärung (Vulnerability Exploitability eXchange) ergänzt diese Informationen um den Status bekannter Schwachstellen in einem Produkt. Jede dieser Aufzeichnungen ist nur so zuverlässig wie derjenige, der sie erstellt hat. Überprüfen Sie daher, wer dahintersteht und wann sie zuletzt aktualisiert wurde.
Die Leitungsorgane genehmigen die Maßnahmen gemäß § 21 und können haftbar gemacht werden
Gemäß Artikel 20 Absatz 1 müssen die Mitgliedstaaten sicherstellen, dass die Leitungsorgane wesentlicher und wichtiger Einrichtungen die Maßnahmen nach Artikel 21 genehmigen, deren Umsetzung überwachen und für Verstöße der Einrichtung gegen Artikel 21 haftbar gemacht werden können. Die Bestimmung enthält keine Angaben dazu, ob einzelne Mitglieder persönlich haften. Die ausdrückliche Regelung für Einzelpersonen findet sich in Artikel 32 Absatz 6. Die Mitgliedstaaten müssen es ermöglichen, Personen, die befugt sind, eine wesentliche Einrichtung zu vertreten, für sie zu entscheiden oder sie zu kontrollieren, haftbar zu machen, wenn sie ihre Pflicht zur Gewährleistung der Einhaltung der Vorschriften verletzen; Artikel 33 Absatz 5 dehnt dies auf wichtige Einrichtungen aus.
Auch Schulungen spielen eine Rolle: Gemäß Artikel 20 Absatz 2 müssen Mitglieder der Leitungsgremien an Schulungen teilnehmen, um Risiken zu erkennen und die Verfahren zum Management von Cybersicherheitsrisiken sowie deren Auswirkungen auf die Dienste des Unternehmens zu bewerten.
Ein Leitungsgremium, das Maßnahmen genehmigt, die ausschließlich für vertraglich gebundene Lieferanten vorgesehen sind, hat genau diesen Anwendungsbereich genehmigt. Die Richtlinie deckt nach wie vor das Risiko durch Open-Source-Komponenten ab, die Ihre Entwickler hinzufügen. Das Problem besteht darin, dass dies bei der Ausarbeitung der Maßnahmen möglicherweise weder den Sicherheitsmaßnahmen für die Lieferkette noch den Entwicklungsmaßnahmen unter Punkt (e) zugeordnet wird und ein Leitungsgremium, das das Lieferantenverzeichnis einsehen, dies möglicherweise nie bemerkt. Fragen Sie den Verfasser der Maßnahmen, welche davon die Überprüfung dieses Codes abdeckt und wer diese durchführt.
Die Lücke zwischen Lieferantenbewertungen und Ihren Bauprojekten schließen
Bei Open-Source-Code, für den kein Lieferantenvertrag vorliegt, übernimmt SecureChain von TuxCare diese drei Prüfungen direkt am Paket selbst. Das System überprüft den Open-Source-Code auf versteckte Malware, erstellt die Open-Source-Pakete aus diesem geprüften Code in gehärteten, isolierten Umgebungen neu und blockiert alles, was die Prüfungen nicht besteht, bevor es Ihre Umgebung erreicht. Aktive Pakete werden im Rahmen einer Service-Level-Vereinbarung (SLA) gepatcht, und sobald die Wartung durch den Upstream-Anbieter endet, sorgt der „Endless Lifecycle Support“ (ELS) dafür, dass weiterhin Korrekturen bereitgestellt werden. Die Abdeckung umfasst JavaScript, Python, Java, Go und PHP, und die Builds verfügen über eine Herkunftsnachweis nach „Supply-chain Levels for Software Artifacts“ (SLSA) Level 3, SBOMs und VEX-Datensätze.
Wenn Sie nicht sagen können, was in einem Build enthalten war, oder wenn Sicherheitslücken in Paketen offen bleiben, die niemand mehr pflegt, sehen Sie sich an, wie SecureChain jeden Build protokolliert und diese Pakete patcht.
FAQ
Wie geht NIS2 das Thema Sicherheit in der Lieferkette an?
NIS2, die EU-Richtlinie zur Cybersicherheit, führt in Artikel 21 die Sicherheit der Lieferkette als eine der zehn Mindestmaßnahmen auf. Diese Maßnahme umfasst den Sicherheitsaspekt der Beziehungen eines Unternehmens zu seinen direkten Lieferanten oder Dienstleistern. Artikel 21 Absatz 3 verpflichtet Unternehmen dazu, die Schwachstellen jedes einzelnen direkten Lieferanten sowie die Produktqualität und die sicheren Entwicklungsverfahren des Lieferanten zu bewerten.
Wer muss die NIS2-Maßnahmen zur Lieferkette einhalten?
Wesentliche und wichtige Einrichtungen. NIS2, die EU-Richtlinie zur Cybersicherheit, unterteilt Organisationen anhand der Kritikalität ihres Sektors oder ihrer Dienstleistung sowie ihrer Größe in zwei Kategorien. Sie gilt im Allgemeinen für mittelgroße und größere Organisationen in den aufgeführten Sektoren sowie für einige kleinere Organisationen, die bestimmte Kriterien erfüllen.
Erlegt NIS2 den Lieferanten Verpflichtungen auf?
Nicht direkt. In ihren Beschaffungsrichtlinien für Krankenhäuser vom Juli 2026 erklärt die ENISA, die EU-Agentur für Cybersicherheit, dass die NIS2-Richtlinie keine direkten Anforderungen an Anbieter von Informations- und Kommunikationstechnologie (IKT) stellt. Von der NIS2-Richtlinie betroffene Kunden können jedoch im Rahmen ihrer eigenen Maßnahmen weiterhin Zusicherungen von Anbietern verlangen.
Sind die ENISA-Leitlinien zur Sicherheit der Lieferkette gemäß NIS2 verbindlich?
Nein. Die ENISA, die EU-Agentur für Cybersicherheit, bezeichnet ihre „Technischen Umsetzungsleitlinien“ vom Juni 2025 als unverbindlich. Sie dienen der Umsetzung der Durchführungsverordnung (EU) 2024/2690 der Kommission, die bestimmte Arten digitaler Einrichtungen wie Cloud- und Managed-Service-Anbieter abdeckt. Auch die ENISA-Leitlinien für die Beschaffung im Krankenhausbereich vom Juli 2026 stellen Empfehlungen dar.
Wie hoch können die NIS2-Geldbußen bei Verstößen gegen die Maßnahmen gemäß Artikel 21 sein?
Gemäß Artikel 34 der NIS2, der EU-Richtlinie zur Cybersicherheit, müssen die Mitgliedstaaten für wesentliche Einrichtungen Höchststrafen von mindestens 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes und für wichtige Einrichtungen von mindestens 7 Millionen Euro oder 1,4 % festlegen, je nachdem, welcher Betrag höher ist. Als Umsatz gilt der Wert des vorangegangenen Geschäftsjahres für das gesamte Unternehmen, zu dem die Einrichtung gehört. Die Geldbußen gelten für Verstöße gegen Artikel 21 oder gegen die Vorschriften zur Meldung von Vorfällen gemäß Artikel 23, wobei die konkreten Beträge durch nationale Gesetze festgelegt werden.
Gilt NIS2 in allen EU-Ländern auf dieselbe Weise?
Nein. Die Verpflichtungen gelten für Unternehmen gemäß dem nationalen Recht der einzelnen Mitgliedstaaten, daher gibt es Unterschiede im Einzelnen. In vielen Mitgliedstaaten sind inzwischen Gesetze in Kraft getreten, obwohl die meisten die Frist für deren Verabschiedung im Oktober 2024 verpasst haben. Im Juli 2026 hat die Europäische Kommission Irland, Spanien, Frankreich und die Niederlande vor den Gerichtshof der Europäischen Union gebracht, da sie die vollständige Umsetzung nicht mitgeteilt hatten. Informieren Sie sich über die Rechtslage in jedem Land, in dem Sie tätig sind.
