Dubious code for vendor guessing in OSV source

[gluesmith2021]

This is probably only a potential issue as it doesn't seem to have any effect for now.

On the following line, what is "github" doing there? was it supposed to be part of another condition to check?

https://github.com/intel/cve-bin-tool/blob/ae66713878e2b53d22134fab6eb34d9462beac71/cve_bin_tool/data_sources/osv_source.py#L300C16-L300C16

As for now, only the "/" check is really a condition ("github" is always converted to True for the if), so a vendor name is extracted for every product name with a slash in it.

It has no effect for now: when populating the DB, for any given CVE, either

• the vendor name guessed from OSV source is replaced with previously ingested vendor names for the CVE product,
• the CVE entry is dropped if there is no pre-existing vendor name.

This would become an issue if guessed vendor names would actually be used (or are there cases already where they are used?) For instance, many product names for Andoid-related CVEs from OSV are path-like, and the second last part does not hint at a vendor name, such as "platform/frameworks/base", "platform/build/soong", "platform/external/v8", etc.

This also raises the question whether OSV source parser should try to guess vendor names at all if they are not meant to be used.

[terriko]

I'd have to dig through the history, but I think this was started to address a particular issue with how things that looked like github urls were being parsed? I think you're right that it's not the best possible solution.

I think eventually PURL adoption might solve this, and we've been noodling around some ideas about having a set of mappings that uses PURL internally (See #3180 for some discussion), but that's likely a ways out.

I'm very open to ideas on viable heuristics to make this less inaccurate Right Now if anyone's got good ideas, and I'm open to someone working on #3180 to make it happen sooner and/or better.