Bun Lockfiles and Your Supply Chain Security

Binary lockfiles are a security tax—you pay later, with interest.

Bun used to store dependencies in a binary file called bun.lockb. It was fast and small, but you couldn’t read it. You couldn’t diff it in a pull request, and you couldn’t see what changed.

When you can’t review a dependency change, you have no policy—just a vibe.

Bun v1.2 switches the default to a text-based bun.lock. That alone is a huge security win.

Why text-based lockfiles matter

  • Meaningful diffs – reviewers see exactly which packages moved or changed.
  • Easy policy checks – CI can scan for banned patterns or untrusted registries.
  • Faster forensics – git log shows the exact commit that introduced a malicious package.

A lockfile guarantees integrity and reproducibility, but it isn’t a silver bullet. It won’t stop a malicious version that was legitimately published, nor a compromised maintainer.

What the text lockfile adds is visibility. Visibility is your first line of defense.

How to secure your Bun workflow

  • Run bun install --frozen-lockfile in CI. The build fails if the lockfile needs an update.
  • Run bun install --lockfile-only in CI. You validate the resolution without executing heavy install scripts.
  • Migrate any bun.lockb files to bun.lock right away.
  • Require human review for lockfile changes. Add the appropriate owners to CODEOWNERS so the right eyes see every dependency update.

Stop trusting the tool blindly. Verify each change instead.

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