Bun lockfiles en de beveiliging van je supply chain
Binaire lockfiles zijn een beveiligingstaks — je betaalt later, met rente.
Bun sloeg afhankelijkheden voorheen op in een binair bestand genaamd bun.lockb. Het was snel en klein, maar je kon het niet lezen. Je kon geen diff maken in een pull request en je kon niet zien wat er was veranderd.
Wanneer je een wijziging in een afhankelijkheid niet kunt beoordelen, heb je geen beleid — alleen een gevoel.
Bun v1.2 wijzigt de standaard naar een tekstgebaseerd bun.lock. Dat alleen al is een enorme winst voor de beveiliging.
Waarom tekstgebaseerde lockfiles belangrijk zijn
- Betekenisvolle diffs – reviewers zien precies welke pakketten zijn verplaatst of gewijzigd.
- Eenvoudige beleidscontroles – CI kan scannen op verboden patronen of onbetrouwbare registries.
- Snellere forensische analyse –
git loglaat de exacte commit zien die een kwaadaardig pakket heeft geïntroduceerd.
Een lockfile garandeert integriteit en reproduceerbaarheid, maar het is geen wondermiddel. Het stopt geen kwaadaardige versie die legitiem is gepubliceerd, noch een gecompromitteerde maintainer.
Wat het tekstgebaseerde lockfile toevoegt, is zichtbaarheid. Zichtbaarheid is je eerste verdedigingslinie.
Zo beveilig je je Bun-workflow
- Voer
bun install --frozen-lockfileuit in CI. De build mislukt als het lockfile een update nodig heeft. - Voer
bun install --lockfile-onlyuit in CI. Je valideert de resolutie zonder zware installatiescripts uit te voeren. - Migreer eventuele bun.lockb-bestanden direct naar bun.lock.
- Vereis menselijke beoordeling voor wijzigingen in het lockfile. Voeg de juiste eigenaren toe aan
CODEOWNERS, zodat de juiste mensen elke update van afhankelijkheden zien.
Stop met het blindelings vertrouwen op de tool. Verifieer in plaats daarvan elke wijziging.