Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Die CRA, FedRAMP, NIS 2 und PCI DSS stellen in Bezug auf Ihre Open-Source-Komponenten immer dieselben zwei Fragen: Was liefern Sie aus, und was geschieht, wenn eine Sicherheitslücke entdeckt wird?
- Sie unterscheiden sich hinsichtlich des Zeitrahmens (PCI DSS rechnet ab der Veröffentlichung eines Patches, FedRAMP ab der Bewertung, während CRA und NIS 2 keine konkrete Frist vorgeben), hinsichtlich der Frage, wer die Aufzeichnungen überprüft, und hinsichtlich der Aufbewahrungsdauer (nur CRA legt eine Frist fest: mindestens 10 Jahre).
- In keinem davon wird erläutert, wie sich feststellen lässt, woher eine Komponente stammt, oder wer die Fehlerbehebung übernimmt, sobald ihre Betreuer ihre Arbeit einstellen.
- SecureChain erfüllt beide Anforderungen: Die Pakete werden geprüft, aus dem Quellcode neu kompiliert, im Rahmen eines SLA gepatcht und mit Herkunftsnachweis, einer SBOM sowie VEX-Erklärungen bereitgestellt.
Der Cyber Resilience Act (CRA), das Federal Risk and Authorization Management Program (FedRAMP), NIS 2 und der Payment Card Industry Data Security Standard (PCI DSS) gehen jeweils weit über den Nachweis der Compliance in der Software-Lieferkette hinaus und werfen jeweils Fragen auf, die sich auch auf die Open-Source-Pakete in Ihrem Produkt beziehen können. Eine dieser Anforderungen ist bereits mit einem konkreten Datum verbunden: Der PCI DSS schreibt seit dem 31. März 2025 ein Inventar der Komponenten von Drittanbietern vor.
Nehmen wir ein hypothetisches Unternehmen, das in der EU verkauft, ein NIS-2-Unternehmen beliefert, einen Cloud-Dienst für den Bund betreibt und Karteninhaberdaten verarbeitet. Ein einziges Open-Source-Paket könnte Fragen seitens einer Marktüberwachungsbehörde, des NIS-2-Kunden, einer Bundesbehörde und eines Zahlungsprüfers aufwerfen. Woher stammt es, und wer kümmert sich um Patches, wenn die Entwickler die Pflege einstellen?
Die vier Dokumente überschneiden sich inhaltlich und unterscheiden sich darin, wer was, wem und wie lange anzeigt. Bei dem im Titel genannten Register handelt es sich um „SecureChain“ von TuxCare, das Open-Source-Pakete über ein kuratiertes Repository bereitstellt.
An wen sich das jeweilige Dokument richtet
Jedes Dokument verwendet einen eigenen Begriff für die Partei, an die es sich richtet, und diese Begriffe werden nicht einheitlich verwendet. Die CRA richtet sich an den Hersteller, der in Artikel 3(13) als eine Person definiert wird, die Produkte mit digitalen Elementen entwickelt oder herstellt bzw. herstellen lässt und diese unter ihrem eigenen Namen oder ihrer eigenen Marke vermarktet. Das FedRAMP-Playbook legt die Hauptverantwortung für die Sicherheitskontrollen beim Cloud-Dienstleister fest, und in den Vorschriften von 2026 ist von einem „Anbieter“ die Rede. Das Playbook beschreibt den Prozess gemäß Rev. 5; FedRAMP stellt es auf seiner alten Website als Referenz bereit, während die Umstellung auf die Vorschriften von 2026 erfolgt. NIS 2 gilt für wesentliche und wichtige Einrichtungen, die in den Artikeln 2 und 3 hauptsächlich nach Sektor und Größe definiert werden. PCI DSS gilt für Einrichtungen, die Karteninhaberdaten speichern, verarbeiten oder übertragen oder deren Sicherheit beeinträchtigen könnten. Dazu gehören Dienstleister, d. h. andere Einrichtungen als Zahlungsmarken, die im Auftrag einer anderen Einrichtung Karteninhaberdaten verarbeiten, speichern oder übertragen oder Dienstleistungen erbringen, die die Sicherheit der Karteninhaberdatenumgebung beeinträchtigen könnten.
| Dokument | Rechtlicher Charakter | Angesprochen als | Stand: 28. Oktober 2026 | Grundlage |
|---|---|---|---|---|
| CRA, Verordnung (EU) 2024/2847 | Verordnung, die in ihrer Gesamtheit verbindlich und unmittelbar anwendbar ist | Hersteller (Art. 3 Abs. 13) | Gilt ab dem 11. Dezember 2027. Artikel 14 gilt ab dem 11. September 2026. | Bindetext |
| FedRAMP-Leitfaden zur kontinuierlichen Überwachung, Version 1.0 (17. November 2025) und zusammengefasste Vorschriften für 2026 | Programmleitfaden (Playbook) und Programmregeln | Cloud-Dienstleister (Playbook), Anbieter (Regeln von 2026) | Regelsätze für die Erkennung und Behebung von Sicherheitslücken (VDR) sowie für die Bewertung und Meldung von Sicherheitslücken (VER): Erstzertifizierung und fortlaufende Zertifizierung ab dem 7. Dezember 2026. Die Übergangsfrist endet am 7. März 2027. | Leitfaden (Playbook). Als „erforderlich“ gekennzeichnete Regeln. |
| NIS 2, Richtlinie (EU) 2022/2555 | Richtlinie, die durch die nationalen Rechtsvorschriften der einzelnen Mitgliedstaaten umgesetzt wird | Wesentliche und wichtige Rechtssubjekte (Art. 2, 3) | Die Maßnahmen der Mitgliedstaaten mussten bis zum 17. Oktober 2024 ergriffen werden und gelten ab dem 18. Oktober 2024 (Art. 41 Abs. 1). | Für die Mitgliedstaaten verbindlich |
| PCI DSS v4.0.1 (Juni 2024) | Branchenstandard | Unternehmen, die Karteninhaberdaten speichern, verarbeiten oder übermitteln (Abschnitt 2) | Version 4.0.1, Juni 2024. Die Anforderung 6.3.2 gilt seit dem 31. März 2025. | Branchenstandard |
Ein Unternehmen kann gleichzeitig mehr als eine dieser Rollen innehaben, beispielsweise als Hersteller im Rahmen der CRA und als Cloud-Dienstleister im Rahmen von FedRAMP; daher bestimmt seine Rolle, welche Fragen aus welchem Dokument für das Unternehmen gelten. Was Sie als Nachweis für die Konformität der Software-Lieferkette vorlegen müssen, wird in jedem Dokument anders bezeichnet. Die CRA verlangt technische Dokumentation; das FedRAMP-Playbook verlangt Ergebnisdokumente und Belege; NIS 2 verlangt Nachweise zur Umsetzung; und PCI DSS verlangt, dass ein Prüfer die Dokumentation überprüft.
Hinweis: PCI DSS v4.0.1 überlässt es den Zahlungskartenmarken, Acquirern und anderen Organisationen, die Compliance-Programme verwalten, zu entscheiden, wer die Anforderungen erfüllen oder die Einhaltung der Anforderungen nachweisen muss (Abschnitt 2).
Was jeder über Komponenten von Drittanbietern wissen möchte
Was sich in Ihrer Software befindet, wird in jedem Dokument mit einem anderen Begriff bezeichnet. Die CRA nennt Open-Source-Komponenten ausdrücklich. NIS 2 spricht von direkten Lieferanten und Dienstleistern. Das FedRAMP-Playbook, in dem Open Source oder Software-Stücklisten nicht erwähnt werden, befasst sich mit Bestandsaufnahmen und Schwachstellen, und PCI DSS identifiziert Komponenten von Drittanbietern in maßgeschneiderter und kundenspezifischer Software.
| Dokument (Art) | Was dort zu den Komponenten gefragt wird | Was du zeigst und wem | Angegebene Verweildauer | Grundlage |
|---|---|---|---|---|
| CRA (Verordnung) | Sorgfaltspflicht bei Komponenten von Drittanbietern (Art. 13 Abs. 5). Meldung von Sicherheitslücken in Komponenten an den Betreuer und deren Behebung (Art. 13 Abs. 6). Identifizierung und Dokumentation von Komponenten anhand einer Software-Stückliste, die mindestens die Abhängigkeiten auf oberster Ebene abdeckt (Anhang I, Teil II Nr. 1). | Technische Unterlagen (Anhang VII), die den Marktüberwachungsbehörden zur Verfügung gestellt werden (Art. 13 Abs. 13). Software-Stückliste auf begründeten Antrag der Behörde (Anhang VII, Nummer 8). | Technische Dokumentation: mindestens 10 Jahre nach dem Inverkehrbringen des Produkts oder für die Dauer des Supportzeitraums, falls dieser länger ist (Art. 13 Abs. 13) | Bindetext |
| FedRAMP (Programmrichtlinien und Vorschriften) | Mindestens einmal monatlich Bestandsaufnahme durchführen (Playbook, Abschnitt 2). Jede einzelne Schwachstelle wird als eigener Eintrag im Aktionsplan mit Meilensteinen (POA&M) erfasst (Abschnitt 3). Die Überwachung der Lieferkette ist als Erkennungsmethode aufgeführt (VDR-CSO-DET). | Monatliche POA&M- und Bestandsdaten an das sichere Repository zur Überprüfung durch die Behörde (Playbook). Monatlicher Bericht über Schwachstellenaktivitäten an alle erforderlichen Parteien (VER-TFR-MHR). | Im Playbook oder im VER-Regelwerk nicht angegeben | Leitfaden (Playbook). Als „erforderlich“ gekennzeichnete Regeln. |
| NIS 2 (Richtlinie) | Sicherheit der Lieferkette, einschließlich der Beziehungen zu direkten Lieferanten (Art. 21 Abs. 2 Buchstabe d). Umgang mit Sicherheitslücken und deren Offenlegung (Art. 21 Abs. 2 Buchstabe e). Abwägung der Sicherheitslücken, der Produktqualität und der Cybersicherheitspraktiken jedes direkten Lieferanten, einschließlich sicherer Entwicklungsverfahren (Art. 21 Abs. 3). | Auf Verlangen ist der zuständigen Behörde der Nachweis über die Umsetzung der Richtlinien zur Cybersicherheit zu erbringen (Art. 32 Abs. 2 Buchstabe g für wesentliche Einrichtungen, Art. 33 Abs. 2 Buchstabe f für wichtige Einrichtungen). | In den Artikeln 21, 32 oder 33 nicht angegeben | Für die Mitgliedstaaten verbindlich |
| PCI DSS v4.0.1 (Branchenstandard) | Bestandsaufnahme der maßgeschneiderten und kundenspezifischen Software sowie der dazugehörigen Komponenten von Drittanbietern (6.3.2). Patches für kritische Sicherheitslücken werden innerhalb eines Monats nach ihrer Veröffentlichung installiert (6.3.3). Bestandsaufnahme der betroffenen Systemkomponenten (12.5.1). | Von einem Gutachter geprüfte Unterlagen und Befragungen (6.3.2.a, 6.3.2.b). | In den Abschnitten 6.3.2, 6.3.3 oder 12.5.1 nicht angegeben | Branchenstandard |
Hinweis: Gemäß Artikel 13 Absatz 5 gilt die Sorgfaltspflicht auch für freie und Open-Source-Komponenten, selbst wenn diese nicht im Rahmen einer gewerblichen Tätigkeit zur Verfügung gestellt wurden.
Wo sich die Nachweise zur Compliance in der Software-Lieferkette überschneiden und wo nicht
Die Überschneidung betrifft den Inhalt der beiden Fragen. Zum einen geht es darum, welche Komponenten Sie ausliefern. Sowohl die CRA als auch das Playbook und der PCI DSS verlangen jeweils eine Bestandsaufnahme in irgendeiner Form. NIS 2 führt das Asset-Management unter den Maßnahmen gemäß Artikel 21 Absatz 2 Buchstabe i auf und fragt nach Lieferanten, während Artikel 21 keine Komponentenliste nennt. Die andere Frage betrifft das Vorgehen, sobald eine Schwachstelle entdeckt wird, und alle vier Dokumente gehen darauf ein. Gemäß dem CRA muss die Behebung unverzüglich erfolgen (Anhang I, Teil II Absatz 2). NIS 2 führt den Umgang mit Schwachstellen und deren Offenlegung auf (Artikel 21(2)(e)). PCI DSS legt für Patches kritischer Schwachstellen eine Frist von einem Monat ab Veröffentlichung fest (6.3.3), und die FedRAMP-Regeln für 2026 kennzeichnen alles, was 192 Tage nach der Bewertung noch offen ist, als „akzeptierte Schwachstelle“ (VER-TFR-MAV).
Die Unterschiede beginnen bereits bei den Fristen. PCI DSS rechnet ab der Veröffentlichung eines Patches, FedRAMP ab der Bewertung, während CRA und NIS 2 in den hier zitierten Bestimmungen keine konkreten Zeitangaben machen. Sie unterscheiden sich auch darin, wann und wem gegenüber man welche Unterlagen vorlegen muss. Eine Marktüberwachungsbehörde verfügt über die technische Dokumentation gemäß CRA; Behörden prüfen die monatlichen Leistungen von FedRAMP; eine zuständige Behörde kann von einer NIS-2-Einrichtung Nachweise anfordern; und ein PCI-DSS-Prüfer überprüft die Dokumentation der Einrichtung. Es sollte nicht davon ausgegangen werden, dass ein Protokoll, das auf dem Zeitrahmen und dem Leser eines Dokuments basiert, auch für ein anderes Dokument geeignet ist.
Was die Dokumente Ihrem Ermessen überlassen
Alle vier Dokumente stellen die Frage und lassen die Vorgehensweise weitgehend offen. Die CRA verpflichtet Hersteller, die Cybersicherheitsaspekte des Produkts in einer dem Risiko angemessenen Weise zu dokumentieren (Artikel 13 Absatz 7), und die NIS 2 fordert angemessene und verhältnismäßige Maßnahmen (Artikel 21 Absatz 1). Der PCI DSS überlässt den Zeitpunkt der Installation anderer anwendbarer Patches – also solcher, die nicht kritische Schwachstellen betreffen – der eigenen Risikobewertung des Unternehmens (6.3.3), und die Erkennungsregel von FedRAMP verlangt angemessene Techniken (VDR-CSO-DET).
In den bisher zitierten Bestimmungen bleiben zwei Fragen offen. Die erste betrifft die Herkunft einer Komponente. Artikel 13 Absatz 5 des CRA verlangt die Einhaltung der Sorgfaltspflicht, damit Komponenten von Drittanbietern das Produkt nicht gefährden, und Artikel 21 Absatz 3 der NIS 2 verpflichtet die betroffenen Stellen, die sicheren Entwicklungsverfahren der Lieferanten zu prüfen. Erwägungsgrund 85 der NIS 2, der nicht bindend ist, beschreibt, wie Angreifer Unternehmen kompromittieren, indem sie Schwachstellen in Produkten und Diensten von Drittanbietern ausnutzen. Keiner der beiden Artikel erläutert, wie überprüft werden kann, ob eine Komponente tatsächlich von der angegebenen Quelle stammt oder ob sie keinen Schadcode enthält.
Der zweite Punkt betrifft die Herkunft der Korrektur. PCI DSS 6.3.3 rechnet einen Monat ab der Veröffentlichung eines Patches, geht also davon aus, dass jemand einen solchen veröffentlicht hat. Die CRA legt die Pflicht zur Bereitstellung von Sicherheitsupdates beim Hersteller fest (Anhang I, Teil II(2)), und Artikel 13(8) hält Schwachstellen in den Komponenten eines Produkts für die gesamte CRA-Supportdauer im Geltungsbereich. Im Rahmen des kontinuierlichen Überwachungszyklus gemäß FedRAMP Rev. 5 verbleibt ein Befund ohne vorgelagerten Fix als Anbieterabhängigkeit im monatlichen POA&M. Für Anbieter mit mehr als einem Behördenkunden lenkt das Playbook die Aufmerksamkeit bei der monatlichen Kooperationssitzung auf überfällige Punkte und Anbieterabhängigkeiten (Abschnitt 7). Keine dieser Bestimmungen legt fest, woher der Fix selbst stammt, sobald die Verantwortlichen die Veröffentlichung eingestellt haben.
Wo SecureChain für Open-Source-Software zum Einsatz kommt
SecureChain von TuxCare überprüft den Quellcode von Open-Source-Paketen auf versteckte Malware und erstellt sie in einer isolierten Umgebung auf Basis dieses geprüften Codes neu. Pakete, die die Überprüfung nicht bestehen, werden blockiert, bevor sie die Umgebung des Kunden erreichen, und die übrigen werden über ein kuratiertes Repository bereitgestellt.
Jedes Paket wird mit einer Herkunftsangabe (einem signierten Protokoll über den Erstellungsprozess gemäß SLSA Level 3), einer SBOM, VEX-Erklärungen sowie Aufzeichnungen über die Herkunft und den Behebungsstatus ausgeliefert, die in den oben genannten Dokumenten abgefragt werden.
SecureChain patcht aktive Komponenten im Rahmen einer Service-Level-Vereinbarung. Bei Versionen, die vom Originalentwickler nicht mehr gepflegt werden, portiert der „Endless Lifecycle Support“ (ELS) Korrekturen für Schwachstellen mit kritischem, hohem, mittlerem und geringem Risiko innerhalb eines festgelegten Zeitplans auf die verwendeten Versionen zurück. SecureChain deckt Open-Source-Pakete in JavaScript, Python, Java, Go und PHP ab.
Wenn Sie noch nicht sagen können, woher eine Komponente stammt oder wer sie weiterpflegt, sobald die Entwicklung im Upstream eingestellt wird, sehen Sie sich an, wie SecureChain for Open Source Software diese beiden Aspekte angeht.
FAQ
Wie wird der Begriff „Evidence“ in den Vorschriften CRA, FedRAMP, NIS 2 und PCI DSS verwendet?
Alle vier verwenden diesen Begriff, allerdings in unterschiedlichen Bedeutungen. Anhang VII des Cyber Resilience Act listet Nachweise für eine Kontaktadresse zur Meldung von Sicherheitslücken in der technischen Dokumentation auf. Gemäß den Artikeln 32 und 33 der NIS-2-Verordnung können Behörden Nachweise über die Umsetzung anfordern. Das „Federal Risk and Authorization Management Program Playbook“ erwähnt Belege, und der „Payment Card Industry Data Security Standard“ sieht vor, dass Prüfer die Dokumentation überprüfen und Mitarbeiter befragen (6.3.2.a, 6.3.2.b).
Wie lange muss die technische Dokumentation gemäß CRA aufbewahrt werden?
Gemäß Artikel 13 Absatz 13 des Gesetzes über Cyber-Resilienz (CRA) sind Hersteller verpflichtet, die technische Dokumentation den Marktüberwachungsbehörden mindestens 10 Jahre nach dem Inverkehrbringen des Produkts oder für die Dauer des Supportzeitraums, falls dieser länger ist, zur Verfügung zu stellen. In Anhang VII sind die Inhalte aufgeführt, gegebenenfalls einschließlich einer Software-Stückliste.
Welche Bußgelder sehen die CRA und NIS 2 vor?
Artikel 64 Absatz 2 des Cyber Resilience Act sieht bei Verstößen gegen Anhang I sowie die Artikel 13 und 14 Geldbußen von bis zu 15.000.000 EUR oder 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres vor. Artikel 34 der NIS-2-Richtlinie verpflichtet die Mitgliedstaaten, Höchstbeträge von mindestens 10.000.000 EUR oder 2 % des Umsatzes für wesentliche Einrichtungen und von 7.000.000 EUR oder 1,4 % des Umsatzes für wichtige Einrichtungen festzulegen. In jedem Fall gilt der höhere Betrag.
Wie erreicht NIS 2 einen Softwareanbieter?
Die NIS-2-Richtlinie legt die Pflichten auf wesentliche und wichtige Stellen fest, sodass ein Lieferant in der Regel über einen Kunden erreicht wird. Artikel 21 Absatz 2 Buchstabe d und Artikel 21 Absatz 3 verpflichten die Stelle, die Schwachstellen jedes direkten Lieferanten abzuwägen und Entwicklungsverfahren zu sichern. Ein Lieferant, der selbst eine wesentliche oder wichtige Stelle ist, fällt durch die Rechtsvorschriften der Mitgliedstaaten eigenständig unter die Richtlinie.
Wann schreibt der PCI DSS eine Bestandsaufnahme von Komponenten von Drittanbietern vor?
Anforderung 6.3.2 des Payment Card Industry Data Security Standard (PCI DSS) v4.0.1, eines Branchenstandards, betrifft Komponenten von Drittanbietern, die in maßgeschneiderte und kundenspezifische Software integriert sind. Bis zum 31. März 2025 galt dies als bewährte Vorgehensweise, danach ist es verpflichtend. Ob ein Unternehmen eine Validierung durchführen muss, liegt im Ermessen der Zahlungskartenmarken, Acquirer und anderer Organisationen, die Compliance-Programme betreiben.
