OPEV: Expansion of the Vulnerability Field

[puerco]

OPEV # 0015: Expansion of the Vulnerability Field

🖊️ Enhancement Overview

During the development of the initial implementations, there have been issues raised about the need to expand the vulnerability field. While this OPEV only addresses the need to expand the vulnerability field 1) become an object and to
2) to express more names or aliases of a vulnerability, members of the community have pointed to other cases where the vulnerability entry needs to be expanded from an identifier string to a full struct.

🧑‍💻 Enhancement Proposal Authors

• @puerco

👩‍🔧 Sponsoring Maintainers

(not required)

📋 OpenVEX Projects

• openvex/spec
• openvex/go-vex
• openvex/vexctl

📐 Specs and Documents

Pull Request open: #17

❓ Enhancement Questions

Does this enhancement propose a change to the OpenVEX project's governance
structure?

NO

Does this enhancement propose a breaking change with the upstream VEX design
established by the VEX Working Group?

NO

💬 Discussion Start Date:

OPEVs shall be discussed for no longer than 30 days after which the vote tally
will be computed and the proposal will either merge or be rejected.

Start Date: 2023-07-09

🗳️ Voting Results

Final Enhancement Vote Tally:

Final Enhancement Vote Tally:

👍 : 3 Votes @lumjjb @wagoodman @puerco (implicit) | non binding: @SecurityCRob

👎 : 0 Votes

---

ℹ️ Voting Instructions:

To vote for this enhancement, maintainers should add a comment with a 👍 emoji
to show support or 👎 to reject the enhancement. After voting is over (usually
after 30 days), votes will be computed by the project's mantainers and
registered in this issue. Refer to GOVERNANCE.md for details
on how many votes are required to approve and when voting ends.

[lumjjb]

I think adding a referencable object with the actual contents as optional may lead to failure to resolve some of these details at consumption time (unable to get object). Although I see the value of using the reference, i worry about the reliability to rely on it solely as a pattern for common use. As of the current state of maturity of cross-referencing objects across standards and the adoption of json LD by these standards, i would be more comfortable if it was not optional to include the vulnerability identifiers within the struct.

i.e. the example here wouldn't be possible without the additional resolved information from the original format.

This may just be a rewording and a recommendation instead of a change in the struct definition

[SecurityCRob]

While not a voting member, I agree with and endorse this update. I think this helps set us up for success as we start to see openvex used more broadly.

[puerco]

@lumjjb so, do you think we should make name required? We can mark it in the spec. In its minimal form, the vulnerability field would be:

"vulnerability": {
   "name": "CVE-2019-17571"
}

[lumjjb]

yep - that works!. sorry for the late response, was out sick.

[wagoodman]

👍

[puerco]

@lumjjb 76ef832 adds language to specify name as required 👍

[puerco]

Proposal approved and enhancement document has merged 🎉 https://github.com/openvex/community/blob/main/enhancements/opev-0015.md