Support scanning Rust binaries built with `cargo auditable`

[Shnatsel]

cargo auditable is a project by Rust's Secure Code WG. It embeds the list of dependencies into the binary itself, so that it can then be audited for known vulnerabilities.

Auditing such binaries is already supported by cargo audit and Trivy. It would be nice to get support for it in osv-scanner as well.

cargo auditable is used for all Rust builds by at least 5 Linux distributions, including Alpine. A number of organizations use cargo auditable, but to the best of my knowledge only Microsoft has spoken about it publicly.

There is already a Go library for extracting this data, which should make the integration quite easy: https://github.com/microsoft/go-rustaudit

I am the principal author of cargo auditable and I'm happy to answer any questions you might have.

[oliverchang]

Thanks for the FR. this indeed looks like a great fit for OSV-Scanner.

[oliverchang]

@G-Rath is this something we can put in your backlog?

[G-Rath]

Since my understanding is that we have to open a file to know if its Rust + supports this and I assume doing that for every/most files would be relatively expensive, our thinking for support would be as an explicit opt-in like with Alpine, JSON, etc? i.e. osv-scanner --lockfile cargo-auditable:path/to/my/rust/binary

I also assume this should actually now get added to osv-scalibr as a new extractor there, rather than here but that shouldn't mean the core implementation can't be worked on in the meantime

[Shnatsel]

That makes sense to me. For example, Trivy requires an explicit opt-in to look for cargo auditable data in binaries with the --cataloguers option. I believe the scalibr equivalent would be requiring to explicitly add an extraction/detection plugin to scalibr.ScanConfig.

The use case of recursively scanning a directory and looking for cargo auditable data in binaries is still quite important. So Trivy-like configuration to opt in to the detection plugin and then apply it to all the regular operations, including recursive scanning, seems like the best option to me.

[G-Rath]

Looks like someone has beaten me to it: https://github.com/google/osv-scalibr/pull/377 😄

[Shnatsel]

That PR's approach with filesystem.IsInterestingExecutable by looking at the executable bit on Unix and file extensions on Windows sounds good to me. It sounds like it would reduce the amount of files to be looked at to a manageable amount to allow enabling the scanner by default.

[rpbeltran]

Hadn't seen this Github Issue before making the PR but greatly appreciate everyone's input, thanks!

[Shnatsel]

The extractor has been available in osv-scalibr for a while, and it is getting wired up to osv-scanner in https://github.com/google/osv-scanner/pull/1770