new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Bun · Package manager · all subjects

audit: security scanning

24 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

bun audit command reads packages from bun.lock

bun audit reads the package list from bun.lock (no node_modules required), sends it to the npm advisory endpoint, and prints a report. For packages from scoped registries, Bun sends them to that registry instead. If a registry has no advisory endpoint, Bun lists those packages as skipped and they don't affect the exit code.

bun audit never modifies package.json, bun.lock, or node_modules

bun audit never modifies package.json, bun.lock, or node_modules. To apply fixes, use bun audit fix instead.

bun audit success output when no vulnerabilities found

If Bun finds no vulnerabilities, the command prints: No vulnerabilities found

bun audit output format for vulnerabilities

When vulnerabilities are found, Bun lists each affected package with its severity, a short description, and a link to the advisory, followed by a summary showing the total count and breakdown by severity (e.g., 3 vulnerabilities (1 high, 2 moderate)).

bun audit --audit-level flag filters by severity

The --audit-level=<low|moderate|high|critical> flag only reports vulnerabilities at the specified severity or higher. Example: bun audit --audit-level=high

bun audit --prod flag filters to production dependencies

The --prod flag (also accepts -p, -P, or --production) only audits packages reachable through dependencies, optionalDependencies, or peerDependencies. Example: bun audit --prod

bun audit --omit flag skips dependency types

The --omit=<dev|optional|peer> flag skips packages only reachable through the given dependency type. This flag is repeatable. --omit=dev is equivalent to --prod. Example: bun audit --omit=optional --omit=peer

bun audit --ignore flag silences specific advisories

The --ignore <id> flag ignores an advisory by GHSA ID or numeric ID. This flag is repeatable. CVE IDs are not in the registry data and don't match. Example: bun audit --ignore GHSA-c2qf-rxjj-qqgw --ignore 1112918

bun audit --json flag returns raw registry response

The --json flag prints the raw JSON response from the registry instead of the formatted report. The JSON is unfiltered — --audit-level and --ignore only affect the exit code, not the JSON output.

bun audit exit code behavior

Exit code is 0 if no vulnerabilities remain after Bun applies --audit-level and --ignore, and 1 otherwise. For bun audit fix, the exit code is based on the re-audit after installing (or the plan, with --dry-run). If the registry request fails, both commands print audit request failed to stderr and exit 1.

bun audit fix upgrades vulnerable packages to safe versions

bun audit fix runs the audit, then upgrades each vulnerable package to the lowest non-vulnerable version that every dependent's range allows, and installs. Only bun.lock and node_modules change, with one exception: Bun treats a direct dependency pinned to an exact version as ^version. If Bun finds a fix, it rewrites the pin in package.json or the catalog entry.

bun audit fix blocked by a dependent's range

When bun audit fix encounters a package with no safe version that fits a dependent's declared range, it is blocked. If the range is in your own package.json or catalog, bun audit fix --latest gets past it. Otherwise, update the dependent or add an overrides entry.

bun audit fix handles downgrades and old versions

If no newer version is safe but an older one is, Bun downgrades and marks the row (downgrade). Bun still installs a safe version newer than --minimum-release-age and marks the row (newer than --minimum-release-age).

bun audit fix handles patched dependencies

Bun upgrades patched dependencies (patchedDependencies) like any other package. After upgrading, re-create the patch afterwards with bun patch.

bun audit fix re-audits after installing

After installing, Bun re-audits the new lockfile. The remaining count and exit code reflect that second audit, so they match what a follow-up bun audit would report.

bun audit fix --dry-run flag

The --dry-run flag prints the plan without installing.

bun audit fix --json flag output structure

The --json flag prints a single JSON object describing the plan and result with the following fields: fixes, blocked, unfixable, unmatched, unaudited, vulnerableAfterInstall, fixed, remaining, and dryRun. Pass --ignore-scripts if lifecycle scripts might write to stdout.

bun audit fix runs security scanner from bunfig.toml

A security scanner configured in bunfig.toml runs on the packages about to be installed, as with bun update.

bun audit fix rejects certain flags

Bun rejects --prod, --frozen-lockfile, and --no-save with bun audit fix since they prevent writing bun.lock.

bun audit fix --latest rewrites dependency ranges

bun audit fix --latest is the same as bun audit fix, but ranges in your own package.json files and catalogs no longer block a fix. Bun rewrites them to accept the new version, keeping their style (^5.0.0 → ^6.3.1, ~5.7.1 → ~6.3.1, exact stays exact). Ranges declared by third-party packages still block; use overrides for those.

bun audit filtering options are CLI-only

Filtering options like --audit-level, --prod, and --omit are CLI-only. To apply them on every run, put them in a package.json script.

Security scanner runs during package operations

Security scanners analyze packages during bun install, bun add, and other package operations. They can detect known security vulnerabilities (CVEs), malicious packages, and license compliance issues.

Security scanner severity levels

Scanners report issues at two severity levels: 'fatal' causes installation to stop immediately and exit with non-zero code; 'warn' prompts to continue in interactive terminals but exits immediately in CI environments.

Security scanner authentication via environment variables

Enterprise security scanners can take authentication and other configuration from environment variables. Set these variables (for example SECURITY_API_KEY) before running bun install and the scanner will use them automatically.

Give your agent this brain