false positive: name collision for python arrow vs rust arrow

[terriko]

Apparently there is a Rust package called arrow which has some issues associated with it in OSV, such as https://rustsec.org/advisories/RUSTSEC-2021-0117.html

There is also a python package called arrow which one of our dependencies uses: https://pypi.org/project/arrow/

As a result, we're getting OSV issues for the wrong package. This is similar to #3179 and #3152 and should likely be resolved by cve-bin-tool itself as discussed in #3180

[anthonyharrison]

@terriko This is where the use of PURLs can really help. Looks like #2685 #2945 need prioritsing

[inosmeet]

Running this shows unknown vendor, but only after looking into the CVE number we know that this is from Rust and not python. In our current implementation of both purl and mismatch, we only handle invalid relations associated with vendors and as this returns unknown vendor, I don't think we can tackle this with purl or mismatch.

Triage maybe our only option here ? cc @mastersans

[anthonyharrison]

@inosmeet @mastersans @terriko

If we have don't have a purl or a vendor to be able to determine the type of component, then triage is the only way we can distinguish between the rust and python components. Suggest that this is included in the triage documentation as a use case.

FUTURE idea might be to separate components with an unknown vendor and no purl as CANDIDATE vulnerabilities. This is in effect adding a confidence factor to the vulnerability identification - 100% is we have a vendor/package/version match, less if we have no vendor etc) and then maybe add the confidence indicator as a command line parameter.

[terriko]

This is going to be a pretty common scenario, and I think we need a fix that bypasses the need for triage because it'll save a huge amount of work for our users.

Two quick options:

• add invalid_purl into the mismatch data to go alongside invalid_vendor (In this case "RUSTSEC-2021-0117" has a purl of "pkg:cargo/arrow". See https://api.osv.dev/v1/vulns/RUSTSEC-2021-0117)
• add invalid_id into the mismatch data to go alongside invalid_vendor (in this case that would be "RUSTSEC-2021-0117")

Of the two, invalid_purl would catch a lot more stuff so it's probably the best option unless we encounter something that has neither a vendor nor a purl. I think it should be fairly straightforward to implement given the code you already have.

That said... @inosmeet has what, a week left to finish docs and final write-up? I this this is doable but I don't want to add it to your workload this late in the game, and I don't think I'm getting it into the 3.4 pre-release.

How would you feel about me (or someone else) adding purl mismatch capability after you finish your wrap up for the year, targeting either 3.4 final release or a 3.4.1 point release?

[inosmeet]

I'll try to look into it after I get in the docs and final draft report. I'm not sure if this approach can help at parsers level though.

[terriko]

Yeah, it might have to happen at some sort of filtering level in with the triage if you don't pull the purls from the OSV stuff until then.

[terriko]

But I still think storing it with the mismatches is the right choice, even if it might have to be looked up elsewhere!

[terriko]

Moving this to future, since I don't think it's happening in the 3.4 timeframe.