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.

▲

FiloSottile 9 hours ago | parent | next [-]

> 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.

▲

conradludgate 9 hours ago | parent | prev | next [-]

https://rustsec.org/

▲

bpavuk 9 hours ago | parent | prev [-]

> I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo.

how about `cargo-audit`?

▲

mirashii 8 hours ago | parent [-]

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.

	▲	hobofan 8 hours ago \| parent [-]
		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.