Display known vulnerabilities of a crate in the UI

[jmwoliver]

Overview

Hey Rust community!

I've been playing around with displaying known vulnerabilities of a crate within the crates.io UI. The data would be pulled from the Open Source Vulnerabilities database (osv.dev) and displayed if any exist. It could then link to the original vulnerability report for more information.

Here's an example API call for crates.io on the package borsh:

curl -d '{"package": {"name": "borsh", "ecosystem": "crates.io"}}' "https://api.osv.dev/v1/query"

From what I understand, the RustSec Advisory Database pushes their vulnerabilities to osv.dev and the OSV endpoint is allowed to be consumed freely. I think the vulnerabilities are already surfaced within other tools as well:

• cargo-audit
• cargo-deny
• trivy
• dependabot

So this would just expose information in the UI that those tools are already surfacing.

I'm new 'round these parts, so I'm not sure if this has been discussed before or if crates.io doesn't like calling out to external APIs. I searched past discussions and issues, but didn't find anything. Please let me know your thoughts, I’d appreciate any feedback! I'd love to work on this if it is acceptable to pursue.

Mock Ups

Creating a new Known Vulnerabilities tab:

Displaying the vulnerabilities on that tab:

[jmwoliver]

Hello @Turbo87! Not to bug you, but I'd love to hear your feelings on this idea.

[Turbo87]

Sorry for the delay...

This proposal looks somewhat related to #6397. I think @LawnGnome has some thoughts on this, but he is currently at a conference and hadn't had time to respond to this yet.

I generally would like to surface vulnerability reports in the frontend, but the details on how exactly we would like to do that are still tbd. :)

[jmwoliver]

No problem, thank you for your thoughts! It does seem related to that one. I initially thought they were separate, but reading it again makes me think instead of a Known Vulnerabilities tab, it would be the Security tab like proposed in #6397. Then within that tab would be a Known Vulnerabilities section.

I'll wait to see what comes of #6397, but I'd love the chance to work on this portion of it if it ends up being the route that is agreed upon!

[LawnGnome]

Sorry, I'm at Open Source Summit this week, so it's been hard to find half an hour to write up my thoughts! Anyway, I have a doughnut and coffee in front of me, so let's see where we can get to. ☕

I think you're right that this would fit into the Security tab being proposed in #6397 in the longer term. I'd love to work with you on this when we get there! It might be a little while before we're ready for this, though: as you would have seen in #6397, there's a consensus that the Security tab work will require multiple RFCs. I intend to start drafting an RFC for a basic security tab just showing a security policy (if one exists) next week, which feels like it would be a hard prerequisite before we could start thinking about scoping this.

Other considerations that I think we'd need to work through before working on an implementation would include:

• Are we going to try to display vulnerabilities in transitive dependencies?
  • (My bias on this, for what it's worth, is that we probably shouldn't: there's no realistic way for us to know if a downstream package is actually used in a way that triggers a vulnerability given the level of detail we have available in RustSec advisories — even if the advisory includes function-level metadata, we still can't figure out if the specific conditions are met for the vulnerability.)
• How do we communicate vulnerabilities in older versions? (Or do we even attempt to?)
  • (Related to this, although less common in the Rust ecosystem than some others, would be a case where a crate has multiple major versions still being maintained: if 1.2.3 is vulnerable to something for design reasons that can't be fixed without a BC break, but the already-extant 2.3.4 isn't, how do we communicate that nuance?)
• How can we ensure that we communicate actual risk levels appropriately?
  • (The specific sort of case I'm thinking of here is "crate x is vulnerable in a very minor way on something behind a feature flag and the maintainer hasn't seen a need to prioritise rushing out a fix" — I don't think we'd want to discourage users from using that crate, necessarily, and just having a big vulnerability block feels scary.)
• Finally, technically, how would we want to access/persist this in crates.io? Obviously, we could just call out to the osv.dev API from the frontend, as you said, but I'm unsure if we'd want to pull that data and cache it on the backend — the cost of doing so would have to be weighed against the reliability of osv.dev (not the mention the extra load we might put on that service).

To be clear: I don't expect answers to this all today. 🙂 This is just a braindump of things that I can think of that will eventually need to be addressed in an RFC/issue/whatever the right decision making form for this would be.

[jmwoliver]

@LawnGnome Thanks so much for responding! I agree, this work is probably a ways out since the Security tab hasn't yet gone into the RFC phase. I'm definitely happy to help with this part once it gets there if you'd like though!

Your questions are also really good. I was thinking this would be a "do-what-you-want-with-this-info" kind of option. If a user wants to dig deeper to make sure it is not an issue in their use-case, then it is available for their perusal. Maybe that is not a good approach though, it might be more intimidating than it is helpful.

From what I've seen playing around with the advisories DB (which isn't very much), it seems pretty willy-nilly on how much detail it gives about impacted versions and level of severity. Here's the output of cargo-audit audit on a Cargo.lock file that has a crate with a vulnerability (borsh) for comparison:

$ cargo-audit audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 543 security advisories (from /Users/jacobwoliver/.cargo/advisory-db)
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (90 crate dependencies)
Crate:     borsh
Version:   0.10.3
Warning:   unsound
Title:     Parsing borsh messages with ZST which are not-copy/clone is unsound
Date:      2023-04-12
ID:        RUSTSEC-2023-0033
URL:       https://rustsec.org/advisories/RUSTSEC-2023-0033
Dependency tree:
borsh 0.10.3
└── hui 0.1.0

In the same way, crates.io could present that info as-is and let the user dig deeper with the advisory URL provided. Again, perhaps that isn't the best approach and should be fleshed out more.

Thanks again for your time!

[tarcieri]

Hello, I started @rustsec!

This looks great but I think it might also be nice to have a more general-purpose "Security" tab which could also display a crate's SECURITY.md in addition to @rustsec advisories, similar to how README.md is displayed today.