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

Significant raise of reports

lwn.net

Post reply on HN
Print view View original

151–160 of 164 posts

Re: Significant raise of reports

#151

Post by epolanski »

sigbottle wrote: post #113

I'm actually curious about AI progress: There's no way the AI is a priori understanding codebases with millions of LoC now. We've tried that already, it failed. What it is doing now is setting up its own extremely powerful test harnesses and getting the information and testing it efficiently. Sure, its semantic search is already strong, but the real lesson that we've learned from 2025 is that tooling is way more powe…

The fact that it's millions of LoC is borderline irrelevant in that context, you don't need to have it all in context to find bugs in a handful of files.

Re: Significant raise of reports

#152

Post by keeganpoppen »

chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

but this simply isn't true. everyone thinks "oh well my use cases will never hit any of those bugs", but then there is one person in your org who hits that particular bug and it drives them batty. it is a retro-justification for doing things the wrong way "For the Right Reason". like... no one would be like "NEVER change the oil in your car unless the light goes off". we're not talking about Micro$oft here, where you literally have to pray to your deity of choice every time you click the update button. we are talking about the Linux kernel. i do not even need a thumb to count on one hand the amount of times a kernel update has significantly impacted my life. whereas probably 50% of my Windows updates break at least one of my peripherals, and OS X isn't exactly much better these days.

Re: Significant raise of reports

#153

Post by keeganpoppen »

Muromec wrote: post #143
chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

>it takes effort to familiarize yourself with new features, decide what should be enabled and what should be disabled, etc. What features? I update my rolling release once a month and nothing changes for the last 10 ish years. Maybe pipewire/pulse thingy was annoying and bluetooth acted a bit. With docker on rpi I even upgrade the whole zoo of things by just rebooting.

exactly. it is something you genuinely never need to think about, except for once in a blue moon. or, more like once in a leap year. and completely unmeasured by the "we will update it when our [horrific] business processes say it's okay" crowd is the cumulative angst of shit being broken FOR NO REASON. and that is to say nothing of the security vulnerabilities and all the other reasons that exist for updating your software.

Re: Significant raise of reports

#154

Post by TacticalCoder »

jcalvinowens wrote: post #150

> I suspect that bugs are reported faster than they are written, so we could in fact be purging a long backlog (and I hope so). It's hard for me to imagine how this wouldn't be true. This isn't the "new normal", everyone is just running it into the ground and wringing every drop they can out of it right now. It would be interesting to "backtest" how much higher the rate of vulnerability discovery would have been if a…

> I suspect it's not very significant: we're flushing a 20+ year backlog, and generally the rate at which vulnerabilities are created is lower today.

The thing is: if these new AI tools can find a backlog of old bugs, these tools can very obviously be used on code that hasn't been pushed yet. And they'll find potential bugs there too. And so the rate at which new vulns are created is soon going to be even much, much, much lower.

Now of course I'm talking about serious projects like the Linux kernel in TFA: real stuff that powers the real-world. If we're talking about OpenClaw who decided to launch a startup based on a "Write me a clone of MySpace but with a Web design from the 2020s" prompt, then all bets are off.

The nice thing with using AI tools to find bugs is that there's not much ambiguity: a bug, if proven to be a bug, has to be squashed. It doesn't matter how it was found: even the AI doubters can accept there's a bug and that something has to be done about it.

Using AI tools to fix bugs in the Linux kernel is IMO much more impressive than "Write me the 10 000th MySpace clone but using a Web design from the 2020s".

Re: Significant raise of reports

#155

Post by derefr »

radlad wrote: post #116
mentalgear wrote: post #105

Earlier quoted context omitted.

There's an anecdote I remember reading somewhere: When an 'embedded systems' engineer was to present a web-based product they were tasked to build, the managers/reviewers were puzzled they couldn't find any bugs. Asked about this, the engineer replied: "I didn't know that was an option". Definitely a different mindset/toolset is required when it comes to building systems that have to be working autonomously without "…

Yes but I would push back a little on the idea that you simply put yourself in a "mindset of writing bug-free code." Simpler code has fewer bugs. Embedded code tends to be simpler and more targeted in its role. Of course, putting yourself in the mindset of writing simpler code is great too - if you have the time to do so, and the problem you are solving is itself sufficiently simple.

The embedded engineering mindset is not a mindset of "writing bug-free code"; it's a mindset of treating the first ~20% of the time budget you're given for the project as time spent designing and writing code (and constraining scope appropriately); and then treating the rest of your time budget as time spent coming up with every possible way to validate/static-analyze/fuzz/etc your code you can, and then debugging all the resulting failures. (Which also implies structuring your code so that it remains at all times extremely testable, whether you are writing tests just then or not.)

Re: Significant raise of reports

#156

Post by IshKebab »

tptacek wrote: post #142
IshKebab wrote: post #138

Earlier quoted context omitted.

1. That's bollocks. Obvious bullshit. All software doesn't have the same security track record. Do you also think sendmail and seL4 have an equally poor security track record? 2. Even if everything did have an equally poor security track record, why would that mean security bugs are no more significant than any other bug? Honestly I'm dubious you've thought about this at all.

I didn't say "all software has the same security track record". seL4 has a much better track record than Sendmail by dint of not doing very much. I'm pretty comfortable with what people do and don't think about how much thinking I've done on this topic. Done much work with L4?

Then your point makes even less sense. Everything has security vulnerabilities therefore they are no different to other bug classes? What?

Re: Significant raise of reports

#157

Post by functional_dev »

motbus3 wrote: post #134

The slapocalipse is here, but I would propose the idea that open source maintainer get free access to AI tools from these big companies, so at least they can aggregate the problems and have some level of automation of the process. For me, this seems something that would make sense for all dev community to push for.

agreed, attackers can use these AI tools to scan open source code and find bugs very fast... if project maintainers do not have access to such tools, it because an ufair fight

Re: Significant raise of reports

#158

Post by throawayonthe »

JumpCrisscross wrote: post #23
Shank wrote: post #7

Important to note that this is a comment on this article: https://lwn.net/Articles/1065586/ .

“Reversing was already mostly a speed-bump even for entry-level teams, who lift binaries into IR or decompile them all the way back to source. Agents can do this too, but they can also reason directly from assembly. If you want a problem better suited to LLMs than bug hunting, program translation is a good place to start.” Huh. Direct debugging, in assembly. At that point, why not jump down to machine code?

i think they aren't saying "it's more effective to debug at assembly level" but just that LLMs might be less dependent on decompilation/RE that tries to recreate high level code (the context is specifically about closed-source programs)

Re: Significant raise of reports

#159

Post by tancop »

SoftTalker wrote: post #71
jakevoytko wrote: post #45

Earlier quoted context omitted.

There are some rose-colored glasses when people say this. Programs didn’t auto save and regularly crashed. It was extremely common to hear someone talk about losing hours of work. Computers regularly blue screened at random. Device drivers weren’t isolated from the kernel so you could easily buy a dongle or something that single-handedly destabilized your system. Viruses regularly brought the white-collar economy to…

> Viruses regularly brought the white-collar economy to its knees. Now, it's anti-virus (Crowdstrike) that does that. I don't think many or any virus or ransomware has ever had as big an impact at one time as Crowdstrike did. Maybe the ILOVEYOU worm.

crowdstrike is not your average antivirus like malwarebytes or avast. the whole point is you can remote control everything with custom rules and enforce a security policy by locking the device until someone updates it. that update system is the main reason the bug was so dangerous. its built for corporate places who care about compliance more than actual security.

Re: Significant raise of reports

#160

Post by motbus3 »

functional_dev wrote: post #157
motbus3 wrote: post #134

The slapocalipse is here, but I would propose the idea that open source maintainer get free access to AI tools from these big companies, so at least they can aggregate the problems and have some level of automation of the process. For me, this seems something that would make sense for all dev community to push for.

agreed, attackers can use these AI tools to scan open source code and find bugs very fast... if project maintainers do not have access to such tools, it because an ufair fight

Exactly. The rate of acceptance right now is low. Maybe less than 10% and most will not be relevant. Also, if they can use it to categorise, validate and test it why not? If they have 100 new bugs, but all useless ones already checked and close life would be almost normal again.

Using llm for things that require knowledge is sketchy and unreliable, but having fixed pipeline checks that runs few hooks, maybe some automated scripts, add context, link bugs, create clear versions of the conversation... That's ok!

We see many companies stumbling on the llm problems when the code get to big or too messy, and that will be it, imho. But using those tools as small quick gains is here to stay.

Post reply on HN