Support for bun audit (like npm/yarn audit)

[Calvein]

What is the problem this feature would solve?

I'm trying to replace node, yarn & jest with bun and the only missing feature to replace our workflow is an equivalent to yarn audit.

What is the feature you are proposing to solve the problem?

Add bun audit which would work like npm/yarn audit.

What alternatives have you considered?

I run bun install with the --yarn flag to be able to run yarn audit

[melroy89]

I'm kinda surprised this command is really missing. Or do I miss something?

[tomerh2001]

+1
Any updates?

[melroy89]

+1 Any updates?

I don't think it's implemented in v1.0.3 either. So no. No update. Maybe it will be part of any future roadmap?

[tomerh2001]

+1 Any updates?

I don't think it's implemented in v1.0.3 either. So no. No update. Maybe it will be part of any future roadmap?

Uh I see, do you know of any temporary alternatives we could use until then? Ones that doesn't require a specific pm (I. E. Could be used with bun)

[melroy89]

Uh I see, do you know of any temporary alternatives we could use until then? Ones that doesn't require a specific pm (I. E. Could be used with bun)

Not really.. but maybe try upgradeps:

bun install upgradeps

And then run (for the audit feature):

bunx upgradeps

Example output:

upgradeps v2.0.6 ─ run with -h to output usage information
✘ typescript 5.0.0 → 5.2.2 minor last publish 1 month ago
  1 dependency 1 minor

[alec-c4]

+1

[LucyEgan]

+1

[MendyLanda]

+1

[avan2s]

Anything here planned in the next time? Especially bun audit fix would be great like npm audit fix. The package-lock json is touched sometimes and i think the bun.lockb should do as well.

[HDVinnie]

Would love to see this added as well.

[jase88]

It would be great to have this feature in bun.

Ideally with features that are missing in other package managers, such as the ability to ignore certain security vulnerabilities for the time being by giving a reason (like implemented in npm-audit-resolver)

[vhscom]

Trivy is a useful security scanning tool for polyglot projects. Rather than just running an npm audit you can use Trivy to both audit your JavaScript modules, Dockerfiles, go modules, and more in a single-shot CLI fashion:

 trivy fs /path/to/project # don't make me do stuff

[hussain-nz]

I know it sucks but I found it easier to just stick with npm run audit, of course it doesn't work without package-lock.json but you can generate this effectively with a flag (16 seconds on our Azure CI server) : npm i --package-lock-only

[lgarron]

I know it sucks but I found it easier to just stick with npm run audit, of course it doesn't work without package-lock.json but you can generate this effectively with a flag (16 seconds on our Azure CI server) : npm i --package-lock-only

This sounds like a useful workaround in theory, but it has a huge issue: the package versions in a lockfile that npm would generate at a given moment will not generally match the versions frozen in bun.lockb. This can easily cause a false negative, which is bad for a security feature like this.

This workaround would get a lot more practical if bun had a way to output bun.lockb in package-lock.json format. (I know bun bun.lockb prints the contents, but certainly not in JSON format.) That might also make it more practical for GitHub to index bun.lockb files and support it for Dependabot in the future.

[lgarron]

I'm now in a situation where I maintain a repo that has "9 high severity vulnerabilities" but I can't properly audit or upgrade them using bun.

I am fine with this for personal projects, but I'm worried this is borderline-untenable for anyone considering bun for use at work. 😬

If bun documented and supported a canonical way to run an npm audit over a bun.lockb in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.

And at least in the short-term it would be possible to set up a GitHub action to run such a check on a schedule in each individual repo for now.

[Jarred-Sumner]

If bun documented and supported a canonical way to run an npm audit over a bun.lockb in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.

If you run bun bun.lockb, it will produce a yarn v1 yarn.lock file. I wonder if there's a way to get npm audit to run on that?

[goamn]

If bun documented and supported a canonical way to run an npm audit over a bun.lockb in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.

If you run bun bun.lockb, it will produce a yarn v1 yarn.lock file. I wonder if there's a way to get npm audit to run on that?

I believe yarn v1 does have an audit command: https://classic.yarnpkg.com/lang/en/docs/cli/audit/

[tim-brand]

If bun documented and supported a canonical way to run an npm audit over a bun.lockb in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.

If you run bun bun.lockb, it will produce a yarn v1 yarn.lock file. I wonder if there's a way to get npm audit to run on that?

Great suggestion!
I tested it, and it works: bun bun.lockb > yarn.lock && yarn audit

[lgarron]

If bun documented and supported a canonical way to run an npm audit over a bun.lockb in the near future, this would be a significant stopgap. As mentioned above, it could allow GitHub to integrate with Dependabot in the long-term, which would be a much better experience than finding out about vulnerabilities months too late.

If you run bun bun.lockb, it will produce a yarn v1 yarn.lock file. I wonder if there's a way to get npm audit to run on that?

Great suggestion! I tested it, and it works: bun bun.lockb > yarn.lock && yarn audit

Ah, that's fantastic! 😄

I don't use yarn, so I didn't realize bun bun.lockb was outputting yarn-compatible data!

I'm not a huge fan of having to use yarn in addition to node, npm, and bun, but it's certainly a very good stopgap until bun audit exists!

---

EDIT: here's a little script I made to avoid writing yarn.lock into repos:

#!/usr/bin/env bun

import { $, spawn } from "bun";
import { cp, mkdtemp, rm } from "node:fs/promises";
import { join } from "node:path";
import { exit } from "node:process";

const tempDir = await mkdtemp("/tmp/bun-audit-temp-");
let exitCode = 0;
try {
  await cp("package.json", join(tempDir, "package.json"));
  await $`bun bun.lockb > ${join(tempDir, "yarn.lock")}`;
  exitCode = await spawn(["bun", "x", "yarn", "--cwd", tempDir, "audit"], {
    stdout: "inherit",
  }).exited;
} finally {
  await rm(tempDir, { force: true, recursive: true });
}
exit(exitCode);

EDIT 2: Published as a package, so you can run: bun x bun-audit
Repo at: https://github.com/lgarron/bun-audit

[lgarron]

EDIT 2: Published as a package, so you can run: bun x bun-audit
Repo at: https://github.com/lgarron/bun-audit

I've been relying on this for a while, but it's kind of inadequate for addressing vulns.

The ip package has a vulnerability and is unmaintained, which took a while for other projects to work around, e.g. modernweb-dev/web#2747

npm audit fix works if I switch my project to use a package-lock.json file, but I can't figure out how to use bun update to bump enough packages to avoid the vulnerable dep, even if I try to combine it with npx npm-check-updates -u. 😕

A bun audit fix command is critical for real-world projects that wish (or are legally required to) address vulnerabilities in a timely manner.

[redbmk]

I've seen cases where the yarn.lock file isn't 100% compatible with yarn, and yarn audit will have issues. Some examples:

Using package.json overrides

❯ cat package.json | jq .overrides
{
  "braces": "^3.0.3",
  "debug": "^4.3.4",
  "express": "^4.19.2",
  "ip": "^2.0.1",
  "jose": "^4.15.5",
  "ws": "^8.18.0"
}
❯ grep ^ws@ -A1 yarn.lock
ws@^8.11.0, ws@^8.14.2, ws@^8.17.0, ws@~8.11.0:
  version "8.18.0"
❯ yarn audit
yarn audit v1.22.21
warning Lockfile has incorrect entry for "debug@^3.1.0". Ignoring it.
warning Lockfile has incorrect entry for "debug@2.6.9". Ignoring it.
warning Lockfile has incorrect entry for "ws@~8.11.0". Ignoring it.
warning Lockfile has incorrect entry for "ip@^1.1.8". Ignoring it.

In this case it finds an issue with ws which was resolved in 8.17.1. Yarn thinks that 8.18.0 is an invalid version for ~8.11.0 and then treats it as if it resolved to 8.11.0, which has the vulnerability. Bun however, only actually installs 8.18.0.

It's possible newer lockfile versions of yarn handle this better or there might be some other syntax that works with the v1 lockfile.

Pointing to a commit on github

❯ cat package.json | jq '.dependencies["@xenova/transformers"]'
"xenova/transformers.js#v3"
❯ cat yarn.lock | grep -A2 '^"@xenova'
"@xenova/transformers@^2.17.2":
  version "2.17.2"
  resolved "https://registry.npmjs.org/@xenova/transformers/-/transformers-2.17.2.tgz"
--
"@xenova/transformers@xenova/transformers.js#v3":
  version "github:xenova/transformers.js#c390936"
  resolved "github:xenova/transformers.js#c390936"
❯ yarn audit
❯ yarn audit
yarn audit v1.22.21
warning package.json: No license field
warning llm-service@1.0.50: No license field
error Can't add "@xenova/transformers": invalid package version "github:xenova/transformers.js#c390936".
info Visit https://yarnpkg.com/en/docs/cli/audit for documentation about this command.

One sort of workaround is to use synp and npm audit which seems to work in this case, however I think synp is actually just ignoring that version because the package-lock.json it generates only shows 2.17.2:

❯ bunx synp@1.9.13 --source-file yarn.lock
Created package-lock.json
❯ grep xenova package-lock.json
        "@xenova/transformers": "^2.17.2",
        "@xenova/transformers": {
          "resolved": "https://registry.npmjs.org/@xenova/transformers/-/transformers-2.17.2.tgz",
❯ npm audit
found 0 vulnerabilities

[Eveeifyeve]

I would say this would have to some how call bun.lockb and do the same functions as yarn audit. It is possible I will see after my bun publish command to try to implement this.

[Eveeifyeve]

As this would be useful to check for vulnerabilities. I don't know how it will exactly would work, but @Jarred-Sumner or someone from the core team could possibly help me?