A person might be implementing dozens or hundreds of pieces of software from multiple vendors. Now there are CVEs on their radar. They have to deal, and assess.

What do they do?

Do a deep dive on every CVE, including looking at code, validating what the CVE represents, and assessing security risk org wide, no matter how and where and in what way the software is used? Is code even available?

Or, is the prudent thing to say "CVE -- we need the vendor to resolve".

How much work must an end user put in, when a CVE is there?

I agree 100% that this is terrible, but my point is to at least understand it from the side of implementation. What I tend to do is use my distro for everything I possibly can. This provides an entity that is handling CVEs, and even categorizing them:

https://security-tracker.debian.org/tracker/source-package/o...

This helps reduce the need to handle CVEs directly. Not eliminate of course, but vastly reduce it. Output of clicking on a CVE is helpful with a rating:

https://security-tracker.debian.org/tracker/CVE-2021-36368

This rating may be because it does not affect debian in its default config, or because something isn't compiled in, or the impact is truly low, or so on.

This gives me something to read if I must, and to grasp when I have no time to deep dive. I trust debian to be reasonably fast and work well to resolve CVEs of importance, and properly triage the rest.

Yes, I know of edge cases, yes I know of the fact that seldom used packages often need an end user to report a CVE. It can and does happen. But the goal here is "doing our very best" and "proving we'd doing that".

So this helps by allowing me to better focus on CVEs of vendor products I use, and get a better grasp on how to pursue vendors.

Yet when dealing with the infrastructure of smaller companies -- they just don't have the time. They still have to manage the same issues as a larger company, that being SoC2 compliance or what not, as well as liability issues in their market sphere.

And the thing is, I'm willing to bet larger companies are far worse at this CVE chicanery. It's just rote to them. Smaller companies have flexibility.

Here's a hotlist for making at least some of this manageable, because if you give people information, you don't have to respond as much:

* have a RSS feed, or a webpage which is only updated if there is a security update for your software

* have a stable and development(bleeding edge) branch. One branch only has security updates and never new code. Maybe, possibly bugfixes, but bugfixes must not break the API, config files, or create requirements for newer versions of libraries

* provide a mailing list never ever ever used for marketing purposes, which alerts users to new updates for software. never spam that email address. ever.

Important:

If you have outstanding CVEs, list them somewhere on a static page, with a description of what the issue is, and how you've triaged it. If you believe it's a bogus CVE, say so. If you think it only causes issues in certain circumstances, and is thus less important that other CVEs you are working on, say so.

Keep all CVEs here by simply updating the page to indicate a CVE was resolved, but also with a version/commit and date of when. Again, information resolves so many issues.

Do these things, and your end users will love you, and it will engender more trust that security issues are being dealt with seriously. (Note: not saying that aren't, but if you make it easy for people to know when updates come out, lots of questions stop being asked)

When engineers see this sort of thing, they love you. They become stronger advocates. It falls under marketing as much as technical due diligence.