Add OPEV 0016

[macedogm]

As discussed in openvex/spec#31 and in the OpenVEX SIG meeting on April 13th, this OPEV proposes to extend the OpenVEX spec to allow re-scoring vulnerabilities. The extension is minimal, doesn't break backwards compatibility and follows the original NTIA VEX spec.

[macedogm]

@puerco PTAL and thanks for the support of the OpenVEX SIG.

[fahedouch]

Great news! I couldn't make it to the meeting yesterday. So, am I right in understanding that OpenVEX has agreed to support ratings in its spec?

[macedogm]

@fahedouch those that were in the OpenVEX SIG meeting sympathize with this proposal, because they face the same issue (overall need to provide better scoring at product level instead of the generic scoring from the upstream source). They agreed to get it reviewed, improved and them be submitted for official voting from the maintainers of the spec.

[puerco]

Thanks for the proposal, I am excited to now have this capability under a more formal discussion track. I have some initial comments and questions 👇

[puerco]

We are considering adding a proper identity structure. To the spec. The current plan is to model it to record actors (people or bots) or tools. Can you provide more context on the types of entities you expect reference here?

In the end we will unify this part of the proposal with the new identity struct.

[macedogm]

To me the entity is similar to the author field of the report, it provides more details about who did the re-score. I believe that for most of the cases it will be the same person/company that generated the entire report, but I also believe that we should be flexible and allow it reference some 3rd-party if needed. The source.url is to allow to link the re-score to an external link that can provide more details about it.

[alegrey91]

I agree with @macedogm, since VEX format already has the author and role fields, this might result in redundancy here.
I would go with something minimal, only to give more details to the final user, such as source.url or at most with an optional field details.

[fahedouch]

I agree with both @alegrey91 and @macedogm, keeping it minimal with source.url (and maybe an optional details) feels right. The doc-level author/role already covers the identity part.

[puerco]

Since we have a list of reclassifications, how are tools expected to understand which of these apply to them.

In this example: if I have a policy engine to block on a 7.5 or higher, score which of the two reclassifications should it pay attention to?

SLSA, for example, uses a builderId URI to identify and define the expectations of a build system. Here, we may need something like it (unless you want to do it only based on the source).

[macedogm]

My expectation is that tools (scanners) will respect the VEX data that was provided and follow it over their default score. From my main experience with Trivy, once you provide a VEX report to it, it will by default suppress vulnerabilities that it matches, so here I see the same logic being applied, by default it will either suppress a matched vulnerability or re-score it if it's a match.

So on your example, the policy engine must respect the VEX data and if the score in the example is lower than the block threshold, then that vulnerability will not be blocked if the re-score is now lower. The reasoning here is that the user/operator must properly check and trust the VEX report in question before feeding it to its tools.

SLSA, for example, uses a builderId URI to identify and define the expectations of a build system. Here, we may need something like it (unless you want to do it only based on the source).

I haven't thought about that. I don't believe that such context would be relevant here, so it would be based only on the source.

[fahedouch]

Looking at the example, both ratings come from the same source but different CVSS versions — so the source-based logic alone doesn't disambiguate.

The current spec doesn't have a method field — version/format is only implicit via the vector prefix, which works for CVSS but breaks for OWASP RR, EPSS or SSVC. Adding an explicit method (cvss-v3.1, cvss-v4.0, owasp, ssvc, other) would let consumers filter cleanly without needing a builderId-style URI.

For the residual case (same source, same method, diverging values), the spec could just say "order is precedence, last wins" and let consumers override via their own policy.

[macedogm]

I've updated the spec and added a type that lists the supported types for the score and allows to more easily parse the provided score. PTAL.

[fahedouch]

Adoption of type looks great. One thing missing: other as a value in the enum. It would act as an escape hatch and avoid a spec bump every time a new scoring system shows up.

[macedogm]

@puerco wdyt ^? it makes sense and I can quickly update the proposal

[puerco]

Formal nit: Since openvex is JSON-LD, the reclassification struct will need an @id field (which can be implicit). Just noting it as it needs to go into the spec below.

[macedogm]

@puerco I'm a bit lost here. What would be a good @id in this case? Can you please share some ideas? Could it be the actual source.url? If yes, then it would have to be mandatory, and we could even remove the source.name to make it smaller and simpler, given that it would be implied from the source.url. On the other hand, if the provider of the report doesn't have a place to publish its source.url, then what would be a good candidate for the @id?

[alegrey91]

Same here, I don't see the point of the @id attribute. What's the benefit of having an ID for this kind of information?

[puerco]

FYI, initially we didn't enforce a strict enumeration on the hash fields and very quickly led into problems. Not saying this is the same case but just some advice from paste experiences.

[macedogm]

I've updated the spec to consider this now.

[macedogm]

@puerco the spec is now updated to address the feedback from the pr and also from the last sig meeting. I've only one open question about the @id that I tagged you above. Thank you!

[fahedouch]

naming nit: rating is singular but holds a list, should be ratings. And severity as the outer name is confusing — usually severity = the category (low/med/high), not the container.

[macedogm]

@fahedouch your comment makes sense and I've updated the proposal to try to eliminate any confusion, ptal.

[fahedouch]

thanks. Small follow-up: the inner list is now severities but each entry is {type, score} — those are scores/ratings, not severity categories. Would scores or ratings be a better fit?