Hacker News Reader

I agree with this, finding vulnerabilities is really hard, and there's people coming out of college with no experience anywhere else in the field trying to get high paying jobs looking for vulns in technology they don't understand or have never worked with.

One of the best vulns I've ever remediated was one discovered by an application developer in their own authentication that was prescribed by our platform. He knew it was a problem and knew it needed to be fixed, but knew he needed us to report it before a fire got lit under the appropriate people's butts to make it get fixed.

> The author sounds like a very common type of software developer who takes security issues in their code like a personal attack.

She herself is a cyber security expert, so congratulations on attacking the messenger I guess?

Oh word? Because the only CVE I find when I google the author's name is this:

https://www.fastly.com/blog/cve-2023-30534-insecure-deserial...

An unexploitable PHP bug that five people decided to share the credit on.

I mean, of all the perverse metrics.

Bro, Way to prove her point!

>"Risk = probability * impact" doesn't work when you throw security into the mix.

In my experience, that's primarily because cybersecurity people know neither the probability nor the impact of the things which they are calling risks, which moreover means they don't know how to order them from a prioritization perspective.

As a cybersecurity person, probability is typically high since so many people release POCs and impact is almost always they steal all our IP and lock our computers, grinding business to a halt. CVSS is kind of helpful for triaging stuff, but if you are even a moderately sized org, it's literally fire drills all the time or you bury your head in the sand.

Business people typically don't wanna hear that and then act all shocked pikachu face when it happens.

This is kind of a narrow view of security.

Plenty of risks arent vulns in public software. Some are vulns in your own software. Some are just deviations from best practises or lack of system isolation.

Even among public vulns with known PoC, the impact is going to depend on context. Plenty of times the impact is zero based on how software is used.

It was a view in response to the above post, not a generalized view I take on things.

I’m actually a fan of embedding security resources into the eng teams and having those resources fix issues rather than toss shit over the wall. Knowing how software works is really hard without living inside the code base.

Ah, yes, this is the "start from the assumption that everything has failed" trick.

"if attackers can run arbitrary code on our systems then they can exploit vulnerabilities!" or "if attackers can send arbitrary payloads to services which are turned off in the actual image and in any case not accessible without breaching a perimeter firewall and passing through a DMZ then they can exploit vulnerabilities!"

OK, sure, what about "attackers kidnap the families of our AD admin team and force them to do whatever they want"?

Also, "high" meaning "sometimes we just don't care".

No, sorry, I do not care that (e.g.) CVE-2023-4911 has been categorized as "high", I am not in a rush to replace every single Fargate task that contains a vulnerable glibc because it's just not an interesting vulnerability in that context: let's assume you (a) bypass the payload validation on the (private!) API Gateway, (b) construct a payload that allows some kind of RCE in my JVM, (c) somehow escape from the JVM sandbox to run arbitrary native code, (d) successfully implement the attack, (e) get root in the underlying VM ... it's a Firecracker VM that doesn't have ANYTHING ELSE in it.

But, no, it's a "high", I better start cutting change tickets for literally everything in the universe to conduct an incredible load of busy work in order to do a no-op.

Really smart cybersecurity would be (I'm just making this up, I haven't really thought about it) "you know, if we're looking at services contained in a VM security boundary like Fargate, perhaps we don't care about Attack Vector = Local or Physical, or User Interaction = Required?" but what we actually get is "raw CVSS score tells you all you need to know and absolutely dictates urgency and triage priority".

> Ah, yes, this is the "start from the assumption that everything has failed" trick.

I am actually fairly data driven, and it's why things like SBOMs are exciting. Based on my experience, if something is exposed to the world and that thing has a vulnerability... within a period of reasonable time (say within 12 months), it will be exploited.

> No, sorry, I do not care that (e.g.) CVE-2023-4911 has been categorized as "high"

I wasn't actually referring to my "high" being the cvss scores. It was likelihood of exploitation(in my org), not the score. In your example, that would be a local exploit, so wouldn't be a high in my book unless you are shoveling user input to a CLI, which I would hope isn't happening.

Personally unless you know there to be higher risks for certain things, if it ain't 9+ on cvss, it gets a ticket cut to deal with it like any other but at some convenient time in the future.

> but what we actually get is "raw CVSS score tells you all you need to know and absolutely dictates urgency and triage priority"

Your security org sucks and are doing it wrong. I'm genuinely sorry, and I'll say that not all of us are like that :(

> cybersecurity is unique in the sense that you're dealing with intelligent adversaries

I disagree with this on the grounds that normal software engineering is dealing with intelligent adversaries as well. They may not be "adversarial" in the sense they are maliciously trying to _break_ the code, but if it is successful in performing _some_ work they will attempt to use it to perform other work as well, whether it was intended to or not.

But, what the author seems to be saying here is that a "vulnerability" is just a fancy word for a bug that is not inherently more significant than a crash or outage (where the vulnerability may not be available to exploit anyways). The suggest that cybersecurity teams may be more successful by integrating with the pipelines developers and SREs already have for dealing with issues (including critical ones) than interrupting their work and trying to assert how much more important cybersecurity is.