4 ms·
TBH this is a pretty good way of looking at it. Yeah we're seeing an explosion of vulnerabilities being found right now, but that (hopefully) means those vulner
by xingped 5mo ago
TBH this is a pretty good way of looking at it. Yeah we're seeing an explosion of vulnerabilities being found right now, but that (hopefully) means those vulnerabilities are all being cleaned up and we're entering a more hardened era of software. Minus the software packages that are being intentionally put out as exploits, of course. Maybe some might say it's too optimistic and naive, but I think you have a good point.
- anankaie 5mo agoTo be fair, to some extent that’s up to us. Time to get cleaning, I guess.
- FrinkleFrankle 5mo agoNew code will also use these tools from the get go, hopefully vastly reducing the vulnerabilities that make it to prod to begin with.
- gred 5mo agoThe future may be distributed quite unevenly here, as they say, with a divergence between a small amount of "responsible" code in systems which leverage AI defensively, and a larger amount of vibe-coded / prompt-engineered code in systems which don't go through the extra trouble, and in fact create additional risk by cutting corners on human review. I personally know a lot of people using AI to create software faster, but none of them have created special security harnesses a la Mozilla (https://arstechnica.com/information-technology/2026/05/mozilla-says-271-vulnerabilities-found-by-mythos-have-almost-no-false-positives/ https://arstechnica.com/information-technology/2026/05/mozil...).
- akoboldfrying 5mo ago> we're entering a more hardened era of software This is one force that operates. Another is that, in an effort to avoid depending on such a big attack surface, people are increasingly rolling their own code (with or without AI help) where they might previously have turned to an open source library. I think the effect will generally be an increase in vulnerabilities, since the hand-rolled code hasn't had the same amount of time soaking in the real world as the equivalent OS library; there's no reason to assume the average author would magically create fewer bugs than the original OS library authors initially did. But the vulnerabilities will have much narrower scope: If you successfully exploit an OS library, you can hack a large fraction of all the code that uses it, while if you successfully exploit FooCorp's hand-rolled implementation, you can only hack FooCorp. This changes the economic incentive of funding vulnerabilities to exploit -- though less now than in the past, when you couldn't just point an LLM at your target and tell it "plz hack".
- cratermoon 5mo agoTypically when hand-rolling code you implement only what you require for your use-case, while a library will be more general purpose. As a consequence of doing more, have more code and more bugs. Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. For supply chain security and bug count, I'll take a focused custom implementation of specific features over a library full of generalized functionality.
- akoboldfrying 5mo agoYes, a lot hinges on how little you can get away with implementing for your use case. If you have an XML config file with 3 settings in it, you probably won't need to implement handling of external entities the way a full XML parsing library would, which will close off an entire class of attendant vulnerabilities. > Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. This isn't really an argument in favour of having the average programmer reimplement stuff, though. For it to be, you'd have to argue that the leftpad author was unusually sloppy. That may be true in this specific case, but in general, I'm not persuaded that the average OSS author is worse than the average programmer overall. IMHO, contributing your work to an OSS ecosystem is already a mild signal of competence. On the wider topic of reimplementation: Recently there was an article here about how the latest Ubuntu includes a bunch of coreutils binaries that have been rewritten in Rust. It turns out that, while this presumably reduced the number of memory corruption bugs (there was still one, somehow; I didn't dig into it), it introduced a bunch of new vulnerabilities, mostly caused by creating race conditions between checking a filesystem path and using the path for something.
- spockz 5mo agoThis argument goes even further. If you have only 3 settings, why does it need to be an xml file?
- akoboldfrying 5mo ago
- michaelchisari 5mo agoI agree with the prediction but not the timing. We won't enter a more hardened era of software until after a long period of security vulnerabilities. Rivers caught on fire for a hundred years before the EPA was formed.
- larodi 5mo agoYou are avoiding intentionally to say ‘thanks to LLMs’ or is implicit? As all these recent mega bugs surface with lots of fuzzing and agentic bashing, right ?
- jangxx 5mo agoThank you for reminding us all that you AI bros are still the most obnoxious people there are.
- larodi 5mo agoIndeed, yet another proof, there's the part of HN crowd which is passive aggressive, dismissive, and dishonest in the very scientific possible sense. Won't make my day harder than it is, but is a very weak signal. If I'm to be offended by a single thing in your post that is calling me (names) - is AI Bro. This was undeserved, and cannot be farther from the truth. Not to miss the fact your comment is entirely off topic, and perhaps you see AI bros everywhere now.
- 12_throw_away 5mo agoThis seems like a very emotional response, which is off-topic for HN. Consider using facts and logic to make calm, rational arguments.
- larodi 5mo agoWhat facts did parent use? What facts did u use? Which particular emotion do you imply in you response?