Abkühlphasen mit SBOMs
Ritesh Noronha
Im September 2025 phischte ein Angreifer einen Maintainer namens "qix" und spielte schädliche Updates für chalk, debug und ansi-styles ein — Pakete mit über 2,1 Milliarden wöchentlichen Downloads zusammen. Die schädlichen Versionen waren etwa zwei Stunden lang auf npm live, 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 jetzt alle paar Wochen:
Nx (August 2025) — schädliche Pakete waren 4–5 Stunden live, SSH-Schlüssel und GitHub-Tokens wurden vor der Entfernung exfiltriert
Shai-Hulud-Wurm (Sept.–Nov. 2025) — sich selbst replizierender npm-Wurm breitete sich vor der Eindämmung über 25.000+ Repositories aus
LiteLLM (März 2026) — schädliche PyPI-Releases, die eine
.pth-Datei zur automatischen Ausführung und zum Abgreifen von Anmeldedaten nutzten, innerhalb von Stunden zurückgezogenAxios (31. März 2026) — schädliche Versionen eines Pakets mit über 100 Mio. wöchentlichen Downloads, das sich mit einem von Sapphire Sleet betriebenen C2 verband
ua-parser-js, event-stream, colors, faker — die historische Aufzählung von Kompromittierungen, die in jedem Supply-Chain-Vortrag zitiert wird
In jedem Fall lebte die schädliche Version in der Registry nur Stunden, nicht Tage. Und in jedem Fall wäre jeder, der einfach wartete, bevor er die neue Version zog, in Ordnung gewesen.
Das ist die Cooldown-Idee, und sie ist nicht neu. Was neu ist, ist, dass Paketmanager endlich — wenn auch verspätet und uneinheitlich — damit begonnen haben, Cooldown-Funktionen nativ auszuliefern. Und jetzt ist klar, dass die Paketmanager-Ebene allein nicht ausreicht. Hier kommen SBOMs ins Spiel.
Die Cooldown-Landschaft für Paketmanager (Stand April 2026)
Zwischen September 2025 und Februar 2026 haben sieben große Paketmanager Funktionen zur Abkühlung von Abhängigkeiten ausgeliefert:
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 zersplittert. Jedes Ökosystem hat sein eigenes Flag, seinen eigenen Standardwert (meistens keinen), seine eigene Semantik dafür, was "Alter" bedeutet. Organisationen mit polyglotten Stacks — und die meisten modernen Organisationen sind polyglott — müssen jetzt Abkühlungszeiten an sieben verschiedenen Stellen, in sieben verschiedenen CI-Systemen konfigurieren und hoffen, dass kein Team etwas vergisst.
Wichtiger noch: Die Cooldown-Regel des Paketmanagers wird zum Installationszeitpunkt, auf dem Laptop des Entwicklers oder auf einem CI-Runner durchgesetzt. Das bedeutet:
Es ist pro Repo opt-in. Eine falsch konfigurierte
package.json, und du bist exponiert.Es gilt nicht für Artefakte, die du bereits gebaut hast. Wenn ein Container-Image von letzter Woche eine schädliche Abhängigkeit gezogen hat, kann der Cooldown des Paketmanagers dich nicht nachträglich warnen.
Er kann stillschweigend überschrieben werden — ein
--no-cooldown-Flag, ein von einem gutmeinenden Ingenieur eingestelltes.npmrc-Override, ein CI-Cache, der die Prüfung überspringt.Er hilft nicht bei Software von Drittanbietern, die du nicht gebaut hast — Lieferobjekte von Anbietern, Container-Basis-Images, Firmware.
Es gibt keine zentrale Prüfkette. Ein Sicherheitsteam kann nicht fragen "Welche unserer 400 Services haben im letzten Quartal eine Abhängigkeit mit weniger als 48 Stunden Alter zugelassen?" und eine Antwort erhalten.
Das ist eine Governance-Lücke, keine Tooling-Lücke. Und Governance-Lücken sind genau der Grund, warum es SBOMs gibt.
SBOMs as an Enforcement Layer
Ein SBOM ist ein nach dem Build erstelltes, ökosystemunabhängiges Inventar dessen, was Sie tatsächlich ausgeliefert haben. Das ist ein einzigartig nützlicher Blickwinkel für die Durchsetzung von Cooldowns:
Standardmäßig polyglott. Eine einzige SBOM-Richtlinie kann Komponenten über npm, PyPI, Maven, Go, Cargo, NuGet, OCI-Images und eingebettete Firmware hinweg bewerten — mit einer Regel, nicht sieben Konfigurationen.
Nach dem Build, nicht vor der Installation. Sie prüfen gegen das, was tatsächlich im Artefakt gelandet ist, nicht gegen das, was von
package.jsonbeabsichtigt war. Kein „Die Lockdatei sagte das eine, der Build machte etwas anderes.“Zentral, prüfbar, durchsetzbar. Richtlinien leben an einem Ort. Verstöße erzeugen Aufzeichnungen. Verstöße sind für Sicherheit, Compliance und Engineering gleichzeitig sichtbar.
Shift-left und Shift-right. Dieselbe Regel kann in CI laufen, um eine Veröffentlichung zu blockieren, und gegen bestehende Produktionsartefakte, um Komponenten zu finden, die nach der Bereitstellung riskant geworden sind.
Deckt Software ab, die Sie nicht kompiliert haben. Lieferungen von Anbietern und Basis-Images werden inzwischen mit SBOMs ausgeliefert (CRA, FDA, EO 14028 weisen alle in diese Richtung). Ein Cooldown des Paketmanagers kann sie nicht prüfen. Ein Cooldown auf SBOM-Ebene kann das.
Der Paketmanager ist der Ort, an dem Sie Cooldowns bevorzugt ausführen lassen — dort ist es am günstigsten. Das SBOM ist der Ort, an dem Sie nachweisen, dass Cooldowns ausgeführt wurden — dort ist es maßgeblich. Beide Ebenen sind nützlich. Nur eine ist ausreichend.
Introducing COMPONENT_PUBLISHED_AGE
Die Plattform von Interlynk liefert jetzt ein Policy-Subject namens COMPONENT_PUBLISHED_AGE. Es drückt genau eine Idee aus: „Für jede Komponente in einer SBOM nachsehen, wann genau diese Version in ihrem Paket-Registry veröffentlicht wurde, und dieses Datum mit einem Policy-Schwellenwert vergleichen.“
Drei Operatoren werden unterstützt:
Operator | Bedeutung | Beispiel |
|---|---|---|
| Komponente wurde in den letzten N Tagen veröffentlicht. Verstößt. |
|
| Komponente ist älter als N Tage. Verstößt. |
|
| Komponente fällt in ein Altersfenster |
|
Die Grenze ist exklusiv — LESS_THAN 7 löst bei einer Komponente, die genau vor 7 Tagen veröffentlicht wurde, nicht aus. Das entspricht jedem anderen altersbasierten Subject in der Plattform (Alter des Vulnerability-Status, Zuweisungsalter usw.), sodass es keine Überraschungen gibt.
LESS_THAN ist die Cooldown-Grundform. MORE_THAN ist das Gegenstück — Erkennung von Veralterung, wenn eine Komponente aufgegeben wurde und das Ökosystem weitergezogen ist. RANGE ist die zweiseitige Version, nützlich zum Definieren einer „grünen Zone“ (z. B. „Abhängigkeiten sollten mindestens 14 Tage alt, aber nicht älter als 18 Monate sein“).
Wenn die Policy ausgeführt wird, erzeugt jede Komponente, deren package_version.published_at in das verbotene Fenster fällt, eine PolicyRuleViolation, die auf genau diese Komponente bezogen ist, mit:
dem PURL und der Version der Komponente
dem genauen Veröffentlichungszeitpunkt
der Regel, die ausgelöst hat
der SBOM (und damit dem Projekt, der Release-Version und dem Artefakt), in der sie auftauchte
Verstöße laufen durch dieselbe Berichts-, Ticketing- und Webhook-Pipeline wie jedes andere Policy-Ergebnis — ein verfehlter Cooldown kann also automatisch ein Jira-Ticket öffnen, einen GitHub-PR-Merge blockieren oder das Security-Team alarmieren.
Wo Abklingzeiten geholfen hätten — Eine Zeitleiste
Hier ist das Gegenfaktum „Was wäre, wenn wir einen 48-Stunden-Cooldown hätten?“ angewendet auf jüngste Angriffe:
Angriff | Veröffentlicht → Zurückgezogen | Ergebnis mit einem 48-Stunden-Cooldown |
|---|---|---|
Nx (Aug. 2025) | ~4–5 Stunden | Nicht übernommen |
chalk / debug / ansi-styles (8. Sep.) | ~2 Stunden | Nicht übernommen |
Shai-Hulud-Wurm (Sep.–Nov. 2025) | ~Stunden pro Version | Stark verringerter Blast-Radius |
LiteLLM (März 2026) | Stunden | Nicht übernommen |
Axios (31. März 2026) | Stunden | Nicht übernommen |
event-stream (historisch) | Tage | Weiterhin übernommen — Cooldown allein unzureichend |
ua-parser-js (historisch) | ~12 Stunden | Nicht übernommen |
Die ehrliche Einschränkung: Ein Cooldown ist kein Allheilmittel. Der event-stream-Angriff blieb monatelang unbemerkt, bevor ihn jemand bemerkte — 48 Stunden zu warten hätte nicht geholfen. Cooldowns schützen gegen die Fast-Burn-Klasse von Supply-Chain-Angriffen, die heute zufällig die Mehrheit ausmacht. Sie schützen nicht gegen langfristige verdeckte Kompromittierungen, Übernahmen von Maintainer-Konten mit geduldigem Vorbereiten oder Angriffe auf das Build-System wie den Trivy-Tag-Hijack. Dafür braucht es andere Kontrollen.
Aber selbst wenn Cooldowns 70% der in freier Wildbahn beobachteten Angriffsmuster bei praktisch null Betriebskosten abfangen — was die jüngsten Vorfallsdaten nahelegen — ist das ein enormer ROI für eine einzige Richtlinie.
Why "Shift Left with SBOM" Is the Right Architecture
Es gibt eine berechtigte Kritik an Cooldowns, die von Cal Paterson am deutlichsten formuliert wurde: Sie funktionieren, indem sie auf Kosten des Leids weniger geschützter Nutzer Trittbrett fahren. Wenn alle 48 Stunden warten, entdeckt niemand das schädliche Paket, weil niemand es ausführt. Die Entdeckung geschieht durch die Early Adopters, die sich dabei 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. nicht. Bis sie es tun, müssen sich einzelne Organisationen selbst verteidigen.
SBOM-Ebene-Cooldowns sind aus denselben oben dargelegten Gründen eine bessere individuelle Verteidigung als Package-Manager-Cooldowns: einheitlich, prüfbar, sprachübergreifend, deckt Drittanbieter-Artefakte ab. Und weil SBOMs als Teil des Builds vor der Veröffentlichung des Artefakts generiert werden, liegt der Durchsetzungspunkt so weit links wie möglich, ohne an einen bestimmten Package Manager gekoppelt zu sein.
CI baut das Artefakt. Code wird kompiliert, Abhängigkeiten werden aufgelöst, Container-Images werden zusammengesetzt.
SBOM wird generiert aus der Build-Ausgabe (CycloneDX oder SPDX).
SBOM wird in Interlynk hochgeladen, wo die Richtlinie
COMPONENT_PUBLISHED_AGEzusammen mit jeder anderen Richtlinie ausgeführt wird (Lizenz, Schwachstelle, Lieferant, Lebenszyklus).Verstöße blockieren die Freigabe. Der PR wird gesperrt, das Tag wird zurückgehalten, der Container wird unter Quarantäne gestellt.
Es existiert ein vollständiger Audit-Trail — wer was wann mit welchen Abhängigkeiten gebaut hat und welche Richtlinien bestanden oder fehlgeschlagen sind.
Entscheidend ist, dass dieselbe Richtlinie auch kontinuierlich auf bereits ausgelieferten SBOMs ausgeführt wird. Wenn eine neue Schwachstelle für eine Komponente bekannt wird, die Sie ausgeliefert haben, oder wenn sich (für unsere Zwecke) herausstellt, dass eine von Ihnen ausgelieferte Komponente nachträglich aus der Registry entfernt wurde, erfahren Sie davon, ohne den Build erneut ausführen zu müssen.
An Infographic to Put on the Wall
The clearest way to frame this internally is a two-axis picture:
Horizontal axis: time — from "published 1 hour ago" on the left to "published 5 years ago" on the right.
Vertical axis: risk — malicious-release risk on the left (decays over days), abandoned-project risk on the right (grows over years).
Plot the two curves. They cross somewhere around the 14–30 day mark. That crossing region is the green zone — components that are old enough to have survived post-publication scrutiny, but new enough that the project is still alive.
Then overlay the policy:
LESS_THAN 14— "you are in the red-curve danger zone, cool off"MORE_THAN 540— "you are in the blue-curve staleness zone, upgrade or retire"RANGE {min: 14, max: 540}— the exact green zone, expressed as one rule
That single picture is the entire argument. When you show it to engineering leadership, they stop asking why the security team wants another policy.
Getting Started — Free
COMPONENT_PUBLISHED_AGE ist in Interlynks Community-(kostenlose) Stufe verfügbar. Sie können:
Registrieren Sie sich bei interlynk.io — keine Kreditkarte erforderlich.
Generieren Sie einen API-Schlüssel in den Einstellungen Ihrer Organisation.
Laden Sie ein SBOM hoch für jedes Projekt (CycloneDX oder SPDX JSON, beliebiges Ökosystem).
Erstellen Sie eine Richtlinie mit dem Subjekt
COMPONENT_PUBLISHED_AGE, dem OperatorLESS_THANund dem Wert7— nennen Sie sie „7-Tage-Abkühlphase“.Führen Sie die Richtlinie aus und sehen Sie genau, welche Komponenten in Ihren vorhandenen SBOMs erfasst worden wären.
Keine Gebühren pro Benutzer, keine Abrechnung pro SBOM in der Community-Stufe. Dies ist genau die Richtlinie, für die es keine Paywall geben sollte, und das gibt es auch nicht.
What We're Not Claiming
Eine kurze Liste ehrlicher Grenzen:
Abkühlphasen ersetzen SCA nicht. Das Scannen nach Schwachstellen, Lizenzrichtlinien, Lieferantenbestätigungen und die Erkennung des Lebenszyklus (aufgegeben/EOL) sind alles eigenständige Maßnahmen — und alle weiterhin notwendig.
Abkühlphasen ersetzen das Pinning nicht. Sie wollen weiterhin Lockfiles, Integritäts-Hashes und (idealerweise) signierte Artefakte. Abkühlphasen verschaffen Ihnen Zeit; Pinning verschafft Ihnen Gewissheit. Verwenden Sie beides.
Abkühlphasen sind statistisch, nicht deterministisch. Ein ausgeklügelter Angreifer, der seinen Kompromittierungsangriff über Wochen hinweg staffelt, wird ein 48-Stunden-Fenster aushebeln. Abkühlphasen erhöhen die Kosten; sie schließen die Tür nicht.
The One-Line Summary
Paketmanager liefern endlich Cooldowns aus, aber fragmentiert, optional und pro Ökosystem. SBOMs sind der einzige Ort, an dem eine Cooldown-Richtlinie einheitlich, prüfbar und über alles, was Sie ausliefern, hinweg durchsetzbar sein kann — einschließlich Software, die Sie nicht selbst gebaut haben.
Wenn Ihre Organisation bereits SBOMs erzeugt, aktivieren Sie heute COMPONENT_PUBLISHED_AGE LESS_THAN 7. Es kostet nichts, erfasst die derzeit am häufigsten anzutreffende Angriffsart in freier Wildbahn und liefert Ihnen eine belastbare Antwort, wenn Sie das nächste Mal ein Regulierer fragt, was Sie gegen die Aktualität der Lieferkette tun.
Wenn Sie noch keine SBOMs erzeugen, ist das ein weiterer Grund, damit zu beginnen.
Referenzen
Befürwortung und Analyse von Cooldowns
Simon Willison — Paketmanager müssen abkühlen
Christian Schneider — Abkühlphasen für Abhängigkeiten: Verteidigung der Lieferkette
Endor Labs — Warum Abkühlfenster in jede npm-Sicherheitsstrategie gehören
Cal Paterson — Abkühlphasen für Abhängigkeiten sind Trittbrettfahren
Aktuelle Vorfälle
Palo Alto Unit 42 — Shai-Hulud-Wurm kompromittiert npm-Ökosystem
CISA — Weitreichende Kompromittierung der Lieferkette mit Auswirkungen auf das npm-Ökosystem (Sept. 2025)
Microsoft Security — Eindämmung der npm-Lieferkettenkompromittierung von Axios (April 2026)
Microsoft Security — Shai-Hulud 2.0: Hinweise zu Erkennung und Abwehr
Upwind — Massive Kompromittierung von debug, chalk und 16 weiteren Paketen
Interlynk
Anmelden (kostenlose Stufe): interlynk.io
Open-Source-SBOM-Werkzeuge: github.com/interlynk-io