I lockfile di Bun e la sicurezza della tua supply chain

I lockfile binari sono una tassa sulla sicurezza: la pagherai più tardi, con gli interessi.

Bun utilizzava un file binario chiamato bun.lockb per memorizzare le dipendenze. Era veloce e piccolo, ma non era leggibile. Non era possibile effettuare un diff in una pull request e non si poteva vedere cosa fosse cambiato.

Quando non puoi revisionare il cambiamento di una dipendenza, non hai una policy, hai solo una sensazione.

Bun v1.2 imposta come predefinito un file testuale bun.lock. Questo, da solo, rappresenta una grande vittoria per la sicurezza.

Perché i lockfile testuali sono importanti

  • Diff significativi – i revisori vedono esattamente quali pacchetti si sono spostati o sono cambiati.
  • Controlli della policy semplificati – la CI può scansionare pattern vietati o registry non attendibili.
  • Forensics più rapidi – git log mostra l'esatto commit che ha introdotto un pacchetto malevolo.

Un lockfile garantisce integrità e riproducibilità, ma non è una bacchetta magica. Non fermerà una versione malevola pubblicata legittimamente, né un manutentore compromesso.

Ciò che il lockfile testuale aggiunge è la visibilità. La visibilità è la tua prima linea di difesa.

Come mettere in sicurezza il tuo workflow Bun

  • Esegui bun install --frozen-lockfile nella CI. La build fallisce se il lockfile necessita di un aggiornamento.
  • Esegui bun install --lockfile-only nella CI. Validi la risoluzione senza eseguire pesanti script di installazione.
  • Migra immediatamente tutti i file bun.lockb in bun.lock.
  • Richiedi una revisione umana per le modifiche al lockfile. Aggiungi i proprietari appropriati a CODEOWNERS in modo che le persone giuste vedano ogni aggiornamento delle dipendenze.

Smetti di fidarti ciecamente dello strumento. Verifica ogni cambiamento, invece.

Fonte: https://dev.to/kunal_d6a8fea2309e1571ee7/bun-lockfile-bunlockb-format-threat-model-ci-checks-2026-4i3b