Scaling/domain knowledge

Posted Dec 6, 2023 6:22 UTC (Wed) by nickodell (subscriber, #125165)
Parent article: Supplementing CVEs with !CVEs

Seems tricky to scale. The current system may have a conflict of interest, but it does at least distribute vulnerability reports among the CNAs, and ensures that the CNAs evaluating their own software for security bugs are domain experts. I think that for a lot of software, it might be hard to tell if a bug is a security issue, without an understanding of what the security model of the software is.

to post comments

Scaling/domain knowledge

Posted Dec 6, 2023 7:40 UTC (Wed) by epa (subscriber, #39769) [Link] (7 responses)

Perhaps they would do better to declare that a NotCVE simply represents a “bug”. Thus avoiding the whole circus about what counts as a vulnerability, the expected uses of the software, where the trust boundary lies and so on.

Calling something a “bug” is also open to debate—the developer may argue that a segmentation fault on invalid input is not a bug because by design the program is meant to work only on valid input—but without the additional politics brought in by the word “vulnerability” it may be easier to resolve.

Scaling/domain knowledge

Posted Dec 6, 2023 8:21 UTC (Wed) by roc (subscriber, #30627) [Link] (2 responses)

Often we do have information about whether a bug has security implications or not, and it seems rude to conceal that information.

Scaling/domain knowledge

Posted Dec 6, 2023 10:14 UTC (Wed) by taladar (subscriber, #68407) [Link]

Perhaps what is really needed is some sort of moderated location to discuss each potential bug and security implications so the disagreements become visible?

Scaling/domain knowledge

Posted Dec 6, 2023 17:39 UTC (Wed) by epa (subscriber, #39769) [Link]

Oh, I didn’t argue to deliberately conceal anything, but to say that any bug can be given a NotCVE without having to argue about whether, officially speaking, it counts as a “vulnerability”. Just to shortcut the sterile discussions about “well I know you have a working exploit, but this shouldn’t be considered a security vulnerability because…”

Scaling/domain knowledge

Posted Dec 6, 2023 12:02 UTC (Wed) by pm215 (subscriber, #98099) [Link] (3 responses)

The problem I think with that is that the whole point of the CVE circus is trying to distinguish "unexciting bugs" from "you will have a really bad day if you don't apply a fix for this" bugs. If every bug got a NotCVE or a BUG identifier or whatever, it would not really be very helpful, because it wouldn't let you track "do we (or our downstream users) have any Really Bad Days in our future if we don't do something?".

Scaling/domain knowledge

Posted Dec 6, 2023 12:14 UTC (Wed) by Wol (subscriber, #4433) [Link]

The other big problem is that you get too many people gaming the CVE system, and flagging bugs that are disabled by default as "you really need to fix this", etc etc.

If the payoff of making an ass of yourself is high, then people are going to do it ... :-( It's exactly the same as the spam problem. Filing a brainless CVE is easy, the cost of dealing with the mess falls on someone else.

Unfortunately the only real way to implement anti-CVE-spam is just to delete all CVEs on sight - at which point the regulators get upset :-(

Cheers,
Wol

Scaling/domain knowledge

Posted Dec 6, 2023 17:41 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

That’s part of the reason. But the other is just to tie together information about a bug with a single easily greppable identifier. A given NotCVE might not be a bug you care about. But if you’ve decided you do care, you have a formal mechanism for labeling fixes, checking whether a fix has been merged into a given branch, listing installed packages that may be unpatched and so on.

Scaling/domain knowledge

Posted Dec 7, 2023 4:31 UTC (Thu) by buck (subscriber, #55985) [Link]

Yeah, I thought that "common vulnerability enumeration" was meant to convey that a CVE is like a serial number authority (confederated, now, I guess) for vulnerabilities.

And, just as most of us never have a need to ever consult the serial number of our refrigerators or whatever, especially not if it's a dorm-room model that's here today and out on the curb tomorrow, but you might want to be able to call in for service if you have an expensive custom fridge with the wood panels that blend into your cabinetry, there are going to turn out to be some numbers that people care about and some that nobody does.

But, if they do, it's nice for somebody to have handed out a unique identifier for them (if nobody is willing to foot the registration fee for a brand name vulnerability PR web site etc., I say, tongue in cheek, because usually the research that's gone into those vulnerabilities is a lot more mind-bending than my brain can take without breaking, and having to register a .vuln domain might be a nice barrier to entry for nuisance reporting [grin]).

Assuming the people overseeing registration are good enough taxonomists to figure out just exactly how to separate one bug from another