Bun Lifecycle Script Security: Using trustedDependencies Safely

Short answer

Bun does not run arbitrary dependency lifecycle scripts by default; packages that genuinely need them must be explicitly listed in trustedDependencies. Treat that list as privileged code: keep it short, review every addition, pin the dependency version, and verify the lockfile and CI behavior after the change.

Why install scripts are a supply-chain boundary

preinstall, install, postinstall, and prepare scripts can execute during dependency installation. On a developer machine or CI runner, that may mean access to source files, environment variables, tokens, or deployment credentials.

The safer default is to avoid executing scripts from every transitive package. Bun supports this by requiring explicit trust for dependency lifecycle scripts. This reduces accidental execution, but it does not make a trusted package harmless or replace package review.

Review the trust decision

Before adding an entry, confirm:

• Why the package needs a lifecycle script.
• What the script executes and whether a prebuilt alternative exists.
• Which exact package version is being trusted.
• Whether the need applies in CI and production builds.
• Who owns the exception and when it should be reconsidered.

An example policy looks like this:

{
  "trustedDependencies": ["<reviewed-package>"]
}

Do not add a package to this list simply to make an installation warning disappear. Read the package documentation and the installed script first, and keep CI secrets unavailable to ordinary build jobs wherever possible.

Keep trust scoped and reviewable

Review trustedDependencies whenever a package is upgraded, removed, or no longer needs a native build. A trusted entry can outlive the reason it was added, especially after a package changes its distribution model. Include trust-list changes in the pull request and make CI install from the committed bun.lock. This gives reviewers a visible record of which packages are allowed to execute lifecycle scripts.

Verify the final dependency change

bun audit
bun test
bun run build
git diff -- package.json bun.lock

When an audit flags a vulnerability, trace the parent package and make the narrowest reviewed update. Avoid blanket bun update --latest changes during an incident; they can include major upgrades unrelated to the finding.

For exact version pinning and frozen CI installs, see Secure Package Version Pinning for npm, Bun, and pnpm. For the cross-manager workflow, see JavaScript Dependency Security.