Ability to mark a vulnerability as only impacting certain release artifacts

[alex]

Hi, @woodruffw suggested I file this here, since the Python vulnerability data uses the osv schema.

I'm one of the maintainers of the popular python cryptography package. We ship both source ("sdist") and binary ("wheel") artifacts for all of our releases.

Our binary wheels include a statically linked copy of OpenSSL. This copy may be impacted by upstream OpenSSL security issues.

We'd like to mark our package as impacted by these, so users are aware. However, our source packages are not impacted by these, since they don't include a copy of OpenSSL -- they link against the system OpenSSL. If we simply mark a vulnerability as impacting our package, it'll generate false positives for any source users, contributing to alert fatigue.

We'd therefore like some sort of additional metadata to specify that only some artifacts are impacted by a given vulnerability.

[oliverchang]

This seems like a candidate for ecosystem_specific, which other systems such as Go describes here: https://go.dev/security/vuln/database

We could have something that encodes this fact there.

[oliverchang]

Another consideration here: How would automation determine this? Most scanners would just read e.g. a requirements.txt or Pipfile.lock file. How would they make the determination about if something will be/is installed via a source or binary package?

[di]

One way we could do this is via hashes: if OSV supported specifying the hashes of specific artifacts that are vulnerable, a record could be more fine-grained that just 'project name + version', and it wouldn't need to be ecosystem-specific.

This would also answer the question about how automation would determine this: for requirements files that are hash-pinned, it would consider only those hashes to be installable, skipping the need to determine if it's source or binary or something else. If the requirements file doesn't include hashes, then we can't take the fine-grained hashes in the record into account.

In practice though, when hash-pinning, I think most users include all possible hashes, so this might not have a huge effect on reducing false positives, but I still think this would be worth doing.

[alex]

The hashes approach is clever (particularly with "known not impacted hashes")!

[github-actions[bot]]

This issue has not had any activity for 60 days and will be automatically closed in two weeks

[woodruffw]

Not stale. @oliverchang, any chance we could mark this as "in progress" or "discussion" or similar to keep it alive :slightly_smiling_face:?

[oliverchang]

Not stale. @oliverchang, any chance we could mark this as "in progress" or "discussion" or similar to keep it alive 🙂?

Thanks for the ping! Yes, I've added the backlog label to keep this one alive.