Are these real CVEs? VulDB entries for dnsmasq rely on replacing config files

> Basically CVEs are often weaponized in a really counterproductive way.

This is inevitable when you boil everything down to a number. When that number refers to a (potentially) costly bug, people shirk critical thinking and just go straight for zero-tolerance.

Not ideal but I'm not sure if there's a better way :/

> How do CVEs get issued? Where do I apply, who makes decisions

For most (but certainly not all) projects, you fill out a simple form [0]. I've done it before and it's fairly easy.

> and what software is covered by them?

All software is covered by someone, usually by the vendor themselves or MITRE.

> Can a CVE be issued in retrospect?

Absolutely, but it's fairly uncommon.

[0]: https://cveform.mitre.org/

CVE-2025-1312 bash and sudo privilege escalation

sudo may be exploited to obtain full root privilege when the shell receives attacker-controlled input

to reproduce: execute this shell script and authorize sudo when prompted

The Black Duck scanner in particular I've found is really easy to misconfigure to siphon up all sorts of crazy shit. Did some coworker write a one-off support script that uses an ancient container in some random repository? Oops now you've got to answer to why you've got a dozen Debian or Alpine vulns in a product that ships on bare metal RHEL. If your build process is not 100% lunar lander clean, which in the era of ship trash as fast as possible, it's not going to be, you inevitably end up with an absolute deluge of things flagged that you have no idea where they came from or how to explain to some suit that no we're not shipping Debian Jessie in 2025, calm down.

I think what's happening here is, people don't have time to assess. And frankly, can you blame them?

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.