Whitelisting non-vulnerable usages / false positives in advisories

[tarcieri]

This came up via: clap-rs/clap#1569

The specific case is clap is pulling in rust-yaml which has RUSTSEC-2018-0006. They use the vulnerable API, but not in a way that triggers the vulnerability.

I've suggested updating the advisory to note their usage isn't vulnerable, but it'd be nice to be able to specify this programmatically somehow.

Something like:

[unaffected_consumers]
clap = ["2"]

[kbknapp]

Much appreciated! Just off the top of my head, maybe you'd probably want unaffected consumers to require a full version spec? In case the consumer has an update and starts using the vulnerability for real. It's more work to have to update the table to the new version being consumed, but ultimately its for the right reason to keep false negatives away which IMO are worse than false positives.

[ckaran]

[unaffected_consumers]
clap = ["2"]

You might want to force this to go all the way out to the patch level; right now it looks like all of version 2 is unaffected (which is currently correct for clap), but they could add a new non-breaking minor release that is affected. I do like that it's a list though!

EDIT

@kbknapp beat me to it while I was helping my son! 😀

[CreepySkeleton]

And maybe require attaching a bit of context

[unaffected_consumers]
clap = { version = ["2"], reason = "never triggers, only trusted input", discussion = "link to thread" }

Where reason is a summary of why this is not a vulnerability and the discussion link is self evident.

[oherrala]

I'm not against this proposal. It could eliminate a lot of noise and would be good for many users.

However, I really want to know if anything in my tree has vulnerability or some other known issue. Maybe it's not an real issue and it's easy to figure out. But I do want to know there is something somewhere.

I have two reasons for this:

1. I need to know. I'm product owner and I want to keep the decisions about vulnerability management for myself and if something is deprecated I can start looking for alternatives, etc. Tools like cargo-audit and cargo-crev help tremendously with this.

2. There are binary code analysis tools which are looking for vulnerable dependencies from binary code. These tools can't make the judgement if it's a real issue or not. However, they are used to audit a piece of software before purchase or before going to production. I would rather have cargo-audit tell me the issues as early as possible and before these binary analysis tools.

[Shnatsel]

Exploitability is also far from being clear-cut. For example, Microsoft has famously misjudged their use of MD5 in certificates, which turned out to be far more exploitable than it seemed.

I agree that surfacing the presence of vulnerable packages this in some way is a good idea even if certain advisories are suppressed. The presence of suppression in itself can be important.

[ckaran]

What about a new switch? E.g., cargo audit --ignore-whitelists.

Alternatively, we could keep the current behavior, and make a new switch that goes the other way: cargo audit --filter-on-whitelists.

[WaffleLapkin]

cargo audit can also output something like

3 errors were suppressed because of whitelist. Use `cargo audit --ignore-whitelists` to see them.

[ckaran]

I just checked the advisory that is linked at https://rustsec.org/advisories/RUSTSEC-2018-0006, and its description for clap-rs/clap#1569 doesn't seem to have been updated yet. Can it be updated?

[tarcieri]

Yep, either open a PR to update the advisory or I can try to look at it later this weekend.

[ckaran]

@tarcieri I'm afraid I'm going to have to wait for you to look into it, I'm tracking down a nasty bug in my code involving serde_json right now.

[miaujennifer]

I'm not against this proposal. It could eliminate a lot of noise and would be good for many users.

However, I really want to know if anything in my tree has vulnerability or some other known issue. Maybe it's not an real issue and it's easy to figure out. But I do want to know there is something somewhere.

I have two reasons for this:

1. I need to know. I'm product owner and I want to keep the decisions about vulnerability management for myself and if something is deprecated I can start looking for alternatives, etc. Tools like cargo-audit and cargo-crev help tremendously with this.
2. There are binary code analysis tools which are looking for vulnerable dependencies from binary code. These tools can't make the judgement if it's a real issue or not. However, they are used to audit a piece of software before purchase or before going to production. I would rather have cargo-audit tell me the issues as early as possible and before these binary analysis tools.

[pinkforest]

SInce both we cannot address this is in advisory-db today and there is now compherensive tooling issue under rustsec/rustsec

We'll close this one in favor of consolidating the attention to: rustsec/rustsec#505

Thanks everyone