Absence of RUSTSEC advisories for Wasmtime security vulnerabilities #10344
Comments
|
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. |
I see, that would be great and solve a lot of manual work. I was considering alternatives to OTOH, do you see any blockers for publishing RUSTSEC for wasmtime? |
|
I'm not involved in the handling of Cranelift/Wasmtime security issues myself, so I don't know if there are any blockers. |
Add bytecodealliance/wasmtime#10344 to the agenda.
|
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. |
|
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. |
[Wasmtime] recently got a [request] to have our security advisories published on the RustSec database as well. We've got a few old advisories on here but we haven't been keeping up-to-date with later advisories. In lieu of automatic imports from GitHub to RustSec we figured we'd in the interim manually fill in some fields. In this PR I'm filing a security advisory for [GHSA-88xq-w8cq-xfg7] which is a 3-year-old advisory at this point. This is to serve as an example for future imports of Wasmtime advisories so my hope is to get everything ok, copy this behavior for our other advisories that aren't listed in RustSec, and then applying this process to future advisories. [Wasmtime]: https://crates.io/crates/wasmtime [request]: bytecodealliance/wasmtime#10344 [GHSA-88xq-w8cq-xfg7]: GHSA-88xq-w8cq-xfg7
|
Follow-up on this: we discussed this at the Wasmtime meeting last week and our conclusions were:
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. |
|
Hm the inactivity on rustsec/advisory-db#2254 is not necessarily inspiring confidence in hitching our process to theirs... |
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-auditrelies 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.The text was updated successfully, but these errors were encountered: