Replacing CVE | Hacker News Reader

Replacing CVE

gavinhoward.com

59 pointsgavinhoward61 comments

> First of all, a linear “score” like CVSS just cannot work in cybersecurity. Instead, we should have a system on the attributes of a vulnerability.

This is exactly what CVSS is: a scoring system based on attributes.

> In the first category, we might have attributes such as: Needs physical access to the machine, Needs to have software running on the same machine, even if in a VM, Needs to run in the same VM.

This is exactly what the AV vector in CVSS is.

> In the second category, we might have attributes such as: Arbitrary execution, Data corruption (loss of integrity), Data exfiltration (loss of confidentiality).

This is exactly what impact metrics in CVSS are.

I fear the author has a severe misunderstanding of what CVSS is and where the scores come from. There's even an entire CVSS adjustment section for how to modify a score based on your specific environment. I'd recommend playing around with the calculator a little to understand how the scores work better: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

And CVSS4 has added more metrics - including an AT (Attack Requirements) field:

> Are there any conditions necessary for an attack which the attacker cannot influence?

https://nvd.nist.gov/vuln-metrics/cvss/v4-calculator

As a pentester, who does not love CVSS[0], I found the article explaining how to replace CVSS with CVSS very amusing

[0] CVSS is often poorly understood and used by internal teams so for our internal engagements, we prefer words like "minor", "medium", "major", "critical" to describe criticity and impact and "easy", "medium", "hard" to describe exploitation difficulty (which loosely translates to likelihood), and the reasoning behind all this is very similar to what CVSS does

Have you ever stumbled across the PEF/REV method for classifying bugs?

https://www.fincher.org/tips/General/SoftwareDevelopment/Bug...

The essence of it is that "PEF" is from the user's point of view - pain, effort (work around), frequency. "REV" is from the developer's point of view- risk, effort (fix), verifiability.

Something that has a low PEF score and high REV score would not be practical to fix while something that is high PEF and low REV is something that should be prioritized high.

Less than 24 hrs into it, and now we have two problems from this defunding fiasco:

All the original problems that exist within CVE.

"Let's just reinvent the wheel!"

Yes, you have a dev background, which entitles you to an opinion, and you also have good intentions. This road is noble. However, the crux of this disaster is not technical, it's political. Maybe reinventing the wheel will be a huge success. Maybe it can wear the crown of free and open source for a while. But it's much more likely this fails as things become difficult to maintain, and you become tired, or poor, and are forced to stop, with nobody, or even worse, an enemy (this is an internationally critical database) controlling the database. So let's focus on solving the original funding disaster without jumping to forking and fracturing as a knee-jerk solution.

Okay, so what's your proposal (or any proposal) to fix this funding disaster? As a technical person I don't know how to affect the political process, and am thus disinclined to participate meaningfully. People with political ability and/or power have bigger problems to deal with right now, and also seem unable to affect the current political process. So what options do we have but to try our best, even if those ways are ultimately doomed?

>As a technical person I don't know how to affect the political process

Vote.

This is a vapid answer, like "write your senator". Of course I do, every chance I get. It doesn't seem to have meaningfully affected our political process.

It isn't. I'll expand on it. Tell your wife, your cousin, your bartender why you voted. Tell them how this CVE system is critical, and why they should care about voting for people that truly understand this. If you vote and influence others to vote, you're solving the problem fully and directly.

Voting is all but useless in deep-(any color) states though, that's the problem. I mean... yes, it's the decent thing to do, but in the end it's wasted effort in the American political system.

That's only true if you think "vote" means "vote once every 4 years, for the President".

Even if the only political action you ever do is informed voting, if you're voting in every election, knowing as much as you can about the candidates, then you have a real chance of starting to move the needle.

https://euvd.enisa.europa.eu/

This one is funded by the EU and accepts direct submissions. It’s probably the best replacement: state-backed, long-running, and reliable.

My understanding of CVE is superficial at best. I thought it was just an acronym publicly identifying vulnerabilities; I didn't realise there was a political structure behind it all.

While the article presents good food for thought, certification isn't a practical solution to the problem at hand. This database seems like a reasonable alternative.

It is “just” that, but: How are numbers assigned? How can others find details? Who determines when these details are public? (note: full CVE details can be used to exploit critical software) If they’re not always public, who gets to see them? And who handles that dissemination? Who takes care of duplicates?

Lots of work does go into this, even if it’s “just” an identifier.

Moving to more stable financial markets, away from the United States, would be a start.

I feel like requiring software "engineers" to be actual capital E Engineers would fix a lot of problems in our industry. You can't build even a small bridge without a PE, because what if a handful of people get hurt? But on the other hand your software that could cause harm to millions by leaking their private info, sure, whatever, some dork fresh out of college is good enough for that.

And in the current economic climate, even principled and diligent SEs might be knowingly putting out broken software because the bossman said the deadline is the end of the month, and if I object, he'll find someone who won't. But if SEs were PEs, they suddenly have standing, and indeed obligation, to push back on insecure software and practices.

While requiring SEs to be PEs would fix some problems, I'm sure it would also cause some new ones. But to me, a world where engineers have the teeth to push back against unreasonable or bad requirements sounds fairly utopian.

Oh gosh that was an interesting read. Became a fan of the author and his irreverence in reading this.

In the age of Rust, I wonder if CVE is even necessary anymore.

Reply on news.ycombinator.com