Absence of RUSTSEC advisories for Wasmtime security vulnerabilities

[venkkatesh-sekar]

Currently, Wasmtime's security disclosure process includes an announcement via the security mailing list upon a patch release, along with a corresponding GitHub security advisory published on the disclosure date. While this process is comprehensive, it does not account for users who rely on tools other than Dependabot PRs for automatic vulnerability detection.

For instance, cargo-audit relies exclusively on the RUSTSEC advisory database to flag vulnerabilities, which has become the preferred method for automated detection in Rust. Hence, could we start considering publishing RUSTSEC advisories alongside GitHub security advisories as part of the standard disclosure process.

[bjorn3]

The github security advisories db should import advisories from the rustsec db. As for the other way around I believe that is partially implemented but not actually running automatically yet. No clue about the current status of that work though.

[venkkatesh-sekar]

As for the other way around I believe that is partially implemented but not actually running automatically yet. No clue about the current status of that work though.

I see, that would be great and solve a lot of manual work. I was considering alternatives to cargo-audit and looks like osv-scanner does combine both databases when scanning Cargo.lock files.

OTOH, do you see any blockers for publishing RUSTSEC for wasmtime?

[bjorn3]

I'm not involved in the handling of Cranelift/Wasmtime security issues myself, so I don't know if there are any blockers.

[alexcrichton]

I've added this to our upcoming meeting agenda -- bytecodealliance/meetings#557

@bjorn3 would you happen to have a link to the work to auto-import to rustsec? I looked thorugh some existing advisories for Wasmtime in rustsec and it looks like they've all been manually imported so far, so I figured we'd probably have to keep doing that but if there's work to auto-import that'd also be neat.

[bjorn3]

The discussion seems to be fragmented over a bunch of issues and PRs. One of them is rustsec/rustsec#656. Another is rustsec/advisory-db#1711.

[alexcrichton]

Follow-up on this: we discussed this at the Wasmtime meeting last week and our conclusions were:

• We'll add this to our security issue process going forward.
• For now I'll open an issue about back-filling advisories.

I sent rustsec/advisory-db#2254 for backfilling a single advisory to double-check that the "mostly empty" report is ok for RustSec folks. If that's ok I'll send a PR to update documentation for our own runbook and point to that PR as an example advisory. I'll then file a follow-up issue for backfilling the existing adviories.

[alexcrichton]

Hm the inactivity on rustsec/advisory-db#2254 is not necessarily inspiring confidence in hitching our process to theirs...