ossf / osv-schema

Open Source Vulnerability schema.
https://ossf.github.io/osv-schema/
Apache License 2.0
175 stars 75 forks source link

Additional options for references field to support reproducers/exploit code #78

Closed kurtseifried closed 1 year ago

kurtseifried commented 2 years ago

This is in relation to: https://github.com/cloudsecurityalliance/gsd-database/issues/2389

Ok meta comments:

Obviously, we want this added as a reference, but the OSV schema only supports:

https://ossf.github.io/osv-schema/#references-field

ADVISORY: A published security advisory for the vulnerability. ARTICLE: An article or blog post describing the vulnerability. REPORT: A report, typically on a bug or issue tracker, of the vulnerability. FIX: A source code browser link to the fix (e.g., a GitHub commit) Note that the fix type is meant for viewing by people using web browsers. Programs interested in analyzing the exact commit range would do better to use the GIT-typed affected[].ranges entries (described above). PACKAGE: A home web page for the package. EVIDENCE: A demonstration of the validity of a vulnerability claim, e.g. app.any.run replaying the exploitation of the vulnerability. WEB: A web page of some unspecified kind.

So it could be classed as "EVIDENCE", which is what I'll use for now, but I'm going to file an upstream issue with OSV to try for a better word, e.g.:

REPRODUCER: Nonweaponized, programmatic method to trigger the vulnerability? EXPLOIT: weaponized, programmatic method to trigger the vulnerability (can be a link to code?) EXPLOITATION: reports of exploitation but no actual technical reproducer/exploit available?

I think one possible way to do this would be to use "sub tags" e.g. EVIDENCE:EXPLOIT or EVIDENCE:REPRODUCER. This would prevent clutter and an explosion of top level tags, and for data consumers they can for example simply support "EVIDENCE" and ignore subtags, or choose to also support subtags, either way they are able to broadly classify the data according to the top level tags, even if they don't want to check for subtags.

oliverchang commented 2 years ago

The description for "EVIDENCE" seems to fit this particular use case perfectly. CC @joshbuker who added it (and who opened https://github.com/ossf/osv-schema/pull/50 for discussion which seems similar).

In terms of a more fine grained way to annotate these, I think we should think more about the intended use case. The intended use case of these broader reference categories was to provide a machine readable mechanism for frontends/UI to roughly group links and for humans to quickly filter out things they don't care about.

If we try to make these more fine grained, what's the end use case for a consumer? Why is REPRODUCER vs EXPLOIT important to distinguish in the schema itself? What do we gain vs having someone just open the link?

kurtseifried commented 1 year ago

Can we also add:

DETECTION (e.g. https://github.com/VNCERT-CC/0dayex-checker) DISCUSSION (e.g. the reddit/twitter threads on this, they're not an article/web/evidence/etc)

joshbuker commented 1 year ago

+1 on DETECTION and DISCUSSION.

I think they add enough value to end users and are distinct enough from other types to be worth including.