This makes sense to me. I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo.
Separately, I love the idea of the `geomys/sandboxed-step` action, but I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones. I'll give sandboxed-step a look, sounds like it would be a nice thing to keep in my toolbox.
I was actually working on this last week, funnily enough. I've been working on a capability analysis tool for Rust, and if you're already generating a call graph via static analysis, taking that and matching it against the function-level vulnerability data that exists in RustSec isn't that hard.
Hopefully I'll have something out next week.
> I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones
Yeah, same. FWIW, geomys/sandboxed-step goes out of its way to use the GitHub Immutable Releases to make the git tag hopefully actually immutable.
https://rustsec.org/
Although, unfortunately, not all RustSec advisories include function-level vulnerability metadata in practice.
> I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo.
how about `cargo-audit`?
cargo-audit is not quite at an equivalent level yet, it is lacking the specific features discussed in the post that identify the vulnerable parts of the API surface of a library. cargo-audit is like dependabot and others here in that it only tells you that you're using a version that was vulnerable, not that you're using a specific API that was vulnerable.
Saddly, since it relies on a Cargo.lock to be correct it also is affected by bugs that place dependencies in the Cargo.lock, but are not compiled into the binary. e.g. weak features in Cargo currently cause unused dependencies to show up in the Cargo.lock.