Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support scanning Rust binaries built with cargo auditable #1332

Open
Shnatsel opened this issue Oct 18, 2024 · 7 comments
Open

Support scanning Rust binaries built with cargo auditable #1332

Shnatsel opened this issue Oct 18, 2024 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@Shnatsel
Copy link

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
Copy link
Collaborator

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

@oliverchang oliverchang added backlog Important but currently unprioritized enhancement New feature or request and removed backlog Important but currently unprioritized labels Oct 20, 2024
@oliverchang
Copy link
Collaborator

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

@G-Rath G-Rath self-assigned this Oct 23, 2024
@G-Rath
Copy link
Collaborator

G-Rath commented Jan 6, 2025

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
Copy link
Author

Shnatsel commented Jan 6, 2025

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
Copy link
Collaborator

G-Rath commented Jan 8, 2025

Looks like someone has beaten me to it: google/osv-scalibr#377 😄

@Shnatsel
Copy link
Author

Shnatsel commented Jan 8, 2025

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants