Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vulnerability reports are not special anymore

words.filippo.io

Post reply on HN
Print view View original

201–210 of 249 posts

Re: Vulnerability reports are not special anymore

#201

Post by pixl97 »

ActorNightly wrote: post #72
themanmaran wrote: post #2

I feel like it's also been overrun by a lot of spam. As someone running a company, I get 2-5 unsolicited "vulnerability reports" per week. Half of them are an LLM finding some bad CSS on our framer splash page. The other half I assume are an extortion attempt so we just mark as spam. Occasionally I see real security researchers on HN complaining that no one takes the disclosure seriously, or that people reply immedia…

Its been like that for half a decade across all software. People act like finding a linux kernel bug is a big deal, completely ignoring the fact that in order to exploit that bug, the attacker has to be able to run code on your computer in the first place, which is extremely hard to do these days remotely. Also people ironically just DGAF that much. The last actual bad exploit was log4shell in java, which given how i…

Ah yes, just move away from all apache libraries, should only take a day or two.

Re: Vulnerability reports are not special anymore

#202

Post by clates »

TeMPOraL wrote: post #192
Quothling wrote: post #79

Earlier quoted context omitted.

Working in the EU energy sector where we have to work with NIS2 compliance, I'd argue that your security team rightly pointed it out. I suspect that's what you mean though, and the rightly is just there because you agree with it but don't like it. We work with even more tight dependencies policies than just having alerts. We have a set of pre-approved and yearly vetted packages, like pandas or pyarrow for Python data…

> compliance basically comes down to "We trust the [third party] enough, and [third party component] is vital to our business, so we accept the risks" This is the beginning and end of reasonable security. This is what it's always about, and if you go beyond it, you risk practicing art for the sake of art, at the expense of customers and other stakeholders. Security is about understanding and managing risk. Not about…

I've almost always gotten everything I want from security teams over my career. Usually a quick and honest chat with them gets you pretty far. I always lead with some flavor of "In my perfect world, I have 100% access and ability to everything, everywhere all the time. In your perfect world, I don't even have a computer. Here's why I need X permission / Y user group / z application"

From the perspective of big corporate security - developers are a wild nuisance who file the lions share of the tickets and soak up an inordinate amount of resources. Being able to at least explain to them that you understand their objectives and are not overrequesting just for the sake of overrequesting goes a long way.

Re: Vulnerability reports are not special anymore

#203

Post by matthewdgreen »

themanmaran wrote: post #2

I feel like it's also been overrun by a lot of spam. As someone running a company, I get 2-5 unsolicited "vulnerability reports" per week. Half of them are an LLM finding some bad CSS on our framer splash page. The other half I assume are an extortion attempt so we just mark as spam. Occasionally I see real security researchers on HN complaining that no one takes the disclosure seriously, or that people reply immedia…

Vulnerability reports are a voluntary service to help a vendor or software project. It’s often an annoyance for the security researcher. I understand people are getting slammed and it sucks, but the main result of rejecting them is going to be an increase in full disclosure. As a note: if you have a bug (that isn’t devastating but you’d like to talk about) having an LLM write up the disclosure is a great way to check the “we disclosed responsibly and they didn’t care” box.

Re: Vulnerability reports are not special anymore

#204

Post by robertlagrant »

gautamsomani wrote: post #200
TeMPOraL wrote: post #192

Earlier quoted context omitted.

> compliance basically comes down to "We trust the [third party] enough, and [third party component] is vital to our business, so we accept the risks" This is the beginning and end of reasonable security. This is what it's always about, and if you go beyond it, you risk practicing art for the sake of art, at the expense of customers and other stakeholders. Security is about understanding and managing risk. Not about…

Asking out of curiousity - how would you or how does your org handles this right now?

I'm not the previous poster, but in my experience you can get a lot of mileage out of having dev teams (tediously, at least the first time) go through all potential vulnerabilities, decide how risky each one is based on likelihood and impact, and then get them to address the high/highs somehow (e.g. by upgrading a dependency, or writing extra code to guard against the issue, or fixing the issue if it's a home-grown vulnerability).

Re: Vulnerability reports are not special anymore

#205

Post by clates »

capitol_ wrote: post #165
froddd wrote: post #104

Earlier quoted context omitted.

This is exactly how developers of malware want you to behave. Update without really thinking about it. I do wonder how long it will take before an attack is developed by submitting a semi-genuine vulnerability, shortly followed by a ‘fix’ including malicious code.

The cooldown setting in dependabot solves this attack vector. By setting it you give security vendors time to scan new packages.

Notably this does nothing to "solve" the attack vector. You've got a live bomb in front of you and you're adding 10s to the countdown hoping that _others_* find it and defuse it in that time period.

I would challenge anyone proposing this to define more than one party doing security checks on packages to prove the point that many projects are waving their hands nebulously around saying "security vendors" and then YOLO'ing code into their codebase because they didn't here the muses wailing.

Alternatively from the other direction - Point to any dependency in your project. How can you get *POSITIVE SIGNAL* that security vendors _did_ look at it and okay it? How much scrutiny did they put into it? At what version did they last inspect it?

Re: Vulnerability reports are not special anymore

#206

Post by bluGill »

capitol_ wrote: post #165
froddd wrote: post #104

Earlier quoted context omitted.

This is exactly how developers of malware want you to behave. Update without really thinking about it. I do wonder how long it will take before an attack is developed by submitting a semi-genuine vulnerability, shortly followed by a ‘fix’ including malicious code.

The cooldown setting in dependabot solves this attack vector. By setting it you give security vendors time to scan new packages.

Only if their scanning detects it though. Malware authors have incentive to figure out how to fool the tool. They don't even need to be right all the time, any attack that survives works for them, and creating accounts is easy.

Re: Vulnerability reports are not special anymore

#207

Post by AmbroseBierce »

>I honestly have no idea how the profession will look after that, so this whole post is more of a current observation than a long-term prediction.

My sweet summer child, the "profession" will become an agent managers talk directly to, like many other professions.

Re: Vulnerability reports are not special anymore

#208

Post by FiloSottile »

matthewdgreen wrote: post #203
themanmaran wrote: post #2

I feel like it's also been overrun by a lot of spam. As someone running a company, I get 2-5 unsolicited "vulnerability reports" per week. Half of them are an LLM finding some bad CSS on our framer splash page. The other half I assume are an extortion attempt so we just mark as spam. Occasionally I see real security researchers on HN complaining that no one takes the disclosure seriously, or that people reply immedia…

Vulnerability reports are a voluntary service to help a vendor or software project. It’s often an annoyance for the security researcher. I understand people are getting slammed and it sucks, but the main result of rejecting them is going to be an increase in full disclosure. As a note: if you have a bug (that isn’t devastating but you’d like to talk about) having an LLM write up the disclosure is a great way to check…

> I understand people are getting slammed and it sucks, but the main result of rejecting them is going to be an increase in full disclosure.

Right, what I'm saying is that letting those bugs go to full disclosure (aka being filed as public issues, like every other bug) would have been a significant damage to user safety a year ago, and it's not anymore.

Re: Vulnerability reports are not special anymore

#209

Post by cpburns2009 »

tempay wrote: post #80
zmgsabst wrote: post #67

Earlier quoted context omitted.

Dev dependencies is how they compromised SolarWinds and thereby most of the US federal government. > The attackers used a supply chain attack. The attackers accessed the build system belonging to the software company SolarWinds, possibly via SolarWinds's Microsoft Office 365 account, which had also been compromised at some point. SolarWinds was using build management and continuous integration server TeamCity provide…

This is very real, but such CVEs are such a tiny fraction in relation to denial-of-service-due-to-regex that it’s hard to take the system seriously. So far as I’m concerned the solution is to isolate everything as much as possible. I’d love to see something on the CVE classification side to also address the signal to noise problem but I don’t see it happening.

So I have a library and its ultimate purpose is converting globs to regexes. Someone sent me a ReDoS vulnerability report with a 4.0 CVSS score because if you write an obscene glob pattern you'll get a correspondingly obscene (and inefficient) regex. What else would you have it do!?

Re: Vulnerability reports are not special anymore

#210

Post by bluGill »

bostik wrote: post #111
socalgal2 wrote: post #34

I feel like the current situation is temporary. LLMs are finding all the bugs. LLMs are also help fixing most of the bugs. Once most of the bugs are fixed, LLMs should be good at finding bugs before shipping them, the stream of bug reports will die down, and we'll be back to vulnerabiltiy reports being special. Further, the fact that bugs are so easy to find by LLMs means there is strong incentives to find ways to mi…

"Temporary" can be an awfully long time. There is ample evidence that discovery rate of bugs (many of which can be bucketed into vulnerabilities) in any non-trivial piece of software is more or less stable.[0] In a recent podcast episode the ex-CISO of Adobe commented that every now and then they'd take a sustained squeeze to find all occurrences of a given type of bug (ie. source of vulnerability) in a codebase. The…

The hope is that LLMs can scan my code every day or something like that. If I make a mistake and get it past code review, the LLM will still find it and it gets fixed right away. (better yet, make LLM an automatic reviewer on everything).

Many of the bugs we are finding in projects like curl are 20 years old - once they are fixed they are fixed and so hopefully we get all those 1-20 year old problems fixed and future scans only find new problems which is itself a big improvement in the rate. I agree that we will never reach a point where there are no bugs introduced, but we should strive to fix them faster.

Post reply on HN