-
-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add attribute to VDR/VEX to allow modification of severity #332
Comments
Vulnerability spec: https://cyclonedx.org/docs/1.5/json/#vulnerabilities
The
Considering this, @hoggmania, is your request solved?
see also |
Here's an example of what modified severity looks like. Docs: https://cyclonedx.org/docs/1.5/json/#vulnerabilities_items_ratings Its a common use case that CycloneDX has supported for several releases. What we don't want, is multiple ways to accomplish modified severity. @hoggmania please let us know if there's anything in the existing implementation that's missing. |
Feeling very sorry for wasting people's time when I missed this.....should have tried a bit more RTFM. Much appreciated! |
@jkowalleck I sort of get the logic and it sort of works with the CycloneDX VEX :-) And maybe its just me... but I expect the CycloneDX doc with the vuln info to be generated by a vuln scanner tool/vendor where it would be immutable in some cases (e.g., could be stored in a 3rd party container registry) and the severity rating change would be done by a consumer in a separate doc. Sounds like you are saying that the consumer would need to duplicate that CycloneDX doc and add their severity as as record, right? |
@kcq You could use the external reference type |
The classification of a vulnerability in NVD can be somewhat divisive & debatable.
Maintainers may wish to alter the severity or an aspect of the vector. Cunsuming organisations may wish to manage a vulnerability and alter the vector/severity.
Adding attributes to a VEX that allow the vector to be altered or severity changed would allow significant reuse in the SCA field and indeed allow SCA providers to integrate in a standard way ino such systems as OWASP Dependency Track.
OpenVEX is also debating such use cases at openvex/spec#31
The text was updated successfully, but these errors were encountered: