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

161–170 of 249 posts

Re: Vulnerability reports are not special anymore

#161

Post by sam_lowry_ »

throwaway2037 wrote: post #150
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…

First, this is great reply with lots of real world experience to share. > I do think external dependencies are among our biggest security threats though. This sounds like a good business opportunity. I know that Sonatype has a business to vet Java dependencies. Does your company use it? I am guessing that Sonatype may be expanding into other open source ecosystems.

> First, this is great reply with lots of real world experience to share.

I know how they came about with this setup, but I think that's the wrong way of approaching the problem.

Their problem is legacy and trickle-in features in an otherwise unmaintainable code.

With AI, they can rewrite their software to minimize dependencies and in general reduce the attack surface by allowing the business to automate more on their own.

But it requires bold management decisions and people in position of authority that can pick the right battles for the advancement of their careers.

Re: Vulnerability reports are not special anymore

#162

Post by sam_lowry_ »

funciton wrote: post #129
jamesfinlayson wrote: post #51

Earlier quoted context omitted.

I tried to raise that with my internal security team recently - don't clutter my vulnerability dashboard with issues in dev dependencies. They somewhat rightly pointed out that malware needs to be dealt even if it's a dev dependency. So my suggestion went nowhere because I guess we can't filter by type of vulnerability.

Developer's machines and cicd systems are high value targets. They were absolutely right to point that out.

Only in the castle and moat security model popularized by Microsoft and the various "security" vendors that leech off it.

And the money wasted on the security theatre around this outdated concept is astonishing.

Re: Vulnerability reports are not special anymore

#163

Post by throwaway2037 »

inigyou wrote: post #53
lemagedurage wrote: post #50

Earlier quoted context omitted.

Have you considered requiring a small payment for vulnerability disclosure? Refund it on payout. This should be very effective at deterring spammers. It also sucks for real reports, but beats shutting down the program entirely.

Why would anyone pay money to have a chance of being arrested?

    > chance of being arrested
I am not involved with security research in any way. Can you explain the threat here?

Re: Vulnerability reports are not special anymore

#164

Post by esperent »

himata4113 wrote: post #154
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…

This is where you're wrong, I ran an experiment and told it to find bugs in a ~200 LoC project. The models are tuned in a way to where they're expected to generate issue reports so a codebase that had zero bugs, zero vulnerabilities and zero changes needed it found 3 low severity issues (cosmetic) 1 medium severity issue and 1 critical severity issue. The critical severity issue was accepting unvalidated user input,…

Did you make any attempt at tuning the prompt to reduce false positives? Or did you just say "find bugs"? Because if you tell it to do that, it will.

Re: Vulnerability reports are not special anymore

#165

Post by capitol_ »

froddd wrote: post #104
Gigachad wrote: post #90

Earlier quoted context omitted.

It's easier to keep stuff up to date these days. If you have a project with typescript, unit tests, and end to end tests like cypress you can just have dependabot create the PRs to update packages. If everything passes you just have to hit the merge button. Just updating everything is probably easier than assessing if it's possible to trigger an exploit with the way you use the package.

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.

Re: Vulnerability reports are not special anymore

#166

Post by anilakar »

Gigachad wrote: post #6
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…

I'm getting CVE fatigue with all of these super ultra critical 10/10 vulnerabilities that are some node package that compiles my frontend can get stuck if I give it a malicious regex. It's hard to spot the stuff that actually matters.

CVE 10.0 if you happen to use one specific functionality in the library. Non-CVE if you do not, and because it's an old bug, you cannot just downgrade to get a non-red result from Trivy.

Re: Vulnerability reports are not special anymore

#167

Post by jstimpfle »

cadamsdotcom wrote: post #160
jstimpfle wrote: post #147

Earlier quoted context omitted.

It might just mean the opposite. Unergonomic and/or slow memory safe languages might not be needed anymore at some point, because LLM can check for reasonable programming patterns and can do some amount of vulnerability checking upfront. But seriously the first point -- as long as you keep to a known set of reasonable patterns (much larger set than the sets accepted by restrictive and cumbersome type systems), memory…

> can reliably find some Some. In software & in security, 99% is a failing grade. So is 99.99%, so is 99.999%, and any other amount less than 100%. It’s not enough to point 5 LLMs at it and it’s not enough to point 500 LLMs at it. The field needs to seek deterministic & comprehensive solutions to whole problem classes.

It's not as black and white as you claim. 99% is obviously much better than 0%, and 99.999% would be an exceptional, unheard-of improvement. In most software projects, this would find ALL bugs.

And most "memory safe" languages are not all that memory safe. Or they need escape hooks.

EDIT: To be clear it's not AT ALL black and white. You have drunken too much of the type safety kool-aid.

Re: Vulnerability reports are not special anymore

#169

Post by mmsc »

gorgoiler wrote: post #85
jamesfinlayson wrote: post #54

Earlier quoted context omitted.

Yep. I remember years ago seeing the website for some guy who proudly listed all the CVEs he'd discovered. Clearly he'd written some scanning tool to look at regexes in open source projects and was creating CVEs for anything that might result in exponential time execution or whatever.

It sounds like an interesting case study. Do these things get reported with a patch?: (a) add a new function that does regular expressions searching / matching with a resource checker (eg a timer); (b) write a local linter that reports an error for any use of the builtin regular expression tools; (c) fix all the lint warnings; (d) commit the linter.

already exists: https://joshua.hu/comparing-redos-detection-tools. `recheck` and `redos-detector` are definitely the best. there's even an eslint plugin for the latter: https://github.com/tjenkinson/eslint-plugin-redos-detector
Post reply on HN