Les lockfiles Bun et la sécurité de votre supply chain

Les lockfiles binaires sont une taxe sur la sécurité : vous la paierez plus tard, avec les intérêts.

Bun stockait auparavant les dépendances dans un fichier binaire nommé bun.lockb. C'était rapide et léger, mais illisible. Impossible de faire un diff dans une pull request ou de voir ce qui avait changé.

Lorsque vous ne pouvez pas examiner le changement d'une dépendance, vous n'avez pas de politique — seulement une intuition.

Bun v1.2 passe par défaut à un format textuel bun.lock. Rien que cela constitue une victoire majeure pour la sécurité.

Pourquoi les lockfiles textuels sont importants

  • Des diffs significatifs – les relecteurs voient exactement quels packages ont été déplacés ou modifiés.
  • Des contrôles de politique faciles – la CI peut scanner les patterns interdits ou les registres non approuvés.
  • Une analyse forensique plus rapide – git log montre le commit exact qui a introduit un package malveillant.

Un lockfile garantit l'intégrité et la reproductibilité, mais ce n'est pas une solution miracle. Il n'empêchera pas une version malveillante publiée légitimement, ni un mainteneur compromis.

Ce que le lockfile textuel apporte, c'est de la visibilité. La visibilité est votre première ligne de défense.

Comment sécuriser votre workflow Bun

  • Exécutez bun install --frozen-lockfile dans la CI. Le build échoue si le lockfile nécessite une mise à jour.
  • Exécutez bun install --lockfile-only dans la CI. Vous validez la résolution sans exécuter de scripts d'installation lourds.
  • Migrez immédiatement tous les fichiers bun.lockb vers bun.lock.
  • Exigez une revue humaine pour les changements de lockfile. Ajoutez les propriétaires appropriés dans CODEOWNERS pour que les bonnes personnes voient chaque mise à jour de dépendance.

Cessez de faire confiance aveuglément à l'outil. Vérifiez plutôt chaque changement.

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