Lockfile'y Bun a bezpieczeństwo Twojego łańcucha dostaw

Binarne lockfile'y to podatek od bezpieczeństwa – płacisz go później, z odsetkami.

Bun wcześniej przechowywał zależności w binarnym pliku o nazwie bun.lockb. Był on szybki i mały, ale nie można go było odczytać. Nie można było go porównać (diff) w pull requeście ani zobaczyć, co uległo zmianie.

Kiedy nie możesz przejrzeć zmiany w zależności, nie masz żadnej polityki – masz tylko przeczucie.

Bun v1.2 zmienia domyślny format na tekstowy bun.lock. To samo w sobie jest ogromnym sukcesem w dziedzinie bezpieczeństwa.

Dlaczego tekstowe lockfile'y są ważne

  • Sensowne diffy – recenzenci widzą dokładnie, które pakiety zostały przesunięte lub zmienione.
  • Łatwe sprawdzanie polityk – CI może skanować pliki pod kątem zabronionych wzorców lub niezaufanych rejestrów.
  • Szybsza analiza śledcza – git log pokazuje dokładny commit, który wprowadził złośliwy pakiet.

Lockfile gwarantuje integralność i powtarzalność, ale nie jest magicznym rozwiązaniem. Nie powstrzyma on złośliwej wersji, która została opublikowana w sposób legalny, ani przejętego konta maintainera.

To, co tekstowy lockfile wnosi, to widoczność. Widoczność to Twoja pierwsza linia obrony.

Jak zabezpieczyć swój workflow w Bun

  • Uruchamiaj bun install --frozen-lockfile w CI. Budowanie zakończy się niepowodzeniem, jeśli lockfile będzie wymagał aktualizacji.
  • Uruchamiaj bun install --lockfile-only w CI. Pozwala to na walidację rozwiązań bez wykonywania ciężkich skryptów instalacyjnych.
  • Niezwłocznie przenieś wszystkie pliki bun.lockb na format bun.lock.
  • Wymagaj ludzkiej recenzji zmian w lockfile'ach. Dodaj odpowiednich właścicieli do CODEOWNERS, aby właściwe osoby widziały każdą aktualizację zależności.

Przestań ślepo ufać narzędziom. Zamiast tego weryfikuj każdą zmianę.

Źródło: https://dev.to/kunal_d6a8fea2309e1571ee7/bun-lockfile-bunlockb-format-threat-model-ci-checks-2026-4i3b