That probably don’t make sense to a lot of people, and I need to think about it more
But here’s the basics of it
The CVE data is so comically bad, nobody actually doing #vulnerability work can use it. The ID is all we use. We have to look in other databases and collect or own facts
Automated tools rely on sources like #GitHub, #GitLab, and #OSV. Other than the ID, CVE doesn’t really matter anymore
@joshbressers I have a CVE from like 2 years ago that I was supposed to get the description and stuff updated and never did. Mostly because I don't know how to go about doing that, But unsurprisingly no one has complained so I keep forgetting about it.
@lgehr@joshbressers I'm sure I didn't do it because, like I said, I don't know who to contact to update the CVE.
That said it was probably updated by the person that requested the CVE as that wasn't me. They just requested it on my behalf and then gave me the number.
In the past when I've requested them I had reached out to @joshbressers and @kurtseifried to get them and we did all the documentation and stuff then.
@joshbressers This is extremely close to the original CVE idea - the ID was unique, and the (supposed to be only) one sentence gave enough info to allow you to differentiate - not provide details. Also note it was never designed for instant detail, just reasonably close to the date of public disclosure. AND it was originally conceived last century during a different time. So it sounds like it is definitely working as designed. The ID is the point, the rest if it exists in description or references is gravy.
@simplenomad I don’t think I would say it’s working as designed. It’s a negative for my productivity quite often because the data is almost always wrong or incomplete, and it can’t be updated
If it was simply pointers to somewhere competent, that would be lovely
@joshbressers Currently I rely upon the ID itself as the pointer. The only reference I used to use was the “Confirmed” link which was typically pointing to the vendor - I do miss that.
Add comment