Afkoeltijden met SBOM's
Ritesh Noronha
In september 2025 werd een beheerder die bekendstaat als "qix" gefopt via phishing en werden kwaadaardige updates gepusht naar chalk, debug en ansi-styles — samen pakketten met meer dan 2,1 miljard wekelijkse downloads. De kwaadaardige versies stonden ongeveer twee uur live op npm voordat de community ze ontdekte en ze werden verwijderd.
Twee uur. Als je CI-pipeline in dat venster draaide en je lockfile openstond voor de nieuwste patch, heb je malware uitgerold.
Dit is het patroon. Het herhaalt zich nu om de paar weken:
Nx (augustus 2025) — kwaadaardige pakketten live gedurende 4–5 uur, SSH-sleutels en GitHub-tokens buitgemaakt vóór verwijdering
Shai-Hulud worm (sept–nov 2025) — zichzelf replicerende npm-worm verspreidde zich over 25.000+ repositories vóór indamming
LiteLLM (maart 2026) — kwaadaardige PyPI-releases die een
.pth-bestand gebruikten voor automatische uitvoering en het oogsten van inloggegevens, binnen enkele uren verwijderdAxios (31 maart 2026) — kwaadaardige versies van een pakket met meer dan 100 miljoen wekelijkse downloads, dat verbinding maakte met een C2 die werd beheerd door Sapphire Sleet
ua-parser-js, event-stream, colors, faker — de historische opsomming van compromitteringen die in élke supply-chain talk wordt aangehaald
In elk geval stond de kwaadaardige versie uren, geen dagen in de registry. En in elk geval zou iedereen die simpelweg had gewacht voordat hij de nieuwe versie ophaalde, veilig zijn geweest.
Dat is het cooldown-idee, en het is niet nieuw. Wat wel nieuw is, is dat package managers eindelijk — zij het laat en ongelijkmatig — native cooldown-functies zijn gaan leveren. En het is nu duidelijk dat alleen de package-managerlaag niet genoeg is. Hier komen SBOMs om de hoek kijken.
Het landschap van de afkoelperiode voor package-managers (per april 2026)
Tussen september 2025 en februari 2026 brachten zeven grote pakketbeheerders afkoelfuncties voor afhankelijkheden uit:
Pakketbeheerder | Vlag / instelling | Versie |
|---|---|---|
pnpm |
| 10.16+ |
Yarn |
| 4.10.0 |
Bun |
| 1.3 |
Deno |
| 2.6 |
uv |
| 0.9.17 |
pip |
| 26.0 |
npm |
| 11.10.0 |
Dit is echte vooruitgang. Maar het is ook enorm versnipperd. Elk ecosysteem heeft zijn eigen vlag, zijn eigen standaardinstelling (meestal none), zijn eigen semantiek voor wat "age" betekent. Organisaties met polyglot-stacks — en de meeste moderne organisaties zijn polyglot — moeten nu afkoelperiodes op zeven verschillende plaatsen configureren, in zeven verschillende CI-systemen, en hopen dat geen team het vergeet.
Belangrijker nog: de cooldown van de pakketbeheerder wordt afgedwongen op het moment van installeren, op de laptop van de ontwikkelaar of op een CI-runner. Dat betekent:
Het is per repo opt-in. Eén verkeerd geconfigureerde
package.jsonen je bent blootgesteld.Het geldt niet voor artefacten die je al hebt gebouwd. Als een containerimage van vorige week een kwaadaardige afhankelijkheid heeft opgehaald, kan de cooldown van de pakketbeheerder je daar niet achteraf voor waarschuwen.
Het kan stilzwijgend worden overschreven — een
--no-cooldown-vlag, een.npmrc-override die door een goedbedoelende engineer is gecommit, een CI-cache die de controle overslaat.Het helpt niet bij software van derden die je niet hebt gebouwd — door leveranciers geleverde componenten, containerbasisimages, firmware.
Er is geen centraal audittraject. Een beveiligingsteam kan niet vragen "welke van onze 400 services lieten vorig kwartaal een afhankelijkheid jonger dan 48 uur toe?" en daar een antwoord op krijgen.
Dit is een governancekloof, geen toolingskloof. En governancekloven zijn waar SBOM's voor bedoeld zijn.
SBOMs as an Enforcement Layer
Een SBOM is een post-build, ecosysteem-agnostische inventaris van wat je daadwerkelijk hebt verzonden. Dat is een uniek nuttig perspectief voor cooldown-handhaving:
Polyglot als standaard. Eén SBOM-beleid kan componenten evalueren over npm, PyPI, Maven, Go, Cargo, NuGet, OCI-images en embedded firmware — met één regel, niet zeven configuraties.
Post-build, niet pre-install. Je evalueert op basis van wat daadwerkelijk in het artefact terechtkwam, niet op wat bedoeld was door
package.json. Geen "de lockfile zei het ene, de build deed iets anders" meer.Centraal, controleerbaar en afdwingbaar. Beleid staat op één plek. Overtredingen leveren records op. Overtredingen zijn tegelijk zichtbaar voor beveiliging, compliance en engineering.
Shift-left en shift-right. Dezelfde regel kan in CI draaien om een release te blokkeren, en op bestaande productie-artefacten om componenten te vinden die na implementatie riskant werden.
Dekt software die je niet hebt gecompileerd. Leveringen van leveranciers en basisimages worden nu met SBOM's geleverd (CRA, FDA, EO 14028 wijzen allemaal in deze richting). Een cooldown van de pakketbeheerder kan ze niet inspecteren. Een cooldown op SBOM-niveau wel.
De pakketbeheerder is waar je bij voorkeur cooldowns laat draaien — daar is het het goedkoopst. De SBOM is waar je bewijst dat cooldowns hebben gedraaid — daar is het de gezaghebbende bron. Beide lagen zijn nuttig. Slechts één is voldoende.
Introducing COMPONENT_PUBLISHED_AGE
Het platform van Interlynk bevat nu een policy-subject genaamd COMPONENT_PUBLISHED_AGE. Het drukt precies één idee uit: "voor elk component in een SBOM, zoek op wanneer die specifieke versie is gepubliceerd in zijn package registry, en vergelijk die datum met een beleidsdrempel."
Er worden drie operatoren ondersteund:
Operator | Betekenis | Voorbeeld |
|---|---|---|
| Component is gepubliceerd binnen de afgelopen N dagen. Schendt. |
|
| Component is ouder dan N dagen. Schendt. |
|
| Component valt binnen een leeftijdsvenster |
|
De grens is exclusief — LESS_THAN 7 treedt niet in werking op een component dat precies 7 dagen geleden is gepubliceerd. Dit komt overeen met elk ander op leeftijd gebaseerd subject in het platform (leeftijd van kwetsbaarheidsstatus, toewijzingsleeftijd, enz.), dus er zijn geen verrassingen.
LESS_THAN is de cooldown-primitive. MORE_THAN is het omgekeerde — detectie van veroudering, voor wanneer een component is verlaten en het ecosysteem is doorgegaan. RANGE is de tweezijdige versie, handig voor het definiëren van een "groene zone" (bijv. "afhankelijkheden moeten minstens 14 dagen oud zijn maar niet ouder dan 18 maanden").
Wanneer het beleid wordt uitgevoerd, produceert elk component waarvan package_version.published_at binnen het verboden venster valt een PolicyRuleViolation die specifiek aan dat component is gekoppeld, met:
De PURL en versie van het component
De exacte publicatietijdstempel
De regel die overeenkwam
De SBOM (en daarmee het project, de release en het artifact) waarin het voorkwam
Schendingen lopen via dezelfde rapportage-, ticketing- en webhook-pijplijn als elk ander beleidsresultaat — dus een gemiste cooldown kan automatisch een Jira-ticket openen, een GitHub PR-merge blokkeren of het beveiligingsteam alarmeren.
Waar afkoeltijden hadden geholpen — Een tijdlijn
Hier is het tegenfeitelijke "wat als we een afkoelperiode van 48 uur hadden gehad?", toegepast op recente aanvallen:
Aanval | Gepubliceerd → Verwijderd | Uitkomst met een afkoelperiode van 48 uur |
|---|---|---|
Nx (Aug 2025) | ~4–5 uur | Niet overgenomen |
chalk / debug / ansi-styles (Sep 8) | ~2 uur | Niet overgenomen |
Shai-Hulud worm (Sep–Nov 2025) | ~uren per versie | Sterk verkleinde impactradius |
LiteLLM (March 2026) | Uren | Niet overgenomen |
Axios (Mar 31, 2026) | Uren | Niet overgenomen |
event-stream (historical) | Dagen | Nog steeds overgenomen — afkoelperiode alleen is onvoldoende |
ua-parser-js (historical) | ~12 uur | Niet overgenomen |
De eerlijke kanttekening: een afkoelperiode is geen wondermiddel. De event-stream-aanval duurde maanden voordat iemand het merkte — 48 uur wachten had niet geholpen. Afkoelperiodes beschermen tegen de fast-burn-categorie van supply-chainaanvallen, en dat is vandaag toevallig de meerderheid. Ze beschermen niet tegen langdurige, heimelijke compromitteringen, het overnemen van een maintainer met geduldig voorbereiden, of aanvallen op het buildsysteem zoals de Trivy-tagkaping. Daarvoor zijn andere maatregelen nodig.
Maar als afkoelperiodes zelfs 70% van de in het wild voorkomende aanvalspatronen afvangen tegen praktisch nul operationele kosten — en dat is wat de recente incidentgegevens suggereren — dan levert één beleidsregel een enorme ROI op.
Why "Shift Left with SBOM" Is the Right Architecture
Er is een legitieme kritiek op cooldowns, het duidelijkst verwoord door Cal Paterson: ze werken door mee te liften op de pijn van minder beschermde gebruikers. Als iedereen 48 uur wacht, detecteert niemand het kwaadaardige pakket, omdat niemand het uitvoert. De detectie wordt gedaan door de vroege gebruikers die zich branden.
De voorgestelde systeemoplossing is een uploadwachtrij bij de registry — publicatie vindt plaats, maar distributie wordt vertraagd terwijl scanners draaien. Debian doet dit al decennia. npm, PyPI en soortgelijke platforms doen dat niet. Zolang zij dat niet doen, moeten individuele organisaties zichzelf verdedigen.
Cooldowns op SBOM-laag zijn een betere individuele verdediging dan cooldowns van package managers om dezelfde redenen als hierboven uiteengezet: uniform, controleerbaar, polyglot, dekt artefacten van derden. En omdat SBOM's worden gegenereerd als onderdeel van de build, vóórdat het artefact wordt vrijgegeven, ligt het handhavingspunt zo ver naar links als mogelijk is zonder te koppelen aan een specifieke package manager.
CI bouwt het artefact. Code wordt gecompileerd, afhankelijkheden worden opgelost, containerimages worden samengesteld.
SBOM wordt gegenereerd uit de build-output (CycloneDX of SPDX).
SBOM wordt geüpload naar Interlynk, waar het
COMPONENT_PUBLISHED_AGE-beleid naast elk ander beleid draait (licentie, kwetsbaarheid, leverancier, levenscyclus).Schendingen blokkeren de release. De PR wordt geblokkeerd, de tag wordt vastgehouden, de container wordt in quarantaine geplaatst.
Er bestaat een volledig auditrecord — wie wat heeft gebouwd, wanneer, met welke afhankelijkheden, en welke beleidsregels zijn geslaagd of mislukt.
Cruciaal is dat hetzelfde beleid ook continu draait op reeds uitgebrachte SBOM's. Als er een nieuwe kwetsbaarheid wordt gemeld voor een component die je hebt uitgebracht, of (voor onze doeleinden) blijkt dat een component die je hebt uitgebracht achteraf uit de registry is verwijderd, kom je daarachter zonder de build opnieuw uit te voeren.
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 is beschikbaar op Interlynk's Community (gratis) abonnement. U kunt:
Meld u aan op interlynk.io — geen creditcard.
Genereer een API-sleutel uit de instellingen van uw organisatie.
Upload een SBOM voor elk project (CycloneDX of SPDX JSON, elk ecosysteem).
Maak een beleid met onderwerp
COMPONENT_PUBLISHED_AGE, operatorLESS_THAN, waarde7— noem het "7-daagse afkoeling."Voer het beleid uit en zie precies welke componenten in uw bestaande SBOM's zouden zijn opgemerkt.
Geen kosten per gebruiker, geen afrekening per SBOM op het Community-abonnement. Dit is precies het beleid dat geen betaalmuur zou moeten hebben, en dat heeft het ook niet.
What We're Not Claiming
Een korte lijst van eerlijke beperkingen:
Cooldowns vervangen SCA niet. Kwetsbaarheidsscans, licentiebeleid, leveranciersattestatie en levenscyclusdetectie (verlaten/EOL) zijn allemaal afzonderlijk — en nog steeds noodzakelijk.
Cooldowns vervangen pinning niet. Je wilt nog steeds lockfiles, integriteitshashes en (idealiter) ondertekende artefacten. Cooldowns leveren je tijd op; pinning levert je zekerheid op. Gebruik beide.
Cooldowns zijn statistisch, niet deterministisch. Een geavanceerde aanvaller die zijn compromittering over weken spreidt, zal een venster van 48 uur verslaan. Cooldowns verhogen de kosten; ze sluiten de deur niet.
The One-Line Summary
Pakketbeheerders leveren eindelijk afkoeltijden, maar versnipperd, opt-in en per ecosysteem. SBOM's zijn de enige plek waar afkoelbeleid uniform, controleerbaar en afdwingbaar kan zijn over alles wat je uitbrengt — inclusief software die je niet zelf hebt gebouwd.
Als je organisatie al SBOM's genereert, zet vandaag COMPONENT_PUBLISHED_AGE LESS_THAN 7 aan. Het kost niets, het vangt de meest voorkomende aanvalsklasse die momenteel in het wild voorkomt, en het geeft je een verdedigbaar antwoord de volgende keer dat een toezichthouder vraagt wat je doet aan de versheid van de toeleveringsketen.
Als je nog geen SBOM's genereert, is dit nóg een reden om te beginnen.
Referenties
Pleitbezorging en analyse over afkoelperiodes
Simon Willison — Pakketbeheerders moeten afkoelen
Christian Schneider — Afkoelperiodes voor afhankelijkheden: verdediging van de toeleveringsketen
Endor Labs — Waarom afkoelvensters thuishoren in elke npm-beveiligingsstrategie
Cal Paterson — Afkoelperiodes voor afhankelijkheden zijn meeliften
Recente incidenten
Palo Alto Unit 42 — Shai-Hulud-worm compromitteert npm-ecosysteem
CISA — Wijdverbreide compromittering van de toeleveringsketen die het npm-ecosysteem treft (sept. 2025)
Microsoft Security — Beperken van de npm-toeleveringsketencompromittering van Axios (april 2026)
Microsoft Security — Shai-Hulud 2.0: richtlijnen voor detectie en verdediging
Upwind — Massale compromittering van debug, chalk en 16 andere pakketten
Interlynk
Aanmelden (gratis tier): interlynk.io
Open-source SBOM-tooling: github.com/interlynk-io