Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Seit dem 11. September 2026 sind Sie gemäß Artikel 14 des CRA verpflichtet, innerhalb von 24 Stunden nach Feststellung einer aktiv ausgenutzten Sicherheitslücke in Ihrem Produkt eine Meldung zu erstatten.
- Eine SBOM auf oberster Ebene – also die Mindestanforderungen gemäß Anhang I – erfasst keine Pakete, die mehrere Ebenen tiefer liegen; eine Bestandsaufnahme auf Release-Ebene für jeden ausgelieferten Build hingegen schon.
- Ein kompatibler Backport der Version, die Sie bereits verwenden, behebt eine versteckte Abhängigkeit, ohne alles darüber hinaus zu verändern.
- Da Ihr CRA-Supportzeitraum über die Wartungsdauer des Upstream-Projekts hinausgeht, benötigt jede Paketversion einen Korrekturpfad, der auch nach Ablauf der Lebensdauer des Upstream-Projekts fortgesetzt wird.
An einem Dienstag erscheint ein neuer Eintrag im KEV-Katalog der CISA. Darin wird eine Sicherheitslücke genannt, die aktiv ausgenutzt wird – und zwar in einem Paket, das niemand aus Ihrem Team ausgewählt hat und das sich drei Ebenen tiefer in einem Abhängigkeitsbaum befindet, den niemand absichtlich zusammengestellt hat. Innerhalb von 24 Stunden muss jemand in Ihrem Unternehmen feststellen, ob dieses Paket in einer von Ihnen ausgelieferten Version enthalten ist und ob Ihr CSIRT und die ENISA informiert werden müssen.
So sieht Artikel 14 des EU-Gesetzes zur Cyber-Resilienz (CRA) von innen betrachtet aus. Die Fristen sind kurz, und der Auslöser ist enger gefasst, als die meisten Zusammenfassungen vermuten lassen, doch was wirklich wehtut, ist selten die Meldung an sich. Es geht vielmehr darum, festzustellen, was tatsächlich in der Build-Version enthalten ist, während die Uhr tickt.
Die 24-Stunden-Uhr der CRA läuft
Seit dem 11. September 2026 gilt Artikel 14 des CRA. Dies ist die erste Meldepflicht im Rahmen des CRA, die für Hersteller gilt, und sie ist zeitlich begrenzt. Sobald Sie Kenntnis davon erlangen, dass eine Sicherheitslücke in Ihrem Produkt aktiv ausgenutzt wird, haben Sie 24 Stunden Zeit.
Die CRA versteht unter dem Begriff „Hersteller“ eine Organisation oder Person, die ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und es im Rahmen einer gewerblichen Tätigkeit unter ihrem eigenen Namen oder ihrer eigenen Marke auf dem EU-Markt in Verkehr bringt. Unter gewerblicher Tätigkeit versteht man nicht nur die Erhebung eines Preises. Bezahlter Support zählt dazu, wenn er über die bloße Deckung Ihrer tatsächlichen Kosten hinausgeht. Gleiches gilt für die Monetarisierung über eine Plattform oder die Aufforderung an Nutzer, personenbezogene Daten aus Gründen weiterzugeben, die über die Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität der Software hinausgehen. Wenn dies auf Ihr Unternehmen zutrifft und Ihr Produkt als Open Source bereitgestellt wird, betrifft Artikel 14 bereits Ihr Unternehmen.
In Artikel 14 sind drei Meldefristen festgelegt. Jeder Bericht wird über die einheitliche Meldeplattform der ENISA an das als Koordinator benannte CSIRT – in der Regel das für Ihren Hauptstandort zuständige – sowie an die ENISA selbst, die Cybersicherheitsagentur der EU, übermittelt.
Zunächst erfolgt eine 24-stündige Frühwarnmeldung. Innerhalb von 72 Stunden senden Sie eine ausführlichere Meldung zur Sicherheitslücke. Spätestens 14 Tage, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar ist – so bezeichnet die CRA einen Fix oder eine Umgehungslösung –, senden Sie einen Abschlussbericht. Die Fristen von 24 und 72 Stunden sind eher äußerste Fristen als Wartezeiten. Im Text heißt es „ohne unangemessene Verzögerung und in jedem Fall innerhalb“ dieser Fristen.
„Aktiv ausgenutzt“ hat eine genaue Bedeutung. Es müssen zuverlässige Beweise dafür vorliegen, dass ein böswilliger Akteur die Schwachstelle in einem System ohne die Zustimmung des Systembesitzers ausgenutzt hat. Eine veröffentlichte CVE reicht nicht aus. Ein Proof-of-Concept reicht ebenfalls nicht aus. Artikel 14 befasst sich zudem mit schwerwiegenden Vorfällen, die die Sicherheit eines Produkts beeinträchtigen. Diese werden in einem separaten Verfahren behandelt, wobei ein Abschlussbericht einen Monat nach der Meldung des Vorfalls vorzulegen ist. Dieser Artikel befasst sich mit Schwachstellen und dem Aspekt der Open-Source-Abhängigkeiten im Rahmen der CRA. Risikobewertung, Konformitätsbewertung und die übrigen Pflichten des Herstellers fallen nicht in seinen Geltungsbereich.
Die Frist für die Erfüllung der verbleibenden Herstellerpflichten gemäß der CRA sowie für die Verhängung von Geldbußen endet am 11. Dezember 2027. Artikel 14 ist bereits in Kraft getreten und gilt für Produkte, die vor diesem Datum in der EU in Verkehr gebracht wurden.
Rechtsgrundlage: Artikel 14 Absätze 1, 2, 4 und 7; Artikel 3 Absätze 13 und 42; Artikel 64; Artikel 71 Absatz 2; Artikel 69 Absatz 3; Erwägungsgründe 15 und 18.
Warum eine SBOM auf oberster Ebene keinen Aufschluss darüber gibt, ob Sie betroffen sind
Hinweise darauf, dass eine Sicherheitslücke ausgenutzt wird, erreichen Sie in der Regel von außen: ein Eintrag im KEV-Katalog (Known Exploited Vulnerabilities) der CISA, eine Sicherheitsmitteilung eines Anbieters oder eines Betreibers oder eine Meldung eines CSIRT, eines Forschers oder eines Kunden. Daraufhin geschehen drei Dinge: Sie erfahren, dass eine Sicherheitslücke irgendwo ausgenutzt wird. Sie prüfen, ob Ihr Produkt betroffen ist. Anschließend ermitteln Sie, welche Versionen und welche Benutzer betroffen sind.
Die Frist beginnt zu laufen, sobald Sie Kenntnis von einer aktiv ausgenutzten Sicherheitslücke in Ihrem Produkt erhalten. Beginnen Sie daher sofort mit der Überprüfung glaubwürdiger Warnmeldungen. Ein übereinstimmender Paketname bedeutet an sich noch nicht, dass Ihr Produkt betroffen ist – nur mit einer genauen Bestandsaufnahme können Sie dies schnell klären. In der Praxis überschneiden sich die einzelnen Schritte, und Sie warten nicht erst auf eine vollständige Benutzerliste, bevor Sie eine Frühwarnung versenden, wenn die Frist näher rückt.
Das in der Warnmeldung genannte Paket ist oft eine transitive Abhängigkeit, die von einer Ihrer direkten Abhängigkeiten mit einbezogen wird und von niemandem in Ihrem Team ausgewählt wurde. Log4Shell (CVE-2021-44228) ist der bekannte Fall. log4j-core war in vielen Anwendungen als Abhängigkeit von Frameworks und Konnektoren vorhanden, und die meisten Teams mussten zunächst einmal herausfinden, ob sie es überhaupt hatten.
An dieser Stelle kommt die Bestandsaufnahmepflicht der CRA ins Spiel. Anhang I verpflichtet Hersteller dazu, die Komponenten eines Produkts zu identifizieren und zu dokumentieren, unter anderem durch die Erstellung einer Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format. Die Mindesttiefe beträgt „zumindest die Abhängigkeiten auf oberster Ebene“. Diese Mindestanforderung ist angemessen. Für die 24-Stunden-Frage reicht sie jedoch nicht aus.
Eine SBOM auf oberster Ebene erfasst direkt, was Sie hinzugefügt haben. Die Frage, die sich Ihnen stellt, ist, ob eine bestimmte Version eines bestimmten Pakets irgendwo im Produkt vorkommt, und dafür gibt es drei Stellen, an denen Sie nachsehen können.
Dein Manifest, ganz gleich, ob es sich dabei um package.json, pom.xml, oder requirements.txt, listet die von Ihnen deklarierten Abhängigkeiten auf, häufig als Versionsbereiche. Ihr Lockfile speichert den aufgelösten Abhängigkeitsgraphen für einen Build, wobei das, was letztendlich ausgeliefert wird, aufgrund plattformspezifischer und optionaler Abhängigkeiten, Build-Tools, Vendoring sowie einer eventuellen Neugenerierung des Lockfiles im Verlauf des Prozesses dennoch variieren kann. Ihr Release-Inventar zeigt, was das ausgelieferte Artefakt enthält: aufgelöste Komponentenversionen, alles, was in das Artefakt gebündelt oder als Vendor-Komponente integriert wurde, sowie keine der Entwicklungsabhängigkeiten, die Ihren Build nie verlassen.
Die Lockdatei ist eine wichtige Eingabe, belegt jedoch nicht, was ausgeliefert wurde. Um festzustellen, ob die gemeldete Sicherheitslücke in einer bestimmten Version vorhanden ist, benötigen Sie das Versionsverzeichnis.
Es gibt noch eine weitere Schwierigkeit bei allem, was das Ende des Lebenszyklus im Upstream überschritten hat. Wenn eine Sicherheitslücke behoben wird, lautet der Hinweis in der Regel etwa so: „In Version 4.2 behoben, ältere Zweige werden nicht mehr unterstützt“. Die 3.x-Version in Ihrem Baum ist möglicherweise davon betroffen, aber der Upstream wird dies möglicherweise nie erwähnen, da dort niemand mehr diesen Zweig im Blick hat. Die Analyse liegt nun bei Ihnen.
Rechtsgrundlage: Artikel 14 Absatz 1; Artikel 3 Nummer 42; Anhang I Teil II Nummer 1.
Warum die Aussage „Wir wussten es nicht“ Sie nicht schützt
Die Frist gemäß Artikel 14 beginnt erst zu laufen, wenn Sie Kenntnis von einer aktiv ausgenutzten Sicherheitslücke in Ihrem Produkt erlangen. Dies ist eine enge Beschränkung auf einen einzigen Auslöser, die den übrigen Bestimmungen des CRA in keiner Weise Rechnung trägt.
Ab dem 11. Dezember 2027 gelten die umfassenderen CRA-Verpflichtungen. Für Produkte, die vor diesem Datum in Verkehr gebracht wurden, greifen die Übergangsregelungen, sobald das Produkt an oder nach diesem Datum einer wesentlichen Änderung unterzogen wird. Diese Verpflichtungen erfordern, dass Sie die Komponenten und Schwachstellen in Ihrem Produkt identifizieren und dokumentieren sowie wirksame, regelmäßige Sicherheitstests und -überprüfungen durchführen. Bei der Einbindung von Komponenten von Drittanbietern, einschließlich Open-Source-Komponenten, ist Sorgfalt geboten. Außerdem müssen Sie Schwachstellen im Produkt, „einschließlich seiner Komponenten“, während der gesamten Supportdauer wirksam beheben.
Eine Komponente, die bei Ihrer Tooling-Prüfung übersehen wurde, beweist an sich noch nicht, dass Ihr Prozess unzureichend ist. Sie kann jedoch durchaus Anlass für eine Behörde sein, zu prüfen, ob Ihre Komponentenidentifizierung und Ihr Umgang mit Schwachstellen angemessen sind. Diese Verstöße fallen unter die höchste Bußgeldstufe der CRA, die bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes Ihres Unternehmens im vorangegangenen Geschäftsjahr beträgt, je nachdem, welcher Betrag höher ist. Marktüberwachungsbehörden können zudem Abhilfemaßnahmen anordnen, den Verkauf einschränken oder verbieten oder einen Rückruf oder eine Rücknahme verlangen.
Der Zeitpunkt des Inkrafttretens liegt noch in einiger Ferne. Die nächste Warnmeldung hingegen steht bereits kurz bevor. Wenn Ihre Tools ein Paket übersehen haben, werden die ersten Stunden eines 24-Stunden-Fensters damit verbracht, festzustellen, ob sich dieses Paket überhaupt in Ihrem Stapel befindet, wodurch weitaus weniger Zeit für alle anderen Aufgaben bleibt, die der Bericht erfordert.
Rechtsgrundlage: Anhang I Teil II Absätze 1 und 3; Artikel 13 Absätze 5 und 8; Artikel 54; Artikel 64 Absatz 2; Artikel 69 Absatz 2.
Jetzt bring das in Ordnung, ohne alles darüber kaputt zu machen
In der 72-Stunden-Meldung werden Sie gebeten, Ihre bisherigen Erkenntnisse mitzuteilen: allgemeine Informationen zum Produkt, die allgemeine Art des Exploits und der Sicherheitslücke, etwaige von Ihnen ergriffene Abhilfemaßnahmen oder Maßnahmen zur Risikominderung sowie die Maßnahmen, die Ihre Nutzer ergreifen können. Sie benötigen keinen fertigen Patch, um die Meldung einzureichen. Bei einer transitiven Abhängigkeit, die drei Ebenen tiefer liegt, ist jedoch weiterhin Aufwand erforderlich, um diese Maßnahmen auszuarbeiten.
Betrachten wir die übliche Situation: Der Fix ist bereits in der Upstream-Version 4.2 vorhanden. Das Zwischenpaket in Ihrem Baum ist noch auf der 3.x-Reihe stehen geblieben, und dessen Betreuer hat noch keine Aktualisierung vorgenommen. Sie haben keine kostenlosen Optionen. Sie können auf den Betreuer warten. Sie können in Ihrer Sperrdatei eine Überschreibung erzwingen und dabei das Risiko in Kauf nehmen, dass etwas darüber liegendes nicht mehr funktioniert. Sie können das Zwischenpaket auf eine Hauptversion aktualisieren, die 4.2 unterstützt, und alle damit verbundenen, nicht themenbezogenen Änderungen als Teil eines Sicherheitsreleases ausliefern. Sie können die Komponente ersetzen oder selbst patchen. Oder Sie können einen kompatiblen Backport beschaffen, also den Sicherheitsfix, der auf den von Ihnen bereits verwendeten 3.x-Zweig angewendet wurde.
Ab Dezember 2027 schreibt Anhang I hier zwei Dinge vor: Sie müssen Sicherheitslücken unverzüglich beheben. Und soweit technisch machbar, müssen Sie Sicherheitsupdates getrennt von Funktionsupdates bereitstellen. Die CRA schreibt nicht vor, welchen Weg Sie einschlagen. Sie lässt Ihnen auch die Möglichkeit, das Sicherheitsupdate nur für Ihre neueste Version bereitzustellen, solange Nutzer früherer Versionen kostenlos auf diese umsteigen können und ihnen keine zusätzlichen Kosten für die Anpassung ihrer Umgebung entstehen.
Ein kompatibler Backport berücksichtigt diese Trennung und hält den Migrationsaufwand gering. Es handelt sich um eine feste Version der bereits in Ihrem Baum vorhandenen Version, die mit ihren Abhängigkeiten kompatibel ist, wobei abhängige Pakete bei Bedarf neu kompiliert werden. Bei korrekter Durchführung bleiben Ihre eigenen Manifestdateien unverändert, und Kompatibilitätstests finden nur einmal in Ihrem Produkt statt.
Wenn ein Backport einen festen Liefertermin enthält, haben Sie einen konkreten Zeitplan für die Behebung des Problems, den Sie zusammen mit den bereits ergriffenen Maßnahmen melden können. Der Rest liegt bei Ihnen: die Integration der gepatchten Komponente, deren Test und die Veröffentlichung als Update für Ihr Produkt. Je früher die Komponente eintrifft, desto mehr Zeit bleibt Ihnen dafür.
Rechtsgrundlage: Artikel 14 Absatz 2 Buchstabe b; Anhang I Teil II Nummer 2; Artikel 13 Absatz 10; Artikel 69 Absatz 2.
Der Abschlussbericht wird erst nach der Behebung vorgelegt, und die Verpflichtung besteht über Jahre hinweg.
Der Abschlussbericht ist spätestens 14 Tage nach Bereitstellung einer Korrektur- oder Abhilfemaßnahme fällig. Er beschreibt die Sicherheitslücke, deren Schweregrad und Auswirkungen, die bekannten Informationen über den Angreifer sowie das Sicherheitsupdate oder andere Maßnahmen, die Sie bereitgestellt haben.
Unabhängig davon müssen Sie, sobald Sie von der Sicherheitslücke Kenntnis erlangen, die betroffenen Nutzer sowie gegebenenfalls alle Nutzer informieren. In der Mitteilung muss erläutert werden, welche Maßnahmen die Nutzer ergreifen können, um das Problem zu mindern oder zu beheben. Gegebenenfalls erfolgt die Übermittlung in einem strukturierten, maschinenlesbaren Format. Die CRA schreibt kein bestimmtes Format vor. CSAF ist das weit verbreitete maschinenlesbare Format für Sicherheitshinweise, und VEX-Angaben, die angeben, ob eine Sicherheitslücke ein bestimmtes Produkt betrifft, können als CSAF-VEX, CycloneDX-VEX oder OpenVEX ausgedrückt werden.
Ab Dezember 2027 muss auch das Update selbst sicher, unverzüglich und kostenlos bereitgestellt werden.
Dann kommt der „Long Tail“, bei dem die Open-Source-Logik nicht mehr zu Ihrem Vorteil wirkt.
Solange Ihr Supportzeitraum andauert, müssen Sie weiterhin Sicherheitslücken im Produkt beheben. Den Supportzeitraum legen Sie selbst fest, er muss jedoch der voraussichtlichen Nutzungsdauer des Produkts entsprechen und mindestens 5 Jahre betragen, es sei denn, das Produkt wird voraussichtlich kürzer genutzt. Darüber hinaus muss jedes Sicherheitsupdate, das Sie während des Supportzeitraums veröffentlichen, mindestens 10 Jahre nach seiner Veröffentlichung oder bis zum Ende des Supportzeitraums verfügbar bleiben – je nachdem, welcher Zeitpunkt später liegt –, damit auch Nutzer, die das Update erst spät installieren, noch darauf zugreifen können.
Die Wartung einer Paketversion durch den Hersteller kann bereits lange vor Ablauf Ihres Supportzeitraums enden. In diesem Fall hält die CRA Sie dennoch an Ihren Supportzeitraum gebunden. Sie sind nicht an genau diese Version gebunden, da der Austausch oder das Upgrade einer Komponente eine zulässige Abhilfemaßnahme darstellen kann. Sie sind jedoch verpflichtet, Sicherheitslücken in Ihrem Produkt während des gesamten Supportzeitraums zu beheben – mit welchen Mitteln auch immer.
Rechtsgrundlage: Artikel 14 Absatz 2 Buchstabe c und Absatz 8; Anhang I Teil II Nummern 7 und 8; Artikel 13 Absätze 8 und 9; Artikel 69 Absatz 2.
Niemand stromaufwärts nutzt denselben Takt wie du
Die CRA stellt bewusst sicher, dass freie und Open-Source-Software, die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird, nicht unter die Verpflichtungen des Herstellers fällt.
Es wird eine eigene Kategorie geschaffen, nämlich die des „Open-Source-Software-Stewards“, für juristische Personen, die die Entwicklung von Open-Source-Software, die für kommerzielle Zwecke bestimmt ist, nachhaltig unterstützen. Für Stewards gilt ab Dezember 2027 eine weniger strenge, maßgeschneiderte Regelung mit eingeschränkten Pflichten gemäß Artikel 14 unter bestimmten Umständen. Einzelne Community-Betreuer gelten nicht automatisch als Hersteller oder Stewards.
Unabhängig davon, welche Verpflichtungen und Unterstützungszusagen sie haben – diese unterscheiden sich von Ihren und heben Ihre Verpflichtungen nicht auf. Artikel 13 Absatz 6 konkretisiert dies. Wenn Sie eine Sicherheitslücke in einer von Ihnen ausgelieferten Komponente feststellen, müssen Sie diese der Person oder Organisation melden, die diese Komponente herstellt oder wartet, die Sicherheitslücke in Ihrem Produkt beheben – unabhängig davon, ob diese darauf reagiert oder nicht – und den entsprechenden Code oder die Dokumentation weitergeben, falls Sie eine Korrektur entwickelt haben. Sie können die Komponente patchen, ersetzen oder aktualisieren. Was Sie jedoch nicht tun dürfen, ist, die Untätigkeit der vorgelagerten Stelle als Rechtfertigung dafür heranzuziehen, Ihre eigene Reaktion zu verzögern.
Diese Verpflichtungen gemäß Artikel 13 gelten ab dem 11. Dezember 2027. Die daraus zu ziehende Lehre gilt jedoch bereits jetzt: Auch bei Code, der tief in Ihrem Code-Baum verborgen ist, den Sie nicht selbst geschrieben und vielleicht noch nie gelesen haben, liegt es weiterhin in Ihrer Verantwortung, die Sicherheitslücke in Ihrem Produkt zu beheben – selbst wenn der Upstream-Entwickler Ihnen dabei nicht hilft.
Rechtsgrundlage: Artikel 24; Artikel 3 Absatz 14; Artikel 13 Absatz 6; Artikel 69 Absatz 2; Erwägungsgründe 18 und 19.
Was eine praktikable Lösung damit zu tun hat
Die CRA lässt Ihnen Spielraum bei der Entscheidung, wie Sie die Einhaltung von Artikel 14 angehen möchten. Im Folgenden finden Sie eine Reihe praktischer Funktionen für die Open-Source-Komponenten in Ihrem Produkt. Diese sind vor allem dann von Bedeutung, wenn die Beibehaltung der Kompatibilität bestehender Versionen Ihnen Migrationsaufwand erspart.
Beginnen Sie mit einer Bestandsaufnahme aller Komponenten des Produkts auf Release-Ebene, bis hin zur letzten transitiven Abhängigkeit, die als festgelegte Versionen erfasst und den tatsächlich im jeweiligen Produkt-Release enthaltenen Komponenten zugeordnet wird. Die „24-Stunden-Frage“ lässt sich dann anhand dieser Aufzeichnungen beantworten und nicht anhand eines Scans, den Sie erst nach Eingang der Warnmeldung gestartet haben.
Als Nächstes benötigen Sie Patches, die rechtzeitig bereitgestellt werden, einschließlich kompatibler Backports für die Versionen, die sich bereits in Ihrem Baum befinden und bei denen ein Upgrade nicht praktikabel ist, wobei abhängige Pakete bei Bedarf neu kompiliert werden. Sicherheitsänderungen können dann getrennt von Funktionsänderungen bereitgestellt werden, und der Migrationsaufwand bleibt gering. Dieser Patch-Pfad muss auch nach dem Ende des Lebenszyklus eines Pakets seitens des Upstream-Entwicklers fortgesetzt werden – und zwar für die Dauer Ihres Supportzeitraums und nicht nur so lange, wie das Interesse des Betreuers reicht.
Bei den letzten beiden Punkten geht es darum, was Ihr Unternehmen verlässt. Betroffene Nutzer müssen umgehend benachrichtigt werden – gegebenenfalls in maschinenlesbaren Formaten – und Sicherheitsupdates müssen mindestens 10 Jahre nach ihrer Veröffentlichung oder für die restliche Dauer des Supportzeitraums verfügbar bleiben, falls dieser länger ist. Außerdem benötigen Sie eine gleichwertige Abdeckung für jedes Sprachökosystem in Ihrem Produkt, da es gemäß Artikel 14 keine Rolle spielt, woher eine Komponente stammt.
Die meisten der verbleibenden Herstellerpflichten sowie die damit verbundenen Durchsetzungsmaßnahmen gelten ab dem 11. Dezember 2027. Die Meldepflicht gilt bereits jetzt. Die Monate dazwischen bieten die Gelegenheit, die entsprechenden Kapazitäten aufzubauen.
Wo SecureChain und der lebenslange Support ins Spiel kommen
SecureChain und Endless Lifecycle Support (ELS) von TuxCare basieren auf diesen Funktionen, in genau dieser Reihenfolge.
Zunächst zum Bestand: Open-Source-Pakete gelangen über den SecureChain-Katalog in Ihr Produkt. Dieser Katalog verfolgt die von ihm verwalteten Paketversionen und veröffentlicht maschinenlesbare SBOMs dafür – einschließlich CycloneDX – mit den dazugehörigen Abhängigkeitsdetails. Das ist die Komponenten-Seite Ihres Release-Bestands. Sie verknüpfen diese mit Ihren Build-Protokollen und ausgelieferten Artefakten, und von da an ist die Feststellung, ob die betroffene Komponente vorhanden ist, eher eine einfache Abfrage als ein mühsames Suchen. Wenn eine Sicherheitslücke bestätigt wird, veröffentlicht TuxCare die Daten zur Sicherheitslücke, damit Sie diese mit den Paketversionen in diesem Bestand abgleichen können.
Dann die Korrekturen. Solange der Upstream-Entwickler diese noch bereitstellt, erstellt SecureChain sie aus dem Quellcode neu und liefert direkt einsetzbare Ersatzversionen für die unterstützten Paketversionen, die Sie bereits verwenden. Wenn der Upstream-Entwickler nicht mehr aktiv ist, patcht SecureChain das Paket selbst und sorgt für die Kompatibilität. Wenn eine verborgene Abhängigkeit gepatcht wird, werden abhängige Pakete anhand des Patches neu erstellt – so bleiben Ihre eigenen Manifestdateien davon unberührt. Das Patchen erfolgt gemäß den veröffentlichten Zielreaktionszeiten nach Schweregrad, die im Datenblatt zur Lebenszyklusabdeckung festgelegt sind. Dadurch erhalten Sie für Ihre 72-Stunden-Benachrichtigung einen konkreten Zeitrahmen, den Sie angeben können, zusammen mit den bereits ergriffenen Maßnahmen und den Ihren Nutzern zur Verfügung stehenden Abhilfemaßnahmen. Die Integration, das Testen und die Veröffentlichung des Updates als Ihr eigenes bleiben weiterhin Ihre Aufgabe.
Dann kommt der Teil, bei dem der Upstream-Entwickler aufhört, sich darum zu kümmern. Wenn der Upstream-Entwickler die Pflege einer Version einstellt – sei es, weil eine CVE-Frist versäumt wurde oder weil neun Monate lang kein Release veröffentlicht wurde –, sorgt SecureChain noch weitere drei Monate lang für Patches. Danach übernimmt der „Endless Lifecycle Support“ und portiert Korrekturen so lange zurück, wie Sie die Version nutzen – also so lange, wie es Ihr eigener Supportzeitraum erfordert.
Sicherheitshinweise und Aktualisierungen werden über das TuxCare-Sicherheitsportal als CSAF- und VEX-Dokumente veröffentlicht – mit RSS-Feeds und signierten Metadaten –, sodass sie direkt mit Ihren eigenen betroffenen Versionen und Benutzerhinweisen verknüpft werden können. TuxCare ist zudem eine CVE-Nummerierungsstelle (CNA) und kann daher Schwachstellen innerhalb seines eigenen Zuständigkeitsbereichs CVE-Kennungen zuweisen und diese in seinen Sicherheitshinweisen veröffentlichen, anstatt sich in die Warteschlange einer anderen Stelle einreihen zu müssen.
Das Modell deckt JavaScript, Python, Java, Go, Rust und PHP ab. Ein Katalog, ein SBOM-Modell, ein Korrekturmodell – unabhängig davon, aus welchem Ökosystem ein Paket stammt.
TuxCare ist für die Produkte, die es auf den EU-Markt bringt, ein eigenständiger Hersteller im Sinne der CRA; daher gelten für das Unternehmen dieselben Verpflichtungen gemäß Artikel 14 sowie die Pflicht gemäß Artikel 13 Absatz 6, Schwachstellen in Komponenten vorab zu melden und die Korrekturen weiterzugeben. Was sich für Sie bei diesen beiden Produkten ändert, ist, wie viel Zeit des Zeitfensters zwischen einer Warnmeldung und einer korrigierten Version damit verbracht wird, auf die Behebung einer Schwachstelle in einer fremden Komponente zu warten, sowie die Qualität des Berichts, den Sie einreichen können, während die Uhr läuft.
Vor der nächsten Warnmeldung
Das meiste davon können Sie an einem Nachmittag testen. Nehmen Sie eine aktuelle Version und eine Warnmeldung – eine echte oder eine fiktive. Log4Shell reicht aus, falls Sie davon betroffen waren. Andernfalls gehen Sie von einem KEV-Eintrag für eine Bibliothek aus, die drei Ebenen tiefer in Ihrer Struktur liegt. Verfolgen Sie dann den Weg, den die Warnmeldung durch Ihr Unternehmen nehmen würde, und beantworten Sie jede Frage auf der Grundlage des letzten Vorfalls oder anhand einer realistischen Schätzung, falls so etwas noch nie vorgekommen ist.
Ist in Ihrer Release-Übersicht ersichtlich, ob das Paket in diesem Build enthalten ist? Woher würde der Fix stammen, und hat sich jemand auf einen Termin dafür festgelegt? Wie lange hat Ihr letztes Sicherheitsupdate gedauert – von der gepatchten Komponente bis zum Auslieferung des Updates? Wie würden Ihre Nutzer davon erfahren? Wo immer Sie keine Antwort darauf haben, wird die nächste Sicherheitslücke zuerst eine Schwachstelle finden.
In Ihrem Unternehmen ist jemand dafür zuständig, innerhalb von 24 Stunden nach Eingang dieser Meldung zu handeln. Die Vorgehensweise gibt an, ob diese Person rechtzeitig klären kann, ob Artikel 14 zur Anwendung kommt, und gegebenenfalls den entsprechenden Antrag stellen kann.
