Skip to content
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

Remove all "supportingMedia" sections from the JSON #363

Open
jayjacobs opened this issue Nov 21, 2024 · 3 comments
Open

Remove all "supportingMedia" sections from the JSON #363

jayjacobs opened this issue Nov 21, 2024 · 3 comments
Labels
enhancement New feature or request Needs Discussion Discuss in a future QWG meeting or on mailing list section:other Schema location is other than those specifically defined

Comments

@jayjacobs
Copy link
Collaborator

jayjacobs commented Nov 21, 2024

I was pulling some data to provide data-support around issue #200. I found that not only is supportingMedia not used much at all, but when it is used, it is misused and generally just adds noise and parsing effort.

At the time I opened this, there are 256,421 CVEs in a published state, a grand total of 18,123 CVEs have used any of the supportingMedia fields, which is 7% of all published CVEs. Across the 18,123 CVEs, there are 26,046 references to supportMedia with a value and this is the count of unique CVEs with each field:

  field                                                cves
1 containers.cna.descriptions.supportingMedia.value   18099
2 containers.cna.solutions.supportingMedia.value       6641
3 containers.cna.workarounds.supportingMedia.value      728
4 containers.cna.exploits.supportingMedia.value         332
5 containers.cna.configurations.supportingMedia.value   246

Digging into it a bit further, the type of supportingMedia is always "text/html" with 26,117 fields specifying that value. If you notice the counts, there are 71 more definitions of the supportingMedia.type than defined values.

Zero records had base64 values.

There is also a "base64" field to accompany the supportingMedia section with 26,117 records setting a boolean value and 162 records are set to TRUE, 146 are on the "containers.cna.descriptions.supportingMedia" section. Manual inspection of all 146 showed zero with base64 encoded values. This supports closing #200 as a non-issue in practice.

Zero CVEs used supportingMedia to share supporting media.

For those that have text/html types defined (all of them), I focused on the supportingMedia for the description. I noticed that many of them looked to just repeat the text in the main description field. It was a little difficult to check since I was comparing html to plain text, all but a small handful matched the description once I converted from html to plain text, manual inspection of the rest showed any divergence was minor and in only three cases (CVE-2024-6442, CVE-2024-6443, CVE-2024-6444) was the text completely different, but the "supporting media" was just a summary. In other words, ZERO CVEs used the supportingMedia field for supporting media

I did not look at the other supportingMedia fields, I can if people think it would be helpful.

@jayjacobs jayjacobs added enhancement New feature or request section:other Schema location is other than those specifically defined Needs Discussion Discuss in a future QWG meeting or on mailing list labels Nov 22, 2024
@boblord
Copy link

boblord commented Nov 22, 2024

Looks like a candidate for removal from the schema.

@MrMegaZone
Copy link
Collaborator

I'm on board with deprecating supportingMedia with an eye toward future deletion.

@prabhu
Copy link

prabhu commented Dec 20, 2024

My vulnerability-db project uses supportingMedia in a few places. But happy to rewrite in a future iteration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Needs Discussion Discuss in a future QWG meeting or on mailing list section:other Schema location is other than those specifically defined
Projects
None yet
Development

No branches or pull requests

4 participants