Add OPEV-0016 by macedogm · Pull Request #24 · openvex/community

macedogm · 2026-04-13T23:40:38Z

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.

Closes openvex/spec#31

Signed-off-by: Guilherme Macedo <guilherme@gmacedo.com>

macedogm · 2026-04-13T23:42:54Z

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

fahedouch · 2026-04-14T07:36:56Z

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 · 2026-04-14T12:51:35Z

@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 · 2026-04-27T18:39:37Z

+
+| Field | Required | Description |
+| ----- | -------- | ----------- |
+| source | ✕ | An object that contains information about the entity that is providing the vulnerability's rating. |


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.

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.

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.

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 · 2026-04-27T18:43:32Z

+    {
+      "vulnerability": {
+        "name": "CVE-2025-68121",
+        "ratings": [


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).

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.

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.

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.

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.

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

puerco · 2026-04-27T18:44:56Z

+            "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N"
+          },
+          {
+            "source": {


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.

@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?

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?

All JSON-LD elements have an ID which is used to reference them in the linked data graph. This ID exists implicitly even if it is not in the JSON code.

puerco · 2026-04-27T18:48:04Z

+  `severity` or a `vector` must be provided, otherwise there is no purpose in
+  having an empty object that contains no actionable rating for the
+  vulnerability.
+- Strict formatting of `severity` isn't enforced, because some authors might


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.

I've updated the spec to consider this now.

Signed-off-by: Guilherme Macedo <guilherme@gmacedo.com>

macedogm · 2026-05-07T14:11:30Z

@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 · 2026-05-07T14:52:31Z

+| source      | ✕ | An object that contains information about the entity that is providing the vulnerability's severity. |
+| source.name | ✕ | The `name` of the entity providing the severity. |
+| source.url  | ✕ | A `url` linking to a page that further describes the vulnerability or the severity. |
+| rating      | x | An object containing zero or more ratings of the vulnerability. |


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.

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

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?

Signed-off-by: Guilherme Macedo <guilherme@gmacedo.com>

cwayne18 · 2026-07-09T20:52:33Z

any update on this? Would be a great addition IMHO

kaz-33 · 2026-07-22T12:08:06Z

Hi Team, any reason to block this PR? it seems it miss an human review? @puerco @alegrey91 @macedogm

alegrey91 · 2026-07-24T10:17:40Z

Hi Team, any reason to block this PR? it seems it miss an human review? @puerco @alegrey91 @macedogm

Hi @kaz-33, final review is not in our hands. We are waiting for the project maintainers to get approval.

kaz-33 · 2026-07-28T07:41:52Z

thx @fahedouch ! what is the next step?

alegrey91 · 2026-07-28T07:52:51Z

thx @fahedouch ! what is the next step?

Hello @kaz-33, we are waiting for other maintainers to approve it.
Just out of curiosity, how this feature matches your needs? I'm curious to know how does this impact your daily job.

kaz-33 · 2026-07-28T08:58:46Z

@alegrey91 We would like to integrate OpenVEX inside supply chain to promote Image with Trivy(e.g) and trigger the number of CVE Critical. Critical > 0, no promoted. OpenVEX will used to automate exchange with supplier but sometime "affected" to "no_affected" no working cause they change the level of severity, affected + critical >> affected +minor, with openVEX actually, only status is present.

alegrey91 · 2026-07-28T09:06:40Z

@alegrey91 We would like to integrate OpenVEX inside supply chain to promote Image with Trivy(e.g) and trigger the number of CVE Critical. Critical > 0, no promoted. OpenVEX will used to automate exchange with supplier but sometime "affected" to "no_affected" no working cause they change the level of severity, affected + critical >> affected +minor, with openVEX actually, only status is present.

cool! thanks for sharing. I'm glad to hear that someone else has similar needs :)

puerco · 2026-08-28T18:39:28Z

+- The `type` specifies how to parse the `score` string and must be one of the
+  following:
+  - `cvss_v2` - for the CVSS v2.0 format.
+  - `cvss_v3` - for the CVSS v3.x format.
+  - `cvss_v4` - for the CVSS v4.x format.
+  - `owasp` - for the OWASP Risk Rating Methodology format.
+  - `ssvc_v2` - for the CISA Stakeholder-Specific Vulnerability Categorization v2.x format"
+  - `sev` - a string containing directly the rating/severity.


If the type field is a fixed enum, should we enforce some sort of structure either in the value string or a struct?

From a policy perspective it sounds like we need a source of truth on how to parse each type for validation and to ensure properly formatted values are carried forward to systems that expect them.

For example validating a doc should reject an invalid CVSS string, this would also guard other systems from rejecting the vex document (or the score value)

miniprow · 2026-08-28T18:39:35Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: fahedouch, macedogm
Once this PR has been reviewed and has the lgtm label, a repository administrator can /approve this pull request. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from a repository administrator.

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

puerco · 2026-08-28T18:40:39Z

/hold for discussion

puerco · 2026-08-28T18:40:54Z

/hold

puerco · 2026-08-31T18:50:01Z

+        "source": {
+          "name": "Acme - Security team",
+          "url": "https://www.example.com/cves/cve-2025-68121.html"


Question: "source" is the agent (person or tool) reclassifying the vulnerability?

Source is the person (entity/company) doing the reclassification. It isn't the tool.

TODO: remove the source field for the moment, in the future we can tie it to a way of verifying identity/signature of the doc's author with the re-scoring, for example.

Add OPEV 0016

df2e5e4

Signed-off-by: Guilherme Macedo <guilherme@gmacedo.com>

macedogm mentioned this pull request Apr 13, 2026

Modify severity openvex/spec#31

Open

puerco reviewed Apr 27, 2026

View reviewed changes

Address feedback from pr and sig meeting

a779336

Signed-off-by: Guilherme Macedo <guilherme@gmacedo.com>

macedogm requested review from alegrey91, fahedouch and puerco May 7, 2026 14:10

fahedouch reviewed May 7, 2026

View reviewed changes

Address feedback from pr

1f797fd

Signed-off-by: Guilherme Macedo <guilherme@gmacedo.com>

puerco mentioned this pull request Jul 20, 2026

Maintainer nomination: @macedogm #28

Closed

fahedouch approved these changes Jul 24, 2026

View reviewed changes

puerco reviewed Aug 28, 2026

View reviewed changes

miniprow Bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command label Aug 28, 2026

puerco reviewed Aug 31, 2026

View reviewed changes

puerco changed the title ~~Add OPEV 0016~~ Add OPEV-0016 Aug 31, 2026

Conversation

macedogm commented Apr 13, 2026 • edited by puerco Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

macedogm commented Apr 13, 2026

Uh oh!

fahedouch commented Apr 14, 2026

Uh oh!

macedogm commented Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

puerco left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

macedogm commented May 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cwayne18 commented Jul 9, 2026

Uh oh!

kaz-33 commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alegrey91 commented Jul 24, 2026

Uh oh!

kaz-33 commented Jul 28, 2026

Uh oh!

alegrey91 commented Jul 28, 2026

Uh oh!

kaz-33 commented Jul 28, 2026

Uh oh!

alegrey91 commented Jul 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

miniprow Bot commented Aug 28, 2026

Uh oh!

puerco commented Aug 28, 2026

Uh oh!

puerco commented Aug 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

macedogm Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

macedogm commented Apr 13, 2026 •

edited by puerco

Loading

macedogm commented Apr 14, 2026 •

edited

Loading

kaz-33 commented Jul 22, 2026 •

edited

Loading

macedogm Aug 31, 2026 •

edited

Loading

macedogm Aug 31, 2026 •

edited

Loading