Bunのロックファイルとサプライチェーン・セキュリティ

バイナリ形式のロックファイルは、セキュリティ上の「税金」です。後で利息付きで支払うことになります。

Bunは以前、依存関係を bun.lockb というバイナリファイルに保存していました。高速で軽量でしたが、中身を読むことができませんでした。プルリクエストで差分(diff)を確認することも、何が変更されたのかを見ることもできませんでした。

依存関係の変更をレビューできないということは、ポリシーが存在しないのと同じです。ただの「勘」に頼っているに過ぎません。

Bun v1.2では、デフォルトがテキストベースの bun.lock に切り替わりました。これだけでも、セキュリティ面での大きな勝利と言えます。

テキストベースのロックファイルが重要な理由

  • 意味のある差分 – レビュアーは、どのパッケージが移動または変更されたのかを正確に把握できます。
  • 容易なポリシーチェック – CIで禁止されたパターンや信頼できないレジストリをスキャンできます。
  • 高速なフォレンジックgit log を使って、悪意のあるパッケージが導入された正確なコミットを特定できます。

ロックファイルは整合性と再現性を保証しますが、万能薬ではありません。正当に公開された悪意のあるバージョンや、乗っ取られたメンテナーを防ぐことはできません。

テキスト形式のロックファイルがもたらすのは「可視性」です。可視性は、防御の第一線となります。

Bunのワークフローを安全にする方法

  • CIで bun install --frozen-lockfile を実行します。ロックファイルの更新が必要な場合、ビルドは失敗します。
  • CIで bun install --lockfile-only を実行します。重いインストールスクリプトを実行することなく、解決(resolution)の検証が行えます。
  • すべての bun.lockb ファイルをすぐに bun.lock へ移行してください。
  • ロックファイルの変更には人間によるレビューを必須にします。CODEOWNERS に適切なオーナーを追加し、すべての依存関係の更新が適切な担当者の目に触れるようにしてください。

ツールを盲目的に信じるのはやめましょう。代わりに、各変更を検証してください。

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