6 ms·

So, to play Pandora, what if the net effect of uncovering all these unknown attack vectors is it actually empties the holsters of every national intelligence se

by tclancy 6mo ago

So, to play Pandora, what if the net effect of uncovering all these unknown attack vectors is it actually empties the holsters of every national intelligence service around the world? Just an idea I have been playing with. Say it basically cleans up everything and everyone looking for exploits has to start from scratch except “scratch” is now a place where any useful piece of software has been fuzz tested, property tested and formally verified. Assuming we survive the gap period where every country chucks what they still have at their worst enemies, I mean. I suppose we can always hit each other with animal bones.

xingped 6mo 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 6mo ago
  To be fair, to some extent that’s up to us. Time to get cleaning, I guess.
- FrinkleFrankle 6mo ago
  New 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 ago
    The 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 6mo 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 6mo ago
    Typically 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 6mo ago
      Yes, 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.
- michaelchisari 6mo ago
  I 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 6mo ago
  You 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 6mo ago
    Thank you for reminding us all that you AI bros are still the most obnoxious people there are.
    - larodi 5mo ago
      Indeed, 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 ago
        This seems like a very emotional response, which is off-topic for HN. Consider using facts and logic to make calm, rational arguments.
        larodi 5mo ago
        What facts did parent use? What facts did u use? Which particular emotion do you imply in you response?
marcus_holmes 6mo ago
This assumes that there are no new exploits being generated. We're seeing maintainers retreat from maintaining because the amount of AI slop being pushed at them is too much. How many are just going to hand over the maintenance burden to someone else, and how many of those new maintainers are going to be evil? The essential problem is that our entire system of developing civilisation-critical software depends on the goodwill of a limited set of people to work for free and publish their work for everyone else to use. This was never sustainable, or even sensible, but because it was easy we based everything on it. We need to solve the underlying problem: how to sustainably develop and maintain the software we need. A large part of this is going to have to be: companies that use software to generate profits paying part of those profits towards the development and maintenance of that software. It just can't work any other way. How we do this is an open question that I have no answers for.
- teiferer 6mo ago
  That is already how it works. The loner hacker in moms basement working for free on his super critical OSS package is largely a myth. The vast majority of OSS code is contributed by companies paying their employees to work on it.
  - larodi 6mo ago
    The sad truth about open source in 2026 is that it does not serve the society the way it is advertised or did back in the 90s.
    - spockz 6mo ago
      How so? We have open source operating systems running on a whole sleuth of systems ages apart. Interesting ideas and open collaboration coming out of the OS world. This opposed to closed off “products” that change at the whims of the company owning it.
      - larodi 5mo ago
        Statistically. Most of it is created to serve marketing, personal or other agenda needs and is sponsored through the corresponding means for it. There’s a lot of misconception about how the open source comes to be and very small part, still significant of course, of it was really created for the benefit of a community. There are exceptions, but dig the organisational culture and origins and you’ll see the pattern. Also, thousands of projects are made for the satisfaction of the author himself being highly intelligent and high on algorithmic dopamine.
Barbing 6mo ago
Will need those animal bones if all the industrial control systems get turned against us Nuclear might be airgapped but what about water, power…?
allthetime 6mo ago
New software is being generated faster than it can be adequately tested. We are in the same place we’ve always been; except everything is moving much too fast.
- repelsteeltje 6mo ago
  This is exactly the feeling I have. First: excessive growth of dependencies fueled by free components. * with internet access to FOSS via sourceforge and github we got an abundance of building blocks * with central repositories like CPAN, npm, pip, cargo and docker those building blocks became trivially easy to use Then LLMs and agents added velocity to building apps and producing yet more components, feeding back into the dependency chain. Worse: new code with unattributed reuse of questionable patterns found in unknowable versions of existing libraries. That is, implicit dependencies on fragments multitude of packages. This may all end well ultimately, but we're definitely in for a bumpy ride.
- ClikeX 5mo ago
  I'm somehow reminded of Wile E Coyoto running off a ledge, staying afloat until he realizes there is no more ground under his feet.
jpollock 6mo ago
Faults are injected into the code at a constant rate per developer. Then there's the intentional injections. Auto-installing random software is the problem. It was a problem when our parents did it, why would it be a good idea for developers to do it?
- teiferer 6mo ago
  curl ... | sudo bash yolo!
- rounce 6mo ago
  This is related to a massive annoyance of mine: when I run a piece of software and the system is missing a required dependency, I want the software to *tell me* that dependency is missing so I can make a decision about proceeding or not. Instead it seems that far too often software authors will try and be “clever” by silently installing a bunch of dependencies, either in some directory path specific to the software, or even worse globally. I run a distro that often causes software like this to break because their silent automatic installation typically makes assumptions about Linux systems which don’t apply to mine. However I fear for the many users of most typical distros (and other OS’ in general as it’s not just a Linux-only issue) who are subject to having all sorts of stuff foisted onto their system with little to no opportunity to easily decide what is being heaped upon them.
  - skydhash 6mo ago
    Ruby gems and CPAN have build scripts that rebuild stuff on the user's device (and warn you if they can't find a dependency). But I believe one of the Python's tools that started the trend of downloading binaries instead of building them. Or was it NPM?
    - Izkata 5mo ago
      Python's pip predates npm, installs dependencies automatically, can include binaries, and the old-style packages could run arbitrary code during the install. Ruby gems are older than that, but I have no idea what capabilities it has/had.
bulbar 6mo ago
I think it will be an arms race in the future as well. Easier to fix known vulnerabilities automatically, but also easier to find new ones and the occasionally AI fuckup instead of the occasionally human fuckup.
- bigiain 6mo ago
  Yeah. Right now it kinda feels to me like "Open Source" is the Russian army, assuming their sheer numbers and their huge quantity of equipment much off which is decades old. Meanwhile attackers and bug hunters are like the Ukrainians, using new, inexpensive, and surprisingly powerful tools that none of the Open Source community has ever seen in the past, and for which it has very little defence capability. The attackers with cheap drones or LLMs are completely overwhelming the old school who perhaps didn't notice how quickly the world has changed around them, or did notice but cannot do anything about quickly enough.
  - Brian_K_White 5mo ago
    Well this argument was certainly inventive. What a weird impression to have about these things. Who exactly is the innocent little Ukraine supposed to be that the big bad open source is supposed to be attacking to, what? take their land and make the OSS leader look powerful and successful at acheiving goals to distract from their fundamental awfulness? And who are the North Korean canon fodder purchased by OSS while we're at it? Yeah it's just like that, practically the same situation. The authors of gnu cp and ls can't wait to get, idk, something apparently, out of the war they started when they attacked, idk, someone apparently.
    - bigiain 5mo ago
      I guess I should have realised that comment could be so easily interpreted in ways I hadn't intended - given the political nature of that war. I wasn't intending to pass judgement on which side is the "innocent little" and which is the "big bad", but I (and the downvoters) clearly see the it obviously reads one specific way. I wish I'd chosen a less contentious example of a unarguably good army that's 50 or 100 years old and is still using tactics and equipment from the 70s and earlier, fighting against a somewhat less clearly "good" army using new tools that barely existed 5 years ago and new tactics that the older army (and everybody else) has never seem before with the capability to create new weapons and adjust tactics at speeds previously thought impossible. But that war doesn't exist (at least not outside of blindly loyal Russia supporters). For the record, I believe Russia is clearly on the side of evil and Ukraine is clearly on the side of good in this conflict.
teiferer 6mo ago
What we are seeing so far come out of the AI agent era is reduced not increased code quality. The few advances are by far negated by all the slop that's thrown around and that's unlikely to change. > any useful piece of software has been fuzz tested, property tested and formally verified. That would require effort. Human effort and extra token cost. Not going to happen, people want to rather move fast an break things.
- Hfuffzehn 6mo ago
  Isn't blaming AI for that similar to blaming C for buffer overflows? More people are producing more code because of easier tools. Most code is bad. But that's not the tools fault. And in the end it is a problem of processes and culture.
  - teiferer 6mo ago
    We are not in disagreement here. I'm not blaming AI, I'm blaming the culture around its use.
- tclancy 5mo ago
  >What we are seeing so far come out of the AI agent era is reduced not increased code quality. I am not disagreeing in the main, but I wonder about the net effect. Again, this is total speculation on my part. If I vibe-slop a half dozen apps this week (and I might, just you watch), the overall raw code quality in the universe got worse. But if in the space of the same time, two major security holes got patched (assume there was no net amount of code changed), didn't things actually get better?
mahart 6mo ago
Having casually read into a few recent incidents the vector has often been outside of software. A lot of mis-configurations or simply attacking the human in the chain. And nation states have basically unbounded resources for everything from bribes, insiders, and even standing up entire companies.
dml2135 5mo ago
Here's a crazy idea -- what if some of these vulnerabilities are surfacing because they have actually been found, already, and exist in the training data? Even an intelligence agency doesn't have perfect opsec, and something could get mentioned offhand somewhere on a forum, but never get picked up until the LLM uses it.

by tclancy 6mo ago

xingped 6mo 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 6mo ago
To be fair, to some extent that’s up to us. Time to get cleaning, I guess.
FrinkleFrankle 6mo ago
New 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 ago
  The 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 6mo 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 6mo ago
  Typically 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 6mo ago
    Yes, 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.
michaelchisari 6mo ago
I 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 6mo ago
You 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 6mo ago
  Thank you for reminding us all that you AI bros are still the most obnoxious people there are.
  - larodi 5mo ago
    Indeed, 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 ago
      This seems like a very emotional response, which is off-topic for HN. Consider using facts and logic to make calm, rational arguments.
      - larodi 5mo ago
        What facts did parent use? What facts did u use? Which particular emotion do you imply in you response?

marcus_holmes 6mo ago

This assumes that there are no new exploits being generated. We're seeing maintainers retreat from maintaining because the amount of AI slop being pushed at them is too much. How many are just going to hand over the maintenance burden to someone else, and how many of those new maintainers are going to be evil? The essential problem is that our entire system of developing civilisation-critical software depends on the goodwill of a limited set of people to work for free and publish their work for everyone else to use. This was never sustainable, or even sensible, but because it was easy we based everything on it. We need to solve the underlying problem: how to sustainably develop and maintain the software we need. A large part of this is going to have to be: companies that use software to generate profits paying part of those profits towards the development and maintenance of that software. It just can't work any other way. How we do this is an open question that I have no answers for.

teiferer 6mo ago
That is already how it works. The loner hacker in moms basement working for free on his super critical OSS package is largely a myth. The vast majority of OSS code is contributed by companies paying their employees to work on it.
- larodi 6mo ago
  The sad truth about open source in 2026 is that it does not serve the society the way it is advertised or did back in the 90s.
  - spockz 6mo ago
    How so? We have open source operating systems running on a whole sleuth of systems ages apart. Interesting ideas and open collaboration coming out of the OS world. This opposed to closed off “products” that change at the whims of the company owning it.
    - larodi 5mo ago
      Statistically. Most of it is created to serve marketing, personal or other agenda needs and is sponsored through the corresponding means for it. There’s a lot of misconception about how the open source comes to be and very small part, still significant of course, of it was really created for the benefit of a community. There are exceptions, but dig the organisational culture and origins and you’ll see the pattern. Also, thousands of projects are made for the satisfaction of the author himself being highly intelligent and high on algorithmic dopamine.

Barbing 6mo ago

Will need those animal bones if all the industrial control systems get turned against us Nuclear might be airgapped but what about water, power…?

allthetime 6mo ago

New software is being generated faster than it can be adequately tested. We are in the same place we’ve always been; except everything is moving much too fast.

repelsteeltje 6mo ago
This is exactly the feeling I have. First: excessive growth of dependencies fueled by free components. * with internet access to FOSS via sourceforge and github we got an abundance of building blocks * with central repositories like CPAN, npm, pip, cargo and docker those building blocks became trivially easy to use Then LLMs and agents added velocity to building apps and producing yet more components, feeding back into the dependency chain. Worse: new code with unattributed reuse of questionable patterns found in unknowable versions of existing libraries. That is, implicit dependencies on fragments multitude of packages. This may all end well ultimately, but we're definitely in for a bumpy ride.
ClikeX 5mo ago
I'm somehow reminded of Wile E Coyoto running off a ledge, staying afloat until he realizes there is no more ground under his feet.

jpollock 6mo ago

Faults are injected into the code at a constant rate per developer. Then there's the intentional injections. Auto-installing random software is the problem. It was a problem when our parents did it, why would it be a good idea for developers to do it?

teiferer 6mo ago
curl ... | sudo bash yolo!
rounce 6mo ago
This is related to a massive annoyance of mine: when I run a piece of software and the system is missing a required dependency, I want the software to *tell me* that dependency is missing so I can make a decision about proceeding or not. Instead it seems that far too often software authors will try and be “clever” by silently installing a bunch of dependencies, either in some directory path specific to the software, or even worse globally. I run a distro that often causes software like this to break because their silent automatic installation typically makes assumptions about Linux systems which don’t apply to mine. However I fear for the many users of most typical distros (and other OS’ in general as it’s not just a Linux-only issue) who are subject to having all sorts of stuff foisted onto their system with little to no opportunity to easily decide what is being heaped upon them.
- skydhash 6mo ago
  Ruby gems and CPAN have build scripts that rebuild stuff on the user's device (and warn you if they can't find a dependency). But I believe one of the Python's tools that started the trend of downloading binaries instead of building them. Or was it NPM?
  - Izkata 5mo ago
    Python's pip predates npm, installs dependencies automatically, can include binaries, and the old-style packages could run arbitrary code during the install. Ruby gems are older than that, but I have no idea what capabilities it has/had.

bulbar 6mo ago

I think it will be an arms race in the future as well. Easier to fix known vulnerabilities automatically, but also easier to find new ones and the occasionally AI fuckup instead of the occasionally human fuckup.

bigiain 6mo ago
Yeah. Right now it kinda feels to me like "Open Source" is the Russian army, assuming their sheer numbers and their huge quantity of equipment much off which is decades old. Meanwhile attackers and bug hunters are like the Ukrainians, using new, inexpensive, and surprisingly powerful tools that none of the Open Source community has ever seen in the past, and for which it has very little defence capability. The attackers with cheap drones or LLMs are completely overwhelming the old school who perhaps didn't notice how quickly the world has changed around them, or did notice but cannot do anything about quickly enough.
- Brian_K_White 5mo ago
  Well this argument was certainly inventive. What a weird impression to have about these things. Who exactly is the innocent little Ukraine supposed to be that the big bad open source is supposed to be attacking to, what? take their land and make the OSS leader look powerful and successful at acheiving goals to distract from their fundamental awfulness? And who are the North Korean canon fodder purchased by OSS while we're at it? Yeah it's just like that, practically the same situation. The authors of gnu cp and ls can't wait to get, idk, something apparently, out of the war they started when they attacked, idk, someone apparently.
  - bigiain 5mo ago
    I guess I should have realised that comment could be so easily interpreted in ways I hadn't intended - given the political nature of that war. I wasn't intending to pass judgement on which side is the "innocent little" and which is the "big bad", but I (and the downvoters) clearly see the it obviously reads one specific way. I wish I'd chosen a less contentious example of a unarguably good army that's 50 or 100 years old and is still using tactics and equipment from the 70s and earlier, fighting against a somewhat less clearly "good" army using new tools that barely existed 5 years ago and new tactics that the older army (and everybody else) has never seem before with the capability to create new weapons and adjust tactics at speeds previously thought impossible. But that war doesn't exist (at least not outside of blindly loyal Russia supporters). For the record, I believe Russia is clearly on the side of evil and Ukraine is clearly on the side of good in this conflict.

teiferer 6mo ago

What we are seeing so far come out of the AI agent era is reduced not increased code quality. The few advances are by far negated by all the slop that's thrown around and that's unlikely to change. > any useful piece of software has been fuzz tested, property tested and formally verified. That would require effort. Human effort and extra token cost. Not going to happen, people want to rather move fast an break things.

Hfuffzehn 6mo ago
Isn't blaming AI for that similar to blaming C for buffer overflows? More people are producing more code because of easier tools. Most code is bad. But that's not the tools fault. And in the end it is a problem of processes and culture.
- teiferer 6mo ago
  We are not in disagreement here. I'm not blaming AI, I'm blaming the culture around its use.
tclancy 5mo ago
>What we are seeing so far come out of the AI agent era is reduced not increased code quality. I am not disagreeing in the main, but I wonder about the net effect. Again, this is total speculation on my part. If I vibe-slop a half dozen apps this week (and I might, just you watch), the overall raw code quality in the universe got worse. But if in the space of the same time, two major security holes got patched (assume there was no net amount of code changed), didn't things actually get better?

mahart 6mo ago

Having casually read into a few recent incidents the vector has often been outside of software. A lot of mis-configurations or simply attacking the human in the chain. And nation states have basically unbounded resources for everything from bribes, insiders, and even standing up entire companies.

dml2135 5mo ago

Here's a crazy idea -- what if some of these vulnerabilities are surfacing because they have actually been found, already, and exist in the training data? Even an intelligence agency doesn't have perfect opsec, and something could get mentioned offhand somewhere on a forum, but never get picked up until the LLM uses it.