Cooldowns mit Software-Stücklisten (SBOMs)
Ritesh Noronha
Im September 2025 phishte ein Angreifer einen Maintainer namens „qix“ und schleuste bösartige Updates in chalk, debug und ansi-styles ein – Pakete mit insgesamt über 2,1 Milliarden wöchentlichen Downloads. Die bösartigen Versionen waren etwa zwei Stunden lang live auf npm, bevor die Community sie entdeckte und sie entfernt wurden.
Zwei Stunden. Wenn Ihre CI-Pipeline in diesem Zeitfenster lief und Ihre Lockfile für den neuesten Patch offen war, haben Sie Malware ausgeliefert.
Das ist das Muster. Es wiederholt sich mittlerweile alle paar Wochen:
Nx (August 2025) – bösartige Pakete waren 4–5 Stunden live, SSH-Schlüssel und GitHub-Token wurden vor der Entfernung exfiltriert
Shai-Hulud-Wurm (Sept.–Nov. 2025) – selbstreplizierender npm-Wurm verbreitete sich vor der Eindämmung über mehr als 25.000 Repositories
LiteLLM (März 2026) – bösartige PyPI-Releases, die eine
.pth-Datei zur automatischen Ausführung und zum Diebstahl von Anmeldedaten nutzten, innerhalb weniger Stunden zurückgezogenAxios (31. März 2026) – bösartige Versionen eines Pakets mit mehr als 100 Millionen wöchentlichen Downloads, die eine Verbindung zu einem von Sapphire Sleet betriebenen C2-Server herstellten
ua-parser-js, event-stream, colors, faker – die historische Liste von Kompromittierungen, die in jedem Vortrag über Supply-Chain-Sicherheit zitiert wird
In jedem einzelnen Fall existierte die bösartige Version nur für Stunden, nicht für Tage in der Registry. Und in jedem Fall wäre jeder, der mit dem Laden der neuen Version einfach gewartet hätte, unbeschadet geblieben.
Das ist die Idee der Abkühlphase (Cooldown), und sie ist nicht neu. Was jedoch neu ist, ist, dass Paketmanager endlich – verspätet und ungleichmäßig – damit begonnen haben, Cooldown-Funktionen nativ auszuliefern. Zudem ist mittlerweile klar, dass die Paketmanager-Ebene allein nicht ausreicht. Hier kommen SBOMs ins Spiel.
Die Paketmanager-Cooldown-Landschaft (Stand April 2026)
Zwischen September 2025 und Februar 2026 haben sieben große Paketmanager Cooldown-Funktionen für Abhängigkeiten eingeführt:
Paketmanager | Flag / Einstellung | Version |
|---|---|---|
pnpm |
| 10.16+ |
Yarn |
| 4.10.0 |
Bun |
| 1.3 |
Deno |
| 2.6 |
uv |
| 0.9.17 |
pip |
| 26.0 |
npm |
| 11.10.0 |
Das ist echter Fortschritt. Es ist aber auch extrem fragmentiert. Jedes Ökosystem hat sein eigenes Flag, seine eigene Voreinstellung (meistens keine) und seine eigene Semantik dafür, was "Alter" bedeutet. Organisationen mit Polyglot-Stacks – und die meisten modernen Organisationen sind polyglott – müssen Cooldowns nun an sieben verschiedenen Stellen und in sieben verschiedenen CI-Systemen konfigurieren und hoffen, dass kein Team darauf vergisst.
Noch wichtiger ist, dass der Cooldown des Paketmanagers beim Installieren auf dem Laptop des Entwicklers oder auf einem CI-Runner erzwungen wird. Das bedeutet:
Es handelt sich um ein Opt-in pro Repository. Eine falsch konfigurierte
package.jsongenügt, und Sie sind ungeschützt.Es gilt nicht für bereits erstellte Artefakte. Wenn ein Container-Image aus der Vorwoche eine schädliche Abhängigkeit gezogen hat, kann der Cooldown des Paketmanagers Sie nicht nachträglich warnen.
Es kann unbemerkt umgangen werden – durch ein
--no-cooldown-Flag, einen.npmrc-Override, den ein wohlmeinender Entwickler eingecheckt hat, oder einen CI-Cache, der die Prüfung überspringt.Es hilft nicht bei Software von Drittanbietern, die Sie nicht selbst erstellt haben – wie Lieferanten-Software, Container-Basis-Images oder Firmware.
Es gibt keinen zentralen Audit-Trail. Ein Sicherheitsteam kann nicht fragen: „Welche unserer 400 Dienste haben im letzten Quartal eine Abhängigkeit zugelassen, die jünger als 48 Stunden war?“, und eine Antwort erhalten.
Dies ist eine Governance-Lücke, keine Werkzeug-Lücke. Und genau für Governance-Lücken sind SBOMs da.
SBOMs als Security-Richtlinie
Eine SBOM ist eine Build-unabhängige, Ökosystem-agnostische Bestandsaufnahme dessen, was Sie tatsächlich ausgeliefert haben. Das ist ein einzigartig nützlicher Ausgangspunkt für die Durchsetzung von Abkühlfristen (Cooldowns):
Standardmäßig mehrsprachig (Polyglot). Eine einzige SBOM-Richtlinie kann Komponenten über npm, PyPI, Maven, Go, Cargo, NuGet, OCI-Images und eingebettete Firmware hinweg bewerten – mit einer einzigen Regel statt sieben Konfigurationen.
Nach dem Build, nicht vor der Installation. Sie bewerten das, was tatsächlich im Artefakt gelandet ist, nicht das, was in der
package.jsonvorgesehen war. Kein "Die Lock-Datei sagte das eine, der Build machte das andere" mehr.Zentral, prüfbar, durchsetzbar. Richtlinien leben an einem Ort. Verstöße erzeugen Protokolle. Verstöße sind für Sicherheit, Compliance und Entwicklung gleichzeitig sichtbar.
Shift-Left und Shift-Right. Dieselbe Regel kann in der CI ausgeführt werden, um ein Release zu blockieren, und auf bestehende Produktionsartefakte angewendet werden, um Komponenten zu finden, die erst nach dem Deployment riskant wurden.
Deckt Software ab, die Sie nicht selbst kompiliert haben. Hersteller-Lieferungen und Basis-Images werden heutzutage mit SBOMs ausgeliefert (CRA, FDA, EO 14028 weisen alle in diese Richtung). Eine Abkühlfrist auf Paketmanager-Ebene kann diese nicht überprüfen. Eine Abkühlfrist auf SBOM-Ebene hingegen schon.
Der Paketmanager ist der Ort, an dem Sie die Ausführung von Abkühlfristen bevorzugen – dort ist es am günstigsten. Die SBOM ist der Ort, an dem Sie beweisen, dass die Abkühlfristen eingehalten wurden – dort ist sie maßgebend. Beide Ebenen sind nützlich. Aber nur eine ist ausreichend.
Einführung von COMPONENT_PUBLISHED_AGE
Die Plattform von Interlynk liefert nun ein Richtlinien-Subjekt namens COMPONENT_PUBLISHED_AGE aus. Es drückt genau eine Idee aus: „Suche für jede Komponente in einer SBOM heraus, wann genau diese Version in ihrer Paketregistrierung veröffentlicht wurde, und vergleiche dieses Datum mit einem Richtlinienschwellenwert.“
Drei Operatoren werden unterstützt:
Operator | Bedeutung | Beispiel |
|---|---|---|
| Die Komponente wurde innerhalb der letzten N Tage veröffentlicht. Verstößt. |
|
| Die Komponente ist älter als N Tage. Verstößt. |
|
| Die Komponente fällt in ein Alterungsfenster von |
|
Die Grenze ist exklusiv — LESS_THAN 7 wird bei einer Komponente, die vor genau 7 Tagen veröffentlicht wurde, nicht ausgelöst. Dies entspricht jedem anderen altersbasierten Subjekt in der Plattform (Alter des Vulnerability-Status, Alter der Zuweisung usw.), sodass es keine Überraschungen gibt.
LESS_THAN ist das Cooldown-Primitiv. MORE_THAN ist das Gegenteil — Erkennung von Veraltung, falls eine Komponente aufgegeben wurde und das Ökosystem sich weiterentwickelt hat. RANGE ist die zweiseitige Variante, die nützlich ist, um eine „grüne Zone“ zu definieren (z. B. „Abhängigkeiten sollten mindestens 14 Tage alt, aber nicht älter als 18 Monate sein“).
Wenn die Richtlinie ausgeführt wird, erzeugt jede Komponente, deren package_version.published_at in das verbotene Fenster fällt, eine PolicyRuleViolation, die auf diese spezifische Komponente beschränkt ist, mit:
Dem PURL und der Version der Komponente
Dem genauen Veröffentlichungszeitstempel
Der Regel, die übereingestimmt hat
Der SBOM (und somit dem Projekt, dem Release und dem Artefakt), in der sie erschienen ist
Verstöße fließen durch dieselbe Berichts-, Ticket- und Webhook-Pipeline wie jedes andere Richtlinienergebnis – so kann ein verpasster Cooldown automatisch ein Jira-Ticket öffnen, den Merge eines GitHub-PRs blockieren oder das Sicherheitsteam alarmieren.
Wo Cooldowns geholfen hätten – Eine Chronologie
Hier ist das kontrafaktische Szenario „Was wäre, wenn wir eine 48-stündige Abkühlungszeit hätten?“, angewendet auf die jüngsten Angriffe:
Angriff | Veröffentlicht → Zurückgezogen | Ergebnis mit einer 48-stündigen Abkühlungszeit |
|---|---|---|
Nx (Aug 2025) | ~4–5 Stunden | Nicht übernommen |
chalk / debug / ansi-styles (Sep 8) | ~2 Stunden | Nicht übernommen |
Shai-Hulud Wurm (Sep–Nov 2025) | ~Stunden pro Version | Massiv reduzierter Schadensradius |
LiteLLM (März 2026) | Stunden | Nicht übernommen |
Axios (31. Mrz 2026) | Stunden | Nicht übernommen |
event-stream (historisch) | Tage | Trotzdem übernommen — Abkühlungszeit allein unzureichend |
ua-parser-js (historisch) | ~12 Stunden | Nicht übernommen |
Die ehrliche Einschränkung: Eine Abkühlungszeit ist kein Allheilmittel. Der event-stream-Angriff hielt monatelang an, bevor ihn jemand bemerkte – ein Abwarten von 48 Stunden hätte da nicht geholfen. Abkühlungszeiten schützen vor der Kategorie der schnelllebigen Supply-Chain-Angriffe, was heutzutage zufällig die Mehrheit von ihnen ist. Sie schützen nicht vor langfristigen, heimlichen Kompromittierungen, dem geduldigen Übernehmen von Maintainer-Accounts oder Angriffen auf Build-Systeme wie dem Trivy-Tag-Hijacking. Dafür sind andere Kontrollmechanismen erforderlich.
Aber wenn Abkühlungszeiten selbst 70 % der in freier Wildbahn vorkommenden Angriffsmuster bei praktisch null Betriebskosten abfangen – was die jüngsten Vorfalldaten nahelegen –, dann ist das eine enorme Rendite für eine einzige Richtlinienregel.
Warum „Shift Left mit SBOM“ die richtige Architektur ist
Es gibt eine berechtigte Kritik an Cooldowns (Abklingzeiten), die am deutlichsten von Cal Paterson formuliert wurde: Sie funktionieren, indem sie als Trittbrettfahrer auf Kosten der weniger geschützten Nutzer agieren. Wenn jeder 48 Stunden wartet, erkennt niemand das schädliche Paket, weil es niemand ausführt. Die Erkennung erfolgt durch die Early Adopters, die sich die Finger verbrennen.
Die vorgeschlagene systemische Lösung ist eine Upload-Warteschlange in der Registry – die Veröffentlichung findet statt, aber die Verteilung wird verzögert, während Scanner laufen. Debian macht das seit Jahrzehnten. npm, PyPI und Co. tun das nicht. Bis sie es tun, müssen sich die einzelnen Organisationen selbst schützen.
SBOM-Ebenen-Cooldowns sind eine bessere individuelle Verteidigung als Paketmanager-Cooldowns, und zwar aus denselben oben genannten Gründen: einheitlich, auditierbar, polyglott, deckt Artefakte von Drittanbietern ab. Und da SBOMs als Teil des Builds generiert werden, bevor das Artefakt freigegeben wird, liegt der Durchsetzungspunkt so weit links wie möglich, ohne an einen bestimmten Paketmanager gekoppelt zu sein.
CI baut das Artefakt. Code wird kompiliert, Abhängigkeiten werden aufgelöst, Container-Images werden zusammengestellt.
SBOM wird generiert aus der Build-Ausgabe (CycloneDX oder SPDX).
SBOM wird auf Interlynk hochgeladen, wo die Richtlinie
COMPONENT_PUBLISHED_AGEneben jeder anderen Richtlinie (Lizenz, Sicherheitsanfälligkeit, Lieferant, Lebenszyklus) ausgeführt wird.Verstöße blockieren den Release. Der PR wird blockiert, der Tag wird zurückgehalten, der Container wird in Quarantäne gestellt.
Ein vollständiges Audit-Protokoll existiert – wer hat was gebaut, wann, mit welchen Abhängigkeiten und welche Richtlinien wurden erfüllt oder fehlerhaft abgeschlossen.
Entscheidend ist, dass dieselbe Richtlinie auch kontinuierlich auf bereits ausgelieferten SBOMs ausgeführt wird. Wenn eine neue Sicherheitslücke für eine von Ihnen ausgelieferte Komponente offengelegt wird oder (für unsere Zwecke) eine von Ihnen ausgelieferte Komponente nachträglich aus der Registry entfernt wurde, erfahren Sie davon, ohne den Build erneut ausführen zu müssen.
Eine Infografik zum Aufhängen an der Wand
Der am einfachsten verständliche Weg, dies intern darzustellen, ist ein zweiachsiges Diagramm:
Horizontale Achse: Zeit — von „vor 1 Stunde veröffentlicht“ auf der linken Seite bis „vor 5 Jahren veröffentlicht“ auf der rechten Seite.
Vertikale Achse: Risiko — das Risiko bösartiger Releases auf der linken Seite (nimmt im Laufe von Tagen ab), das Risiko eines verwaisten Projekts auf der rechten Seite (wächst im Laufe von Jahren).
Zeichnen Sie die beiden Kurven ein. Sie kreuzen sich irgendwo um die 14- bis 30-Tage-Marke. Dieser Kreuzungsbereich ist die grüne Zone — Komponenten, die alt genug sind, um die Überprüfung nach der Veröffentlichung überstanden zu haben, aber neu genug, dass das Projekt noch aktiv ist.
Legen Sie dann die Richtlinie darüber:
LESS_THAN 14— „Sie befinden sich in der Gefahrenzone der roten Kurve, kühlen Sie ab“MORE_THAN 540— „Sie befinden sich in der Veraltungszone der blauen Kurve, aktualisieren Sie oder sondern Sie aus“RANGE {min: 14, max: 540}— die exakte grüne Zone, ausgedrückt als eine Regel
Dieses einzige Diagramm ist das gesamte Argument. Wenn Sie es der technischen Leitung zeigen, hört sie auf zu fragen, warum das Sicherheitsteam eine weitere Richtlinie einführen möchte.
Erste Schritte — Kostenlos
COMPONENT_PUBLISHED_AGE ist in der Community- (kostenlosen) Stufe von Interlynk verfügbar. Sie können:
Sich unter interlynk.io registrieren — keine Kreditkarte erforderlich.
Einen API-Schlüssel generieren in Ihren Organisationseinstellungen.
Eine SBOM hochladen für ein beliebiges Projekt (CycloneDX oder SPDX JSON, jedes Ökosystem).
Eine Richtlinie erstellen mit dem Thema
COMPONENT_PUBLISHED_AGE, dem OperatorLESS_THAN, dem Wert7— nennen Sie sie "7-Tage-Abkühlzeit".Die Richtlinie ausführen und genau sehen, welche Komponenten in Ihren bestehenden SBOMs erfasst worden wären.
Keine Gebühren pro Arbeitsplatz, keine Abrechnung pro SBOM in der Community-Stufe. Dies ist genau die Richtlinie, die keine Paywall haben sollte, also hat sie auch keine.
Was wir nicht behaupten
Eine kurze Liste ehrlicher Grenzen:
Abkühlzeiten (Cooldowns) ersetzen keine SCA. Schwachstellenscans, Lizenzrichtlinien, Lieferantennachweise und die Erkennung des Lebenszyklus (eingestellt/EOL) sind separate Maßnahmen – und weiterhin alle notwendig.
Abkühlzeiten ersetzen kein Pinning. Sie benötigen weiterhin Lockfiles, Integritätshashes und (idealerweise) signierte Artefakte. Abkühlzeiten verschaffen Ihnen Zeit; Pinning verschafft Ihnen Sicherheit. Nutzen Sie beides.
Abkühlzeiten sind statistisch, nicht deterministisch. Ein raffinierter Angreifer, der seine Kompromittierung über Wochen hinweg vorbereitet, hebelt ein 48-Stunden-Fenster aus. Abkühlzeiten erhöhen die Kosten; sie schließen nicht die Tür.
Die Zusammenfassung in einer Zeile
Paketmanager führen endlich Cooldown-Phasen ein, allerdings fragmentiert, als Opt-in und pro Ökosystem. SBOMs sind der einzige Ort, an dem eine Cooldown-Richtlinie einheitlich, überprüfbar und für alles, was Sie ausliefern, durchgesetzt werden kann – einschließlich Software, die Sie nicht selbst entwickelt haben.
Wenn Ihr Unternehmen bereits SBOMs erstellt, aktivieren Sie noch heute COMPONENT_PUBLISHED_AGE LESS_THAN 7. Es kostet nichts, fängt die derzeit am häufigsten vorkommende Angriffsklasse ab und liefert Ihnen eine vertretbare Antwort, wenn ein Regulator das nächste Mal fragt, was Sie für die Aktualität der Lieferkette tun.
Wenn Sie noch keine SBOMs erstellen, ist dies ein weiterer Grund, damit anzufangen.
Referenzen
Cooldown-Befürwortung und -Analyse
Simon Willison — Package managers need to cool down
Christian Schneider — Dependency Cooldowns: Supply Chain Defense
Endor Labs — Why Cooldown Windows Belong in Every npm Security Strategy
Cal Paterson — Dependency cooldowns are free-riding
Jüngste Vorfälle
Palo Alto Unit 42 — Shai-Hulud Worm Compromises npm Ecosystem
CISA — Widespread Supply Chain Compromise Impacting npm Ecosystem (Sept 2025)
Microsoft Security — Mitigating the Axios npm Supply Chain Compromise (April 2026)
Microsoft Security — Shai-Hulud 2.0: Detection and Defense Guidance
Upwind — Massive Compromise of debug, chalk, and 16 Other Packages
Interlynk
Registrieren (kostenlose Version): interlynk.io
Open-Source-SBOM-Tools: github.com/interlynk-io