如何用 bun audit 检查已安装包的已知漏洞并按严重级别过滤【免费下载链接】bunIncredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one项目地址: https://gitcode.com/GitHub_Trending/bu/bunbun audit是 bun 内置的依赖安全检查命令它读取项目bun.lock中记录的包列表向包注册表的 advisory 端点发起查询然后打印漏洞报告。本文面向已经用 bun 管理依赖的项目目标是在本地或 CI 里完成一次漏洞扫描并用--audit-level等参数把报告过滤到只关心high、critical级别的漏洞。运行前提项目根目录要有 bun.lockbun audit必须在带有bun.lock文件的项目里运行它只读锁文件中的包列表不需要node_modules。如果项目里还没有bun.lock运行bun install生成即可若项目已有其他锁文件Bun 会在没有bun.lock时自动迁移yarn.lockv1、package-lock.jsonnpmlockfileVersion2、3 或 4、pnpm-lock.yaml。npm 6 及更早版本lockfileVersion1的package-lock.json不会被迁移Bun 会打印警告并直接从package.json解析。原有的锁文件会被保留验证无误后可手动删除。如果只想生成锁文件、不安装到node_modules可以用bun install --lockfile-only运行 bun audit 并解读报告在项目根目录执行bun auditBun 从bun.lock读取包列表把该列表发送到 npm 的 advisory 端点来自 scoped registry 的包则发送到对应注册表。某个注册表没有 advisory 端点时Bun 会把其中的包列为 skipped且不影响退出码。bun audit是只读操作不会修改package.json、bun.lock或node_modules。没有漏洞时输出No vulnerabilities found有漏洞时Bun 逐个列出受影响包、严重级别、简短描述和 advisory 链接最后给出汇总。以下是文档示例输出3 vulnerabilities (1 high, 2 moderate) bun audit fix upgrade the vulnerable packages within their ranges bun audit fix --latest also cross major versions退出码是机器判断的依据应用--audit-level和--ignore过滤后无剩余漏洞时为0否则为1。按严重级别过滤--audit-level--audit-levellow|moderate|high|critical只报告该级别及更高严重度的漏洞bun audit --audit-levelhigh这个参数控制的是退出码——只有high及以上级别的漏洞存在时才会退出1低级别的漏洞不会让 CI 失败。按依赖类型缩小扫描范围两个参数用来控制哪些包进入审计# 只审计 dependencies / optionalDependencies / peerDependencies 可达的包 bun audit --prod # 跳过仅通过指定依赖类型可达的包可重复使用 bun audit --omitoptional --omitpeer--prod的别名是-p、-P、--production--omit可接受dev、optional、peer其中--omitdev与--prod等价。忽略特定 advisory--ignore对已评估并接受风险的 advisory可以用--ignore id按 GHSA ID 或数字 ID 忽略参数可重复bun audit --ignore GHSA-c2qf-rxjj-qqgw --ignore 1112918注意 CVE ID 不在注册表数据中无法用于匹配。让过滤规则可复用上述过滤参数只存在于命令行上要让每次运行都生效把它们写进package.json的 script 里例如{ scripts: { audit:ci: bun audit --audit-levelhigh --prod } }用 --json 输出原始结果接入 CI--json打印注册表返回的原始 JSON而不是格式化报告bun audit --json注意 JSON 内容本身未过滤——--audit-level和--ignore只影响退出码。在 CI 里可以组合使用JSON 输出供下游工具消费退出码按过滤规则判定是否失败。可选下一步bun audit fix 修复漏洞确认漏洞后bun audit fix会把每个漏洞包升级到所有依赖方版本范围内允许的最高安全版本并执行安装。副作用它会修改bun.lock和node_modules唯一例外是当某个直接依赖在package.json或 catalog 条目中固定为精确版本时Bun 会把^version视为范围并回写该固定值。建议先用--dry-run查看计划而不安装bun audit fix --dry-run修复完成后 Bun 会对新锁文件重新审计remaining计数和退出码基于第二次审计因此与随后手动运行bun audit的结果一致。修复结果可能分几类文档示例输出fixing: ms0.7.0 → 0.7.1 lodash4.17.20 → 4.17.21 package.json: 4.17.20 → 4.17.21 blocked by a dependents range: minimatch0.3.0 → 3.0.2 express3.21.2 depends on minimatch0.3.0 semver5.7.1 → 6.3.1 my-app depends on semver^5.0.0 bun audit fix --latest no published version fixes: left-pad1.3.0 GHSA-xxxx-xxxx-xxxx bun audit fix --ignore GHSA-xxxx-xxxx-xxxx Fixed 2 vulnerabilities in 2 packages 5 vulnerabilities remainingblocked by a dependents range没有安全版本能满足某个依赖方声明的范围。如果这个范围在你的package.json或 catalog 中用bun audit fix --latest可以越过它——Bun 会重写你自己的范围以接受新版本并保持风格^5.0.0→^6.3.1~5.7.1→~6.3.1精确版本保持精确。第三方包声明的范围仍然会阻塞需要通过 overrides 处理。no published version fixes所有已发布版本都有漏洞需要替换包或用输出中给出的--ignore命令静默该 advisory。如果较新版本不安全但旧版本安全Bun 会降级并标记(downgrade)。--json会打印描述计划与结果的单个 JSON 对象fixes、blocked、unfixable、unmatched、unaudited、vulnerableAfterInstall、fixed、remaining、dryRun如果生命周期脚本可能向 stdout 写内容加上--ignore-scripts。bun audit fix会拒绝--prod、--frozen-lockfile和--no-save因为这些参数会阻止写入bun.lock。结果判定与边界情况把扫描接入自动化时用退出码判定即可0表示过滤后无剩余漏洞1表示仍有漏洞。如果注册表请求失败bun audit和bun audit fix都会向 stderr 打印audit request failed并以退出码1结束——这属于网络或注册表问题不是漏洞发现排查方向是网络连接与注册表可用性。对于没有 advisory 端点的 scoped registry其中的包会被列为 skipped 且不影响退出码这类包的安全问题需要到对应注册表侧另行确认。【免费下载链接】bunIncredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one项目地址: https://gitcode.com/GitHub_Trending/bu/bun创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考