Senden Sie innerhalb von Stunden eine erste Stellungnahme, eine bestätigte Antwort, sobald Sie sie belegen können, und eine Folgemeldung, sobald sich etwas ändert. Sagen Sie, was Sie wissen, was Sie noch prüfen und wann Sie das nächste Update senden. Stützen Sie jedes „nicht betroffen“ auf das, was Ihre Builds während des Angriffszeitraums tatsächlich installiert haben, nicht auf das heutige Lockfile.
Dieser Beitrag behandelt, was Sie sagen, wann und mit welchen Belegen. Für die Untersuchung selbst, also wie Sie herausfinden, ob eine verwundbare Komponente in Ihren Produkten steckt und seit wann, lesen Sie Sind wir von einer CVE betroffen?.
Warum Kunden Sie fragen und nicht die Paket-Registry
In der Woche nach einem viel beachteten Angriff, so erzählte uns ein kleiner Softwarelieferant, schickten ihm Kunden Textnachrichten: Sind Ihre Sachen sicher? Sind meine Sachen sicher? Seine Kunden verarbeiten sensible Daten, sein Team hat keinen Sicherheitsspezialisten, und die Frage brauchte noch am selben Tag eine Antwort.
Kunden fragen nicht, ob ein Paket kompromittiert wurde. Das haben die Registry und die Sicherheitsforscher bereits gesagt. Sie fragen, ob das, was Sie ihnen geliefert haben, es enthält, denn Ihr Produkt ist ihre Exposition. Sie haben eigene Kunden, Auditoren oder Aufsichtsbehörden, die ihnen dieselbe Frage stellen. In regulierten Lieferketten wie Halbleitern, Industrieausrüstung und Gesundheitswesen ist die Frage eine vertragliche, keine Neugier.
Sie fragen auch erneut, wenn sich Ihre Antwort nicht überprüfen lässt. „Wir sind nicht betroffen“ ohne etwas dahinter ist ein Versprechen; „Wir haben jeden Release-Build vom 24. bis 31. März geprüft, und keiner hat die betroffenen Versionen installiert“ ist eine Aussage, auf die sie sich verlassen können.
Vier aktuelle Angriffe und die Frage, die jeder aufwarf
Die richtige Antwort hängt davon ab, wie der Angriff funktionierte, deshalb reicht eine Vorlage allein nicht. Bei jedem dieser Angriffe entscheidet eine Tatsache, was „betroffen“ für einen Lieferanten bedeutet.
Backdoor in xz Utils (CVE-2024-3094), offengelegt am 29. März 2024. Andres Freund fand eine Backdoor in den xz-Versionen 5.6.0 und 5.6.1. Die Release-Tarballs enthielten Code, der nicht im Git-Repository stand, und dieser schleuste die Backdoor während des Builds ein. Die NVD und Red Hat bewerten sie beide mit 10.0 nach CVSS 3.1. Sie erreichte vor allem Rolling- und Testing-Distributionen: Debian testing, unstable und experimental, Fedora Rawhide und 41, openSUSE Tumbleweed und Kali, während stabile Releases nicht betroffen waren. Die Frage, die sie aufwarf: Enthält ein Image oder Gerät, das wir ausgeliefert haben, xz 5.6.0 oder 5.6.1, und welches Basis-Image hat jeder Build verwendet?
Der npm-Wurm Shai-Hulud, in Wellen seit September 2025. Infizierte Pakete führen bei der Installation ein Skript aus, das npm-, GitHub- und Cloud-Zugangsdaten stiehlt und damit infizierte Versionen weiterer Pakete veröffentlicht. Die Frage, die er aufwarf: Hat ein CI-Job eine infizierte Version installiert, und lagen unsere Veröffentlichungs-Tokens offen, was uns selbst zum Verbreiter machen würde? Unser Eintrag zu Shai-Hulud listet jede Welle auf und zeigt, wie Sie prüfen.
LiteLLM auf PyPI, 24. März 2026. Die Versionen 1.82.7 und 1.82.8 wurden direkt auf PyPI hochgeladen, mit Code zum Diebstahl von Zugangsdaten, der nie im GitHub-Repository des Projekts stand. In 1.82.8 führte eine .pth-Datei die Schadfunktion aus, sobald irgendein Python-Interpreter startete, nicht nur beim Import von LiteLLM; sie sammelte Umgebungsvariablen, SSH-Schlüssel, Cloud-Zugangsdaten und Kubernetes-Secrets. HiddenLayer ordnet den Angriff TeamPCP zu, die in jenem Monat auch Tools von Trivy und Checkmarx trafen. LiteLLMs eigenes Advisory nennt zwei Erklärungen für den ersten Zugriff: Es führt die Kompromittierung auf die Trivy-Abhängigkeit im CI-Workflow für Sicherheitsscans zurück und schreibt, das PyPI-Konto eines Maintainers sei möglicherweise kompromittiert worden. Selbst der Expositionszeitraum unterscheidet sich innerhalb desselben Advisorys: an einer Stelle etwa 40 Minuten, an einer anderen 10:39 bis 16:00 UTC. Die Frage, die er aufwarf: Hat ein Build oder ein ausgelieferter Container diese Versionen enthalten, und welche Secrets lagen in dieser Umgebung vor?
axios auf npm, 31. März 2026. Ein Angreifer übernahm das npm-Konto eines Maintainers und veröffentlichte axios 1.14.1 und 0.30.4, die eine Abhängigkeit hinzufügten, [email protected], deren Installationsskript einen Remote-Access-Trojaner für macOS, Windows und Linux ablegte. Datadog gibt den Zeitraum mit 00:21 bis 03:25 UTC an; laut Snyk wurden die Versionen um 03:29 UTC entfernt. Die Frage, die er aufwarf: Hat ein Build in diesem Zeitraum diese Versionen aufgelöst? Ein vor dem Zeitraum committetes Lockfile beantwortet das mit „nein“ für Builds, die es verwendet haben, und sagt nichts über Builds, die npm install ohne es ausgeführt haben.
| Angriff | Ökosystem | Betroffene Versionen | Zeitraum | Was „betroffen“ für einen Lieferanten bedeutet |
|---|---|---|---|---|
| xz Utils | Linux-Distributionen | 5.6.0, 5.6.1 | Wochen, bis zur Offenlegung am 29. März 2024 | Sie haben es ausgeliefert, in einem Image oder Gerät auf Basis einer betroffenen Distribution |
| Shai-Hulud | npm | Hunderte Pakete, je Welle | Stunden bis Tage je Welle | Sie haben damit gebaut, und Ihre Tokens haben es womöglich verbreitet; vielleicht haben Sie es auch ausgeliefert |
| LiteLLM | PyPI | 1.82.7, 1.82.8 | 24. März 2026, ab 10:39 UTC (Quellen uneins über das Ende) | Sie haben damit gebaut oder es ausgeliefert, und Secrets in dieser Umgebung wurden womöglich gestohlen |
| axios | npm | 1.14.1, 0.30.4 | 31. März 2026, etwa 00:21 bis 03:25 UTC | Sie haben im Zeitraum damit gebaut; der Trojaner lief auf der Build-Maschine |
Dieselben Fragen stellen sich bei einer kritischen Schwachstelle, die kein Lieferkettenangriff ist. Als PHP2Shell im Oktober 2026 ausgenutzt wurde, fragten die Kunden jedes Produkts, das PHP mitliefert, welche ihrer Versionen ein betroffenes PHP enthalten. Die folgenden Schritte gelten unverändert.
Die Antwort hat drei Stufen
| Stufe | Wann | Was Sie senden |
|---|---|---|
| Erste Stellungnahme | Innerhalb von Stunden nach der Nachricht | Was Sie wissen, was Sie prüfen, wann Sie das nächste Update senden |
| Bestätigte Antwort | Sobald Sie es belegen können, meist am ersten Tag | „Nicht betroffen“ für benannte Versionen oder „betroffen“ mit dem, was zu tun ist |
| Folgemeldung | Wenn der Fix ausgeliefert wird, wenn Sie etwas Neues erfahren, wenn Sie den Fall schließen | Dieselbe Mitteilung, überarbeitet |
Die erste Stunde: die erste Stellungnahme
Eine erste Stellungnahme (Holding Statement) ist die erste öffentliche Aussage, die Sie machen, bevor die Fakten vorliegen. Sagen Sie schnell etwas, das stimmt. Schweigen wird mit Vermutungen gefüllt, und ein Kunde, der nichts von Ihnen hört, nimmt an, dass Sie es nicht bemerkt haben.
- Wer und wo. Ein namentlich genannter Absender, im Kanal, den der Kunde genutzt hat, dazu Ihre Sicherheitsseite. Ein gemeinsamer Text ist besser als spontane Antworten: Er bleibt einheitlich, und die Rechtsabteilung prüft ihn nur einmal.
- Was hineingehört. Dass Sie von dem Angriff wissen, dass Sie Ihre Produkte und Build-Systeme prüfen, was Sie bisher wissen, wann das nächste Update kommt und an wen man sich wenden kann.
- Was nicht hineingehört. „Wir sind nicht betroffen“, bevor Sie geprüft haben, Spekulationen über den Angreifer oder Schuldzuweisungen.
Vorlage 1: erste Stellungnahme
Betreff: [Name des Angriffs]: unsere erste Stellungnahme
Uns ist die gemeldete Kompromittierung von [Paket oder Projekt] bekannt ([betroffene Versionen], veröffentlicht am [Datum]). Unser Sicherheitsteam prüft derzeit jedes Release von [Produkt] sowie unsere Build-Systeme auf die betroffenen Versionen. Bislang haben wir [in den geprüften Produkten keine betroffenen Versionen gefunden / die Prüfung noch nicht abgeschlossen]. Wir senden Ihnen bis [Datum und Uhrzeit, Zeitzone] ein Update. Bei Fragen in der Zwischenzeit wenden Sie sich bitte an [Name, Adresse des Sicherheitskontakts]. Bis zum Abschluss der Prüfung äußern wir uns nicht spekulativ zu möglichen Auswirkungen.Für eine Textnachricht oder einen Chat genügen zwei Sätze:
Wir wissen von der Kompromittierung durch [Name des Angriffs] und prüfen gerade jedes Release von [Produkt] und unsere Builds. Eine bestätigte Antwort erhalten Sie von uns bis [Uhrzeit].Lassen Sie alle drei Vorlagen juristisch freigeben, bevor Sie sie brauchen.
Der erste Tag: bestätigen, mit Belegen
Zwei Ergebnisse sind möglich, und jedes braucht eigene Belege. Für eine Antwort „nicht betroffen“ sammeln Sie:
- das betroffene Paket und die betroffenen Versionen, aus dem Advisory oder dem Bericht der Sicherheitsforscher
- Ihre Produkte und die Versionen, die Kunden tatsächlich einsetzen
- für jede dieser Versionen den Build, der sie erzeugt hat, und die Aufzeichnung dessen, was dieser Build installiert hat, nicht das aktuelle Lockfile
- jeden Build, der während des Angriffszeitraums lief, einschließlich CI-Jobs, die nie ein Release erzeugt haben
- bei Würmern, die Tokens stehlen: ob in Jobs, die den Schadcode ausgeführt haben könnten, CI-Secrets vorhanden waren
Sind wir von einer CVE betroffen? erklärt, wie Sie jeden dieser Punkte ermitteln.
Jede Aussage, die Sie machen, muss durch etwas gedeckt sein, das Sie vorzeigen können:
| Aussage | Was Sie vorzeigen können müssen | Was nicht genügt |
|---|---|---|
| „Produkt X Version Y enthält Paket Z nicht“ | Die aus dem Release-Build von Version Y aufgezeichnete SBOM | Ein Scan des aktuellen Repositorys |
| „Keiner unserer Builds hat die kompromittierten Versionen installiert“ | Installationsaufzeichnungen für jeden Build im Zeitraum | Ein Lockfile, das manche Jobs umgehen |
| „Unsere Release-Pipeline wurde nicht kompromittiert“ | Aufzeichnungen zu Netzwerkverbindungen und Secret-Nutzung im Zeitraum | Das Ausbleiben von Alarmen |
| „Kunden mit Version Y sind nach dem Upgrade sicher“ | Die Aufzeichnung des behobenen Builds und die rotierten Zugangsdaten | Ein Changelog-Eintrag |
Vorlage 2: nicht betroffen
Betreff: [Name des Angriffs]: [Produkt] ist nicht betroffen
Wir haben unsere Prüfung zur Kompromittierung von [Paket] ([betroffene Versionen]) abgeschlossen. Die folgenden Versionen von [Produkt] sind nicht betroffen: [Liste der geprüften Produkte und Versionen]. Wir haben jeden Release-Build und jeden CI-Build geprüft, der zwischen dem [Startdatum] und dem [Enddatum] lief. Diese Aussage stützt sich auf die Aufzeichnung der Komponenten, die jeder Release-Build installiert hat, nicht auf einen Scan unseres aktuellen Quellcodes. Keiner dieser Builds hat die betroffenen Versionen installiert. Wenn Sie die Belege benötigen, senden wir Ihnen gern die SBOM für die von Ihnen eingesetzten Versionen oder eine VEX-Aussage. Sollten wir etwas erfahren, das diese Einschätzung ändert, informieren wir Sie. Kontakt: [Name, Adresse des Sicherheitskontakts].Sagen Sie „nicht betroffen“ für benannte Versionen. Schreiben Sie nie „100 % sicher“. Fragt der Kunde dann nach der vollständigen SBOM, lesen Sie SBOM-Anfragen von Kunden beantworten.
Vorlage 3: betroffen, mit Abhilfe
Betreff: [Name des Angriffs]: Handlungsbedarf für [Produkt] Versionen [x bis y]
Unsere Prüfung zur Kompromittierung von [Paket] hat ergeben, dass die Versionen [x bis y] von [Produkt] betroffen sind. Der erste betroffene Build wurde am [Datum] erzeugt; Version [z], veröffentlicht am [Datum], enthält [Paketversion] nicht mehr.
Was das bedeutet: [Risiko in einfacher Sprache, zum Beispiel „eine in diesen Versionen installierte Komponente kann Zugangsdaten von dem System, auf dem sie läuft, an einen externen Server senden“].
Was Sie jetzt tun sollten: Führen Sie ein Upgrade auf [Produkt] [z] durch. Falls Sie nicht sofort upgraden können, [Abhilfe, zum Beispiel ausgehende Verbindungen zu den aufgeführten Hosts blockieren]. Wenn Sie die Versionen [x bis y] von [Produkt] in [Umgebung] eingesetzt haben, rotieren Sie bitte [Zugangsdaten oder Schlüssel], auf die diese Zugriff hatten.
Was wir unternommen haben: Wir haben die betroffenen Versionen aus unseren Builds entfernt, [Produkt] aus sauberen Abhängigkeiten neu gebaut, die Zugangsdaten unserer Build-Systeme rotiert und [weitere Maßnahmen]. [Soweit erforderlich, haben wir die zuständigen Behörden informiert.]
Das nächste Update senden wir Ihnen bis [Datum] oder früher, falls sich etwas ändert. Kontakt: [Name, Adresse des Sicherheitskontakts].Eine Mitteilung „betroffen“ kann auch eine gesetzliche Pflicht sein; siehe den Abschnitt zu Meldepflichten unten.
Wo VEX und CSAF ins Spiel kommen. Eine Aussage „nicht betroffen“ oder „behoben“ lässt sich als VEX veröffentlichen, damit die Scanner der Kunden das Paket nicht mehr melden. Größere Kunden erwarten unter Umständen zusätzlich ein maschinenlesbares Advisory; CSAF ist das Format, nach dem die meisten von ihnen fragen.
Folgemeldung: den Fall sauber abschließen
Senden Sie eine Folgemeldung, wenn der Fix ausgeliefert wird, wenn Ihre Untersuchung etwas Neues ergibt, und eine abschließende Mitteilung, wenn der Fall geschlossen wird. Führen Sie ein Advisory pro Vorfall und überarbeiten Sie es, statt jedes Mal ein neues zu senden (aktualisieren, nicht ersetzen). Halten Sie fest, wem Sie wann was mitgeteilt haben: Das nächste Audit oder der nächste Sicherheitsfragebogen eines Kunden wird danach fragen.
Was Sie sagen, wenn Sie es noch nicht wissen
„Wir wissen es noch nicht“ schafft mehr Vertrauen als ein „nicht betroffen“, das Sie zurücknehmen müssen. Formulierungen, die ehrlich sind, ohne jemanden zu beunruhigen:
- „Wir haben [Paket] in [den bisher geprüften Produkten] nicht gefunden. Wir prüfen noch [die übrigen Produkte oder Build-Systeme] und melden uns bis [Uhrzeit] bei Ihnen.“
- „Die von Ihnen eingesetzten Versionen wurden vor dem Angriffszeitraum gebaut. Wir bestätigen gerade, dass kein späterer Build sie ersetzt hat.“
- „Wir prüfen, ob eines unserer Build-Systeme die betroffenen Versionen ausgeführt hat. Ihr installiertes Produkt ist eine separate Frage, und wir beantworten beide.“
Formulierungen, die Sie vermeiden sollten:
- „Keinerlei Auswirkungen“
- „Vollständig sicher“
- „Von keinem Lieferkettenangriff betroffen“
- „Unser Scanner hat nichts gefunden“
Wenn der Angriff zur Meldepflicht wird
Wenn Sie Produkte mit digitalen Elementen in der EU verkaufen, gelten die Meldepflichten des Cyber Resilience Act seit dem 11. September 2026, dem Tag, an dem ENISA die Single Reporting Platform gestartet hat. Eine aktiv ausgenutzte Schwachstelle in Ihrem Produkt oder ein schwerwiegender Sicherheitsvorfall mit Auswirkungen auf seine Sicherheit löst eine Frühwarnung innerhalb von 24 Stunden nach Kenntnisnahme aus, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht, jeweils über die Plattform an Ihr koordinierendes CSIRT und ENISA. Der CRA-Leitfaden führt durch die Schritte.
Ob eine kompromittierte Abhängigkeit, die Sie ausgeliefert haben, oder eine Kompromittierung Ihrer eigenen Build-Pipeline diese Definitionen erfüllt, müssen Sie mit Ihrer Rechtsberatung beurteilen, nicht dieser Beitrag. Die Verordnung definiert die Begriffe:
- Eine „aktiv ausgenutzte Schwachstelle“ ist „eine Schwachstelle, bei der zuverlässige Beweise dafür vorliegen, dass ein böswilliger Akteur sie ohne Erlaubnis des Systemeigentümers in einem System ausgenutzt hat“ (Artikel 3 Nummer 42).
- Ein Sicherheitsvorfall ist schwerwiegend, wenn „er die Fähigkeit eines Produkts mit digitalen Elementen, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, beeinträchtigt oder beeinträchtigen kann“, oder wenn „er zur Einschleusung oder Ausführung von Schadcode“ im Produkt oder in den Systemen eines Nutzers „geführt hat oder führen kann“ (Artikel 14 Absatz 5).
Artikel 14(8) fügt eine Pflicht gegenüber den Nutzern hinzu: die betroffenen Nutzer und gegebenenfalls alle Nutzer über die Schwachstelle oder den Vorfall und über mögliche Abhilfemaßnahmen zu informieren, „gegebenenfalls in einem strukturierten, maschinenlesbaren Format, das sich leicht automatisch verarbeiten lässt“. Vorlage 3 kann ein Teil der Erfüllung dieser Pflicht sein.
Andere Regelwerke gelten ebenfalls. Nach NIS2 melden wesentliche und wichtige Einrichtungen erhebliche Sicherheitsvorfälle ihrem CSIRT oder der zuständigen Behörde, und viele Kundenverträge enthalten eigene Benachrichtigungsklauseln mit eigenen Fristen.
Seien Sie vor dem nächsten Angriff bereit
- Eine Aufzeichnung dessen, was jeder Release-Build installiert hat, aufbewahrt für den Supportzeitraum des Produkts (SBOMs zur Build-Zeit).
- Eine Liste, welche Kunden welche Versionen einsetzen.
- Die drei Vorlagen oben, von der Rechtsabteilung freigegeben.
- Ein namentlich genannter Absender und ein Kanal für jede Art von Kunde.
- Eine Sicherheitsseite und eine
security.txt-Datei, in der die Updates erscheinen (koordinierte Offenlegung von Schwachstellen). - Egress-Kontrolle in der CI, damit ein kompromittiertes Paket keine Secrets an einen Host senden kann, den der Build nicht braucht (Egress-Policy für GitHub Actions).
Für Vorfälle, die zu Hunderten statt einzeln eintreffen, lesen Sie ein PSIRT skalieren.
Wo CRACI hilft
Die Belegtabelle oben verlangt immer wieder dasselbe: eine Aufzeichnung dessen, was jeder Release-Build installiert hat. Genau das bewahrt CRACI auf. CRACI führt Ihre GitHub-Actions-Builds auf eigenen Runnern aus und zeichnet jedes Paket auf, das jeder Job tatsächlich geladen hat, einschließlich der von Installationsskripten abgerufenen und aus Caches wiederhergestellten Pakete. Die SBOM jedes früheren Builds wird aufbewahrt, sodass „Hat ein Build im Zeitraum axios 1.14.1 installiert?“ aus der Build-Historie beantwortet wird, mit dem Zeitraum, in dem Sie betroffen waren, so weit Ihre Aufbewahrungsfrist zurückreicht.
Bekannte bösartige Releases mit veröffentlichter CVE, etwa die xz-Backdoor, werden wie jede andere Schwachstelle markiert, und ein Policy Gate kann Builds blockieren, die sie enthalten. Ein neues bösartiges Paket anhand seines Verhaltens oder seiner Reputation erkennt CRACI nicht.
Die Egress-Policy von CRACI blockiert Verbindungen zu Hosts, die ein Build nicht braucht, und begrenzt so, was ein bösartiges Installationsskript nach außen senden kann, selbst bei einem Angriff, den noch niemand gesehen hat. Wenn ein Kunde nach den Belegen fragt, können Sie die SBOM für die von ihm eingesetzten Versionen als CycloneDX oder SPDX exportieren und senden. CRACI unterstützt VEX.
Beantworten Sie „Waren wir betroffen?“ aus Ihrer Build-Historie, oder lesen Sie mehr darüber, wie Lieferkettenangriffe funktionieren.
Wann CRACI nicht die Antwort ist
- Sie brauchen Hilfe bei der Kommunikation selbst. PR- und Rechtsberatung sind eine andere Aufgabe.
- Die betroffene Software wurde nicht auf CRACI gebaut. CRACI zeichnet GitHub-Actions-Builds auf, die auf seinen Runnern laufen; andere CI-Systeme stehen auf der Roadmap.
- Es geht um das Produkt eines Herstellers, das Sie nicht selbst gebaut haben. Hersteller-SBOMs lassen sich zu CRACI hinzufügen, aber die Antwort ist nur so gut wie die SBOM des Herstellers.
- Sie müssen ein brandneues bösartiges Paket erkennen, bevor es ein Advisory gibt. CRACI markiert bekannte bösartige Releases, sobald ein Advisory mit CVE veröffentlicht ist; Malware anhand von Verhalten oder Reputation erkennt es nicht (auf Zero-Day-Schwachstellen reagieren).
Häufig gestellte Fragen
Was sage ich Kunden, wenn ein Lieferkettenangriff in den Nachrichten ist?
Senden Sie innerhalb von Stunden eine erste Stellungnahme: dass Sie von dem Angriff wissen, dass Sie Ihre Produkte und Builds prüfen, was Sie bisher wissen und wann Sie das nächste Update senden. Lassen Sie eine bestätigte Antwort für benannte Produktversionen folgen, sobald Sie sie mit Build-Aufzeichnungen belegen können, und eine Folgemeldung, sobald sich etwas ändert.
Was sollte eine erste Stellungnahme enthalten?
In einem Satz, was passiert ist, dass Sie Ihre Produkte und Build-Systeme prüfen, was Sie bisher gefunden haben, den Zeitpunkt des nächsten Updates und einen Kontakt. Sie darf nicht „nicht betroffen“ sagen, bevor Sie geprüft haben, nicht über den Angreifer spekulieren und niemandem die Schuld geben.
Wie sage ich „Wir sind nicht betroffen“, ohne zu viel zu versprechen?
Nennen Sie die geprüften Produkte und Versionen, den Zeitraum der geprüften Builds und die verwendeten Belege, etwa die Aufzeichnung der Komponenten, die jeder Release-Build installiert hat. Sagen Sie „nicht betroffen“ für diese Versionen, bieten Sie die SBOM oder eine VEX-Aussage an und sagen Sie ein Update zu, falls sich etwas ändert. Vermeiden Sie „100 % sicher“ oder „vollständig sicher“.
Was sollte eine Mitteilung „Wir waren betroffen“ an Kunden enthalten?
Welche Produkte und Versionen betroffen sind, seit wann und bis zu welcher behobenen Version, das Risiko in einfacher Sprache, was der Kunde jetzt tun sollte (Upgrade, Zugangsdaten rotieren, Hosts blockieren), was Sie bereits unternommen haben, wann das nächste Update kommt und an wen man sich wenden kann.
Welche Belege sollten eine Aussage „nicht betroffen“ stützen?
Für jede Version, die Kunden einsetzen, die Aufzeichnung dessen, was der Build installiert hat, der sie erzeugt hat, nicht das heutige Lockfile. Dazu die Aufzeichnungen jedes Builds, der während des Angriffszeitraums lief, und bei Angriffen, die Zugangsdaten stehlen, ob in Jobs, die den Schadcode ausgeführt haben könnten, Secrets vorhanden waren.
Muss ich einen Lieferkettenangriff nach dem Cyber Resilience Act melden?
Möglicherweise. Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen, die in der EU verkauft werden, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Produktsicherheit melden: eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht. Ob ein bestimmter Angriff darunter fällt, beurteilen Sie mit Ihrer Rechtsberatung.
Wie schnell sollten wir Kunden antworten?
Innerhalb von Stunden mit einer ersten Stellungnahme, auch wenn sie nur sagt, dass Sie prüfen und wann Sie das nächste Update senden. Die bestätigte Antwort folgt, sobald Sie sie belegen können. Ein schnelles, ehrliches „Wir prüfen gerade“ schafft mehr Vertrauen als ein spätes „nicht betroffen“.
