AI is forcing us to pay off 40 years of technical debt
https://spectrum.ieee.org/ai-in-cybersecurity-php2shell-vulnerabilityIt’s frustrating to have all these 0days and CVEs to patch for now, but in the long run perhaps we’ll leave with more robust software.
The only way to do that is to make your code provable. That again is only realistically doable using AI.
In the process, people will have to turn the pretense of "software engineering" into reality, making the engineering part explicit.
That only works when humans actually understand what they're doing.
> -- Donald Knuth (if I recall that exact quote correctly)
Just because you have proven the correctness of your code, that does not mean that it is infallible. Especially -- as a lot of HN users point out -- there's intricate complexity that is likely to cause erroneous behavior if several interfaces/complexities get combined. And those might be caused, for example by a 'user' setting the driver to 'db.backend.sqlite' instead of 'db.backend.sqlite3'; and then you have suddenly an unexpected configuration.
I think that LLMs actually cannot do this right now while people can?
Also there is a lot of defensive programming that has been left to application and runtime layers because of dated security models in our OS and permissions that are way too coarse. It's a lot easier to write a correct program when you don't have to check every path and do that perfectly when the permission system can ensure that no files that haven't been whitelisted cannot be read
Namely:
> The only way to do that is to make your code provable.
Proofs are a mathematical concept. They only work in the abstract world of mathematics where everything is perfectly logical.
Engineering exists in the real world. The physical realm where our mathematics are only imperfect models of what actually exists. Removing bugs through physical engineering requires persistent trial and error until you have found all the places where our mathematical models don't adequately represent the real world.
It's the same in software engineering, which involves cobbling together a myriad of systems not all designed to talk to each other and massive, ever changing codebases where perfect knowledge is impossible.
So yes, we should be trying to engineer bug free code. But that's really more a matter of changing our resource allocation, spending more time and money on QA and doing away with mottos like "Move fast and break things". It's a cultural shift and will only come when the bosses -- the venture capitalists who ultimately control our industry -- are held accountable when things break, and given strong incentives to ensure they don't break.
We have way more resources now to achieve way higher standards.
Open Source was supposed to prove this, but as it turns out, there weren't enough human eyeballs, and those eyeballs weren't looking for bugs. LLMs eyeballs see the entire codebase at once.
The quote captured the fact that a human reviewed proof could have mistakes in it. This is very different from a Lean verified proof.
The opposite. The amount of bugs that I've seen AI add to software is tremendous, some bugs are things that even a 18 years old that starts working as a developer right after school wouldn't do.
Also they are unable to fix them, if you ask them to fix a bug they probably introduce 3 other more, and so on, and you arrive quickly at the point that the code is a mess of spaghetti that needs to be rewritten completely (by a human, this time).
On the opposite side AI is good at finding bugs, so I use it more as an advanced linter that tells me if I'm doing something wrong.
> The only way to do that is to make your code provable. That again is only realistically doable using AI.
If you're code is "provable" doesn't that only mean you've proved the code meets its specification? The specification can still have bugs.
Extreme naivety alarm... Explain how code provable allows for bug free software. Would love to understand the intellectual jump there.
I'm skeptical; every line of code is a liability. Humans regularly make the trade-off between adding lines of code vs doing without the incremental feature addition. LLMs don't; everything gets added.
The recent brotli attack should have been a wakeup call - few people use it, no one actually needs it, but the exploit that it carried was present on every system. Everything from IIS to Caddy and in-between, and yet no one was actually using the thing.
It's a liability to add code, whether you're duplicating existing code in the codebase or adding a feature 1% will use.
LLMs can run with whatever directive you give them. If the directive is lots of code that's what you get. But when everyone gets repeatedly burned by vulnerabilities the directive becomes building bullet-proof code. With the right prompting an LLM can be a lot more diligent about that than we ever could.
By default, yes. But you don't have to let them, and enforcing some code quality was shown to use significantly fewer tokens (can't find the link now).
To me KISS is basically about how you’d write the code, the architecture, which is something that - at least currently - humans need to oversee when writing new code with LLMs.
But what does it have to do with AI discovering a ton of bugs in a lot of (open-source) software?
It is also unfortunate than in more than half the cases where AI provides a 'fix' that fix breaks something else, so my guess is this is going to be 90% human labor to correct, at least initially.
A complete plan to reduce vulnerability from untoward influences is more feasible now with agent assisted engineering. You have to be carefully selective about what matters and what doesn't, or the cost and time balloon out of control.
One does not simply "write a browser"...
HTML is entirely the wrong comparison as it's a document format and not a programming language, and "as long as you can write a browser" is not a simple condition. Do we have any browser (even in development) that isn't written with current toolchains? Or a headless javascript runtime perhaps?
I predicted long ago that when computers become totally secure intelligence and LEA will lobby for mandatory backdoors, possibly through secret courts.
in the beginning, ppl didnt know a lot, and default passwords and stack overflows were 0days.
then awareness came and a lot of that is actually fixed. Writing a modern exploit more often now requires many stages and a shit ton of skills and knowledge.
that will increase.
nothing will be 'fixed' in that utopian sense.
NSA spent 20 years stockpiling vulns and pushing the industry towards half-assed solutions like address sanitization and pointer tagging when they could have put the industry on memory-safe languages instead.
They managed to get the IME/PSP/TrustZone into 99% of the CPUs out there by mandating it for government purchases; they could have done the same thing with memory-safe languages. But instead they chose to stockpile vulns. Hope they burn in hell for this.
Even if they wanted to, I highly doubt they could push the industry to do that. The industry does what it wants to do, and rewriting tons of software was far from its priorities. There were no LLMs back then to help with such a massive migration.
There's also the fact that rewriting software tends to introduce a lot of new bugs.
Yeah, about that. Its the biggest vulnerability in the industry. Nobody wants to confront this fact, though.
Too much profit to be made in subversion and human rights abuses.
I remember reading Godel Escher Bach back in the day, and there is the parable of the record player between the tortoise and the rabbit. And the tortoise keeps building more and more secure record players that the rabbit keeps finding ways to break.
GEB then goes on to teach you that, no, in fact, you cannot have a perfectly secure system. Not just practically or economically, but even in theory, all systems are fundamentally breakable. GEB, after a lot of chapters (what a doorstop!) ties that parable into Godel's Incompleteness Theorem, and essentially proves that no, you can't make unbreakable things, as a fundamental point of logic.
So, when I look at all this, I see that yes, there is an economics point of view here, that fixing code is just expensive, like making a less and less breakable record player. And that AIs push that breaking and economics point much further along than what we have had.
But then I also see a lot of comments here that seem (to me) to be arguing that there is an unbreakable code out there.
Am I reading this right? Is there such a thing as 'perfect' code? Or is my outdated reading of GEB still valid or not?
[0]Note, I'm not a CS person, more a biophysics person.
Godel’s theorem says that unprovable true statements exist. Fortunately there is a vast set of provable true statements that are quite useful in real life.
Similarly, the halting problem is that you can’t write a program that always determines whether absolutely any program you give it will halt. But in real life compilers can still detect infinite loops in your code unless you try really hard to fool them.
In practical terms a software system can never be “perfect”, because first you have to define “perfect” (i.e., specify correct behavior in every possible state), which is practically impossible, and even if you manage that, the hardware has to implement the software abstraction perfectly, and that never happens. (See prefetch attacks, cache timing attacks, supply glitch attacks, rowhammer, etc.)
The security issues come about when someone finds where you failed to specify desired behavior, or (at any level) your system failed to implement it in some circumstance. No strange loop required.
Having never written compiled code, this intriques me. I often write one offs that I actually want to loop infinitely until I tell them to stop.
How does the compiler know whether it's just really long or infinite? Like, if I write a progressive approximation of pi or prime search algorithm, both are never going to halt because we're certain there are infinite digits of pi and prime numbers. The program could technically halt, but not as a function of the program but rather the hardware.
Or, being silly, if I write a "flip bits in target directory until all bits are flipped" and target /dev/null as a user of the software, it wouldn't halt, so the compiler would detect that?
Is there some --don't-mind-the-recursion flag for developing a program like ycruncher? I get the feeling that there's a list of "this typically causes infinities" that it checks against and if your use isn't on there well then... So it's just the mouse/mouse trap thing but in a compiler?
Or is there some unique CS going on that the compiler employs to determine certain classes of loops?
Gödel's Incompleteness, very roughly, says that not every true statement (in a formal system) can be proven. In particular, it says that for a logic equipped with arithmetic the statement holds; how you get to security I do not follow.
The idea is that since you can make every security program turing complete, I thiiiiink?, then you can have it be a formal system. So, you can then get the code, in very tortured ways, to execute a paradox, thereby breaking it. Likely in enough ways to let you gain access, though not always.
Clearly our math system gives basic math, so we should conclude that it is either 'incomplete' or broken. Before the incompleteness theorem, it was exciting to imagine that it might be complete, but we had no idea. Now it seems likely to be incomplete. The odds of it being broken haven't really changed.
If it is broken, 2+2 still equals 4 (we didn't really learn that fact from abstract math), but we'll need to fix up set theory. In a world where math isn't formally verified (and even lean itself isn't formally verified), the Incompleteness Theorem is permission to be awed by how huge the space of all logical deduction is, not an argument that logic is a fiction.
To come at it another way, do you believe that there is an 64-bit integer which, any time it is inserted into register 8 on any computer, will immediate convert the raw mass of the earth into a black hole? No, because even if you suspect there is a hole in the foundation of math, you still believe in brute-force case-analysis, and you know that every 64-bit integer has been inserted into register 8 on a computer before.
Yes, we're going to see the bugs exposed by AI and it's going to suck a bit for a few months.
But when this is all over, software will be more secure than it has ever been before.
I mean, LLMs themselves come from exactly this phenomena. They are a product of finding a technology that scales and going with that no matter what. And parts of this will hit a wall and have to retrench, current players may implode but the genie isn't going back into its bottle so disruption within disruption will continue.
Maybe? I’m not 100% on this one.
Not trying to be a downer, but it could become a mixed bag is all I’m saying.
I don't see sufficient evidence that this is not going to be a perpetual race between people/AIs fixing existing software and more advanced and powerful next generation AIs finding new vulnerabilities and exploits.
It totally feels like the former if you watch it find and fix vulnerabilities or other debt-tasks one after another.
But only so many of these "technical debt" issue are little off-by-one errors that get remedied by a surgically narrow patch.
Many enough require some kind of restructuring or redevelopment of their own and it's going to take time to figure out if AI faces the same dilemma as human developers: where each non-trivial change carries the risk of some new issue, ad infinitum.
If that happens to be the case, and AI isn't able to magically produce perfect software in finite time, then what's really happened is that the threat of hostile AI exploiting our technical debt will force us to always be burning and churning code just to remain a moving target.
It's another "we'll see" thing for now, I think.
Yes, let's fix the foundation. It will make adding features easier once the debt is paid off. And we will probably learn how to do better in the future. It reminds me of settings compiler warning to be treated as errors. Once you do that, you have a ton of work to do. But if you are smart (not all devs are), you learn why the warnings are there and avoid these problems in the future.
see: https://www.computer.org/csdl/magazine/an/2022/03/09779481/1...
Really, we never should have left the Garden of Eden. Things were great there, other than the maternal mortality rate.
My problem with even talking about this is that there's absolutely no evidence for it. The idea that coming up with a technology to find holes in the hulls of boats starts with a flurry of holes being found and a bunch of patching to be done does not even hint at the theory that there are an infinite number of holes in all boats, and now that we can find them we will have to spend the rest of our lives patching them.
Code was bad, and we knew it was bad. We would have found most of these bugs if instead of coming up with LLMs, a bunch of countries got together and decided that they were going to put $10B into hiring programmers to do nothing but review all the code in the world for bugs. With AI, we managed to do it for only a trillion dollars.
But there are potential upsides like the already mentioned possible nation state exploits (sleeper exploits).
That is a choice I make every day when I get into an argument with Claude about the chosen design and how I find it insufficient. Does it slow me down? Sure, a little. But at least I know the foundation is bedrock instead of sand.
These certs only exist for compliance, not for security. Nobody cares they don't add any extra value, because they allow every business to say "my supplier was ISO certified, so I did my due diligence".
And nobody really ever gets prosecuted for lying during their audit.
https://consilien.com/news/what-is-iso-27001#how-do-you-actu...
I have. What I wrote was based on personal experience working for an ISO 27001 certified company and being very involved in the (successful) audit and recertification.
> You will not pass the independent audit if you're bad at security.
Incorrect. You will pass if you have all required processes documented and have documentation that show you follow those processes. Whether you actually do follow the processes is irrelevant, the auditor just needs to think you do.
Also, you can be incredibly bad at security and still be ISO 27001 certified. For example:
Process: Describes that employees use an encrypted password vault for secret management. Keys in the vault are rotated each year and when employees leave.
Reality: Keepass database is sent through email, the password is "CompanyNameVault2023!", which is shared in the same email. Keys are never rotated because it's annoying.
This will 100% get you ISO certified, in my experience at least.
It's like anything else in life: a house, a car etc.
There's no debt about it though. I hate the term 'tech debt'. It's very vague and has these negative connotations that are ambiguous.
The biggest monetary risk is obviously is the frontier labs, and the variability of seed companies in general, but I really just can't wrap my head around the frontier labs being able to communicate with all the businesses about their individual security needs.
Companies that just do Red Team simulated attacks to find and expose tech debt are going to be critical to literally just communicating these vulnerabilities to management.
I think the real issue we are facing isn't the 40 years of tech debt, that's obviously real, but the real issue is communicating to non-technical management of companies of basically any size that they absolutely need to prioritize this stuff. People don't understand that we're going to live in a world where every single 0-day is going to be figured out in 48 months, and it's going to be easy pickings if you don't take this stuff extremely seriously.
Yes, AI developed code might have vulnerabilities or bugs, but so already has your JSP based web server that has Oracle and God knows what else among dependencies.
One thing that I find confusing is you can always prompt a model to find more bugs, and invariably it seems to always be able to
Bostrom touches on this somewhat pessimistically:
> The apparent safety of a tool-AI, meanwhile, may be illusory. In order for tools to be versatile enough to substitute for superintelligent agents, they may need to deploy extremely powerful internal search and planning processes. Agent-like behaviors may arise from such processes as an unplanned consequence.
Double side sword. If you were the creator, the owner of the source tree, easy win. Why not. You know what it will change and the states changed from it.
If you're someone with no understanding to the code has been tasked with "use ai to fix bugs" that is where the trouble starts. When you don't hold the full knowledge of the source tree then you should be shy in using LLM's to fix bugs.
How do you know that bug fix doesn't cause issues further up-stream?
Instead of a highly structured engineering process it's more like a gardening process of figuring out what works, what doesn't, what the Business actually wants vs what their requirements were
So more debt because there's more code but it's easier and simpler to change that debt. And in 3 years the product is EOL so shrugs
Developers would do well to remove the word fast from their vocabulary. It has done tremendous damage to human systems (and the mental well-being of the people dependent on those systems). The whole reason the "technical debt" exists is because there's an addiction to speed. The sad part is that when you poke at that with most people, they couldn't give you a clear reason as to why they need to move fast; just that they have a sense that it's "how everyone does it."
Then what about November? Vantablack November?
Everybody in the industry knows that we've been building on quicksand. Moore's law meant that we could just sacrifice performance and add a dozen layer on top of technology from the 90s (if not older) and keep the thing chugging along.
Look at the PHP situation:
- HTTP is an old and quirky protocol with a lot of surface open for attackers that are rarely useful nowadays and might be better left off to higher layers. But of course, we can't break compat, so everybody still implements all the naughty parts, just in case.
- PHP was a joke language from the start, we were making fun of it in the early 2000s, the fact that over 20 years later it still powers a huge chunk of the web is enough to demonstrate that we're not serious people. Cue the PHP fans telling me that "it's good now". Maybe, I don't really care, the effort that went into making it good should have gone into ditching PHP for a better language 20 years ago. The bandaid mentality is what got us in this situation.
- And of course to add insult to injury, PHP, this security-critical language, is still implemented in garbo C using things like setjmp/longjmp. Just to make sure to absolutely maximize the damage if a vuln is discovered, I suppose. Brilliant.
- Oh and all of this is still running overwhelmingly on top of x86 which is its own bag of legacy garbage. "No but you don't get it, modern CPUs are really more like RISC CPUs, the RISC ISA is translated internally" yeah exactly that's my point let's stop doing things like that.
We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people and we can iterate and patch things quickly. We never had to do things correctly, we could flourish with abysmal levels of quality acceptance. This may not be true anymore.
Of course the reason things are done this way is generally to maintain backward compatibility and make transition easier. At least now that we have LLMs this excuse will hopefully vanish: porting even huge codebases to a new language/framework, something that was a tremendous undertaking mere months ago, is now vastly easier and faster. We can leave the 1990s behind us.
I think you have things backwards. Devs aren't clowns who make it this far. But in industries where buggy code doesn't kill people, devs are expected to ship fast and iterate, because they can and more importantly, it serves the business.
Personally, I'm all about good software engineering principles, unfortunately I don't think you can last long in most companies if you're too opinionated about this and can't compromise (and it's getting even worse with AI, reading the code is no longer a requirement, go explain your teammate that there's an abstraction leak in their code...).
But explaining that openly, as is your duty, means surfacing something which could be read as 'bad work' by a non-technical manager unable to grasp the complexity. So in low-trust teams it very quickly becomes a game of brinkmanship, or a prisoner's dilemma for technical diligence
But shipping faster was pushed at almost every company until, if it's not revenue generating, stop putting resources into it. Not all are like this but it's not all or nothing, it's always a sliding scale how much you can put into making the software correct.
2026 is saying "here is the consequence."
Look at the solo projects from professional devs with nobody overseeing them. Look at what so many of your colleagues submit despite the frustration of your thoughtful team lead and manager. Look at what your so many of your team leads asks for even when they've been granted full discretion. Some select few are great, but most are disturbing if you have any sense of quality or preparedness yourself.
Even for decades before AI, there was lazy naive misguided slop everywhere. During the social coding era of the last 15 years this even amplified itself, streamers and influencers and conference presenters -- professional developers themselves -- would share horrid practices to wide applause. Moving fast and breaking things was what developers were excited about. Rigor was dead. Correctness was a problem for later. Code was presumed best written by a rando on github who'd accumulated a lot of stars rather than by a known responsible hand. Security was a copy and paste job from Stack Overflow, not something to be comprehended and considered.
If only it were a top down problem from outsiders!
But the truth is that the call has been coming from inside the house all along, and the outsiders giving direction have had no problem finding celebrated industry "experts" and "thought leaders" affirming and encouraging all the clowning they could imagine.
Developers could always move fast and do things right but most just didn't have any interest in learning how, and many of those who might have just gave up on bothering.
Just take a look at some of the opensource academic, infrastructure or "passion-projects", where there is no management pressures to "move fast & break-things" and ship-ship-ship. They tend to be very stable, very predictable - and very high quality.
I've seen software that academics write. It's no better than average. It's often cut-and-paste code, or these days AI slop. Software is a means to an end in academia, rarely a product in itself.
That might be true on the margin, but highly doubt it was ever true once you escape a very shitty local optimum.
https://ijcionline.com/paper/13/13224ijci12.pdf
Wow, it’s almost like it’s really hard to get everything perfectly right and this is endemic to software, particularly when the language accepts incorrect code.
The only two things we know mitigate this are proofs (eg rust borrow checker, lean, etc) and DST which is basically the equivalent of accelerated time testing which is done in other industries too. Most people don’t even bother with property testing
simias referred to the industry and you took it personally.
Why is it whenever someone mentions the shortcomings of software industry, there is always a comment saying "no no no, developers were just following orders!"
But also every developer has a responsibility. At least not to promote any technology which is part of the problem.
Trying to understand underlying reasons and incentive structures is much more productive and useful than simply venting about the worse moral character and seriousness of people in one industry vs the next. Curiously, the grass seems always greener - when you ask people in other industries, you'll often hear endless complaints about the state of things there too.
This isn't unique to coding, but coding has been built on it for decades, with the "safety valve" of "who has the time to check all that?". So defcon speakers and intelligence agencies burn time investigating for weak links that might take months to find, and the rest of the world churns on.
Now you have companies throwing thousands or millions in compute at problems just checking EVERY possible problem and yeeeeup, looks like there's a lot of "good enough, ship it" which is now a major problem for all those companies using that tech.
It's still going to be interesting to see how this develops because, yes, there's a lot of code being written by people who haven't even read it (although the amount of enterprise production level code I've seen that's bad stack overflow copy paste makes me less worried about this), and there's maybe better tools and standards to catch these things (why not spin up a test suite if it's an afternoon of AI poking rather hiring a dev and getting them up to speed?).
I’ll keep checking
First, I am not a PHP fan, but I will absolutely stick up for the "its good now".
Yes, absolutely no debate the old PHP 4.x/5.x was shocking. However to give PHP their due, they absolutely did make serious efforts in 7.x/8.x. They deserve due recognition for that.
Unfortunately lots of people – I'm guessing you're one of them – still have battle-scars from 4.x/5.x and they think (incorrectly) that 7.x/8.x is "more of the same".
Second "joke language", well, cast your mind back to what else was available at the time... ColdFusion, CGI, ASPX ... it was not exactly a beautiful world back then.
Sure, to borrow your terminology, the Java fans will be along soon to tell us all how awesome Java is for the web. But many of us still bear battle-scars of the horrors of Java stacktraces, messing around with incomprehensible XML config files, Java's penchant for eating RAM for breakfast, and generally trying to figure out why the hell Tomcat is not working (again !).
well, there's no Java2Shell at least.
Pffft. VRML is the whole game, baby! Once everyone runs out and gets an SGI oxygen, Nobody is going to use freaking web browsers ever again. I mean, HTML, what a joke.
You’re missing the point. Those are all dead. The implication is that PHP should have had the same fate.
What industry do you think is different?
I've had a decent amount of construction work done on my house, and if I had a pound for every shortcut that the guys doing the work took, it would pay for the work they did. And these are the _good_ ones. The bad ones don't even bother following the legal requirements. Somewhat recently [0] it was found that less than half of healthcare workers followed recommendations on _hand washing_.
[0] https://www.cambridge.org/core/journals/infection-control-an...
If you want a web page that works with a database (aka. CRUD), presents it in HTML form, and with a bit of business logic, like 90% of websites, then PHP does it simply. None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now. There is a reason PHP became so successful despite the hate it gets.
PHP is not great for security, it was terrible when it started, but now it is decent. And sure, a vulnerability was found, it is now fixed, every time a vulnerability is found and fixed, PHP becomes better. New technology may have an advantage due to better design, safer languages, etc... but you shouldn't dismiss the qualities that 20 years of bugfixes get you.
As for x86, yep, it is legacy, but it is not completely stupid either. The "RISC core" is not right, it is not like x86 become ARM or RISC V code internally. It is translated into long microcode-style instructions that wouldn't make sense as an ISA, where a compact representation is important for memory/cache reasons. RISC code is also translated just like x86 code, and the advantage of CISC vs RISC has gone back and forth. Now it seems we are going back towards RISC again, but before that, it was CISC, and before that, RISC again. The quirk about x86 that complicates things seems to be the variable length instructions. But the real problem is not really about which ISA is the best (it is a very small part of modern CPUs), it is more about licensing and backwards compatibility.
In the end, PHP wasn't great, but around 2000 it was a great intro to building things on the web.
Verbosity of a language/framework is meaningless now. Pick a language or platform that makes it as hard as possible to write insecure code, no matter the tedium, and let a coding agent bang away on the keyboard for you.
PHP is hard to beat for development velocity. Edit a file, refresh a page in your browser, see the results.
Another industry does even better: the medical/health industry. It's both a clown industry AND kills people AND they have made it way beyond what software can only dream.
The big fun factor is the place in the Venn diagram where they both intersect. I used to work for a medical device manufacturer who's biggest and most popular product routinely had stack traces at inopportune times.
(I'm not kidding. If you take each element of their designs and invert it, you end up with a very solid design.)
On that note, I misspoke somewhat: I assert that PHP and JavaScript were not "badly designed", because that would imply that someone sat down, carefully considered how the different parts of the system interact, second order consequences etc. — and then somehow came to all the incorrect decisions. Rather, it's quite clear a serious design process has simply not occurred to begin with.
Once I recognized this phenomenon, I began to see it in all areas of life. Things are much worse than they could be, simply because nobody has designed them to be good. They just ended up the way they are now, by accident of history.
--
Polemic aside, I am fond of JS and PHP in many respects. I just think we should clean them up! "This mess has always been here, so it's too late to clean it now" would be laughed at in any other context.
We already broke compat with "use strict". Now we just need a "use sane" :)
I don't think it holds with
> If you take each element of their designs and invert it, you end up with a very solid design.
The rule of thumb is "the inverse of stupidity is not intelligence". So, if we have an example where you can get a good design by inverting the bad one, we can't then state that the bad one was a result of a chance. The probability is very low.
- Variable naming conventions (_field in Python).
- Lexical scopes.
- Visibility annotations (public, private, protected).
- Coroutines, threads.
- Packages/modules.
- Sandboxes.
- Processes.
- OS capabilities (pledge/unveil, SELinux, etc).
- Local user accounts.
- File permissions.
- Containers/chroot.
- User mode vs kernel (Ring 0 vs ring 3).
- Virtual machines.
- Cryptographic measures (secureboot, attestation, memory encryption, etc).
On the other hand we have few mechanisms to share data: the filesystem, clipboard, sockets, maybe dbus. Shared memory if you're feeling brave.
If a script wants to know what file is currently open on my editor or what email attachments I recently uploaded, the editor or email client has to explicitly implement this feature via one of those limited mechanisms. Almost nobody does this, so we're stuck with black box applications that are hostile to customization.
So that leaves non-technical managers telling non-technical nerds to just install WordPress. Then, AI comes along and wipes them out. And everyone is like... how did this happen?
It's pretty obvious.
>So that leaves non-technical managers telling non-technical nerds to just install WordPress.
Good summary of how the world operates generally everywhere. It's a clown world.
I'll generally agree, and I include myself in this industry, but we've simply have been bound by compatibility. I don't think anyone chose intentionally to keep the crap around; it was simply never worth it to pay the "break compatibility" cost, until now.
The interesting thing is that memory bandwidth has become a big issue. CISC instructions take up less space than the equivalent RISC instructions, so you can effectively get more instructions per cache line. Effectively the CISC to RISC conversion acts as a type of decompression. Because if that, stopping the CISC messiness without moving to a compressed instruction stream would actually hurt performance.
In theory CISC instructions take less space than the equivalent RISC instructions, but x86 has lots of legacy features which makes it far less efficient than a CISC could be.
Absolutely. The industry could have moved towards safer languages, better coding methodology and formal verification years ago (see for example MISRA C as at least a partial movement in this direction). It didn't, because it was cheaper not to.
This goes double when you add in the same non-technical-sourced pressures that caused developers to take shortcuts are still there, and now even worse with their unrealistic expectations for LLMs.
LLMs might make this somewhat easier, but you're still going to have to deal with backwards compatibility and legacy systems. Completely eliminating the use of architectural cornerstones like x86 or HTTP or even PHP across the entire industry isn't going to happen anytime soon, let alone overnight, especially if the only argument for doing so is "we could design this better if we implemented it from scratch".
There's only one area I sorta give a pass, and that's mainframes. It takes an insane amount of physical servers to replace a mainframe. Why IBM didn't invest more into making mainframes a drastically better platform for devs is beyond me. I don't know that any other server platform has ever achieved the level of uptime a mainframe has.
Still, it is no excuse to leave them with ultra legacy code that remains unmaintained for decades.
Exactly. There was even a whole domain of expertise (SRE) that exploded because of the lack of engineering rigor. That's not to say if everyone did all the right things all the time there would be NO need for SREs, but there would be fewer of us - something that I've tried to communicate to everyone I've worked for in the past ~14 years of being one.
But we had to deliver. We had to increase shareholder value.
I am no fan of PHP but it wasn't really a joke language. Its goal I think was to add some dynamic snippets to your homepage for which I guess it served its purpose pretty good. PHP even originally stood for Personal Home Page iirc. The problem seems to be that the rest of the language was built on top of that. I haven't used PHP in over a decade, so I don't know if it's still the case, but you used to start a PHP file with a PHP opening tag, which is such a weird "feature", but I guess kinda makes sense in a world where everything outside of PHP tags used to be HTML.I remember seeing PHP files that were impossible to work with: thousands of lines with HTML mixed in with PHP classes etc.
This was the tradeoff (or should I say trade-up) for going from
#!/usr/bin/perl -w
use strict;
my $username = <>;
chomp($username);
# blah blah blah blah blah
print "<html>\n<head>\n[...]<body>\n";
print "<p>Hello, " . $username . "!</p>";
print "</body>\n</html>";
<html>
<head>[...]
<body>
<p>Hello, <?php echo $username; ?>!</p>
</body>
</html>
> HTTP is an old and quirky protocol with a lot of surface open for attackers that are rarely useful nowadays
HTTP 1.x is that, perhaps. But I was in the trenches when HTTP/2 came out, brand new and running on binary. It was so new that there were very few implementations around, and my team had to code one. The people who worked on the spec had a lot of learning to apply from HTTP 1.1. That resulted in many nice bits in HTTP/2, but HTTP/2 also had serious issues at a spec level. Which is my way of saying that "modern" doesn't necessarily mean "bug free".
Not sure why you would. It seems like the people who made these compromises were roughly right and the problem only escalated when it also came with a solution.
Who's we?
The issue is simple: YOU work for clowns who prioritize financial success above all else, including quality of output. You usually don't have the ability to say "No" to a bad decision made by a senior person. Deadlines, managers dumping more work, feature creep, etc. Then, when you can't deliver they taunt you for their incompetence. So you eat shit all day long churning out crap. That or management hires the bottom of the barrel because its cheap and maybe one or two seniors who eat turd sandwiches all day, give up and ship shit. Enjoy workplace hell. Fire your incompetent boss.
It's especially fun when not implementing the naughty bits is its own source of vulns. Your code is simpler and less prone to RCE, but your proxy mishandling or whatever allows for credential smuggling attacks, identity spoofing, request smuggling, cache poisoning, and all the normal issues at the application layer.
The risk is of course, an earthquake where it could destroy all houses built before year X.
But we do the same in all industries, path of least resistance.
Don't forget the other half of the web development stack: Javascript. The absolute worst scripting language ever desi--well no, it wasn't designed, it just kind of happened accidentally. At least PHP solved a problem of the day, Javascript was nonsense from the start, and somehow managed to become critical infrastructure.
While yes, PHP begun as a collection of macros and was never intended to be a programming language, JS was made by someone with intention. To quote from wiki,
> [Eich] originally joined intending to put Scheme "in the browser", but his Netscape managers insisted that the language's syntax resemble that of Java. As a result, Eich devised a language that had much of the functionality of Scheme, the object-orientation of Self, and the syntax of Java.
I've seen quotes before from Eich himself I believe that he was combining these influences at the time - Scheme's closures, Self's prototypes. It didn't "just happen".
Still, I pray you’re right.
Software devs absolutely love to create a mess, and are never challenged by business, product, management, or you name it, to increase speed to market, cut down cost estimates and, to say it crudely, deliver half-assed work.
Systemic issues have systemic consequences.
There quality should be there, but it should only ever be “good enough”
I bring this up because it's the first thing that popped into my head thinking about PHP's legacy. And, admittedly maybe it's not the best analogy, but when people shit on the caissons that bridged the internet because it seems crazy in hindsight to continue use those techniques, shit dreamed up by wacky people to do the impossible, or maybe said we should tear it down and build it a different way, the reality is that sometimes you just leave the bridge in place and improve where you can. It's still standing, you know?
I might be stretching here with all this, but despite you making some very defensible points, I just don't buy into the whole narrative. Just because retrospection has blessed us with the ability to intellectually point out that we built things on quicksand doesn't mean that there were real alternatives to build on at the time. The ease and speed that things like PHP provide(d) allowed enough things to be created to make the web as we know it coalesce into existence in the first place. Pedantic or more expensive or arguably safer choices easily could have slowed progress to a crawl, OR you just build the bridge and see if it's still standing 143 years later.
And in some cases, it is.
[0] https://www.pbs.org/kenburns/brooklyn-bridge
I've certainly taken time to address tech debt whenever I could. Which was not as often as I'd like.
The Morris worm was already a sign, but alas, as long as there is no punishment, no one cares, like buying at those 1 € shops.
1. It just werked. You could write incredibly shitty code and it, like HTML, would work as long as there wasn't a fatal error. And sure you could just say "git gud", but that's not going to happen. People will just use the best language that works for them, and in this case, it was PHP.
2. It required very few resources to run low to medium traffic websites. Because of the Apache mod_php module, PHP sites wouldn't use any resources if they weren't being served, unlike every other language at the time. So it meant places could host thousands of websites on the same server no proble.
The guy who created PHP, Rasmus Leerdorf, never wanted and never expected that PHP would become as popular as it has. He has mentioned that he thought that at any moment, someone was going to come around and create a language that would succeed PHP. But it never happened. People are just better at pointing and complaining instead of solving the issues that people want solved.
It's totally the devs fault and not the environments devs have to work in. Deadlines forced down on you until you have to make compromises, 24/7 having to compete with people who actually don't care because you have to meet months end payments somehow. Whole businesses blinded by a tech gold rush.
>We're a clown industry.
I do agree here, but that includes every non dev person.
You don't see the same problems in say, structural engineering as you do in software engineering. I suggest this is due to needing to go through the formal training required of a structural engineer, and membership bodies like chartered institutions, with standards and codes of ethics. We might want to reflect on that
I basically just worked extra unpaid hours with a colleague to do it since it was frustrating. Not even from a security standpoint as it is now, but just plain developer happiness.
But while we were cleaning the Swamps of Dagobah the other team was extending them.
Our deliverance came when the other team got woo-ed by React and started coding less in Ruby.
For my mental sanity I treat the React project as a black box.
Just heard they had to update the Redis connection configuration in 6 places, after we had switched to Sentinel based connections.
I seriously can't with my people sometimes.
Things have moved on from PHP, but at the time, the alternatives had many more tradeoffs in a wide range of cases. Without PHP the internet would have unfolded much differently, much more slowly.
The "bandaid" mentality you decry exists of course, and is outright bad in some cases, but is just good business in many others.
Rewriting everything makes no sense. And, of course, in the vast majority of cases is never going to happen, so advocating for that is effectively advocating doing nothing at all for 90%+ of sites. A much more efficient and effective approach to using AI here would be to find and fix issues in the PHP runtime, and to assist in automating the deployment of the runtime. Time spent on this fixes thousands and millions of sites at a time, in a consistent, improvable way, rather than one at a time, in a piecemeal way.
> We're a clown industry
I think if we want to bring more engineering discipline to software development, we need sober analysis, not outraged rants.
Ironically, the opposite is the case with LLMs. Now those on your teams that wanted to stop the clownery will be overruled by the vast amount of bullshit code from their less skilled peers. Of course, those that care can use LLMs to faster clean up, but there's no way they are able to keep up.
Managers always favored outcome over correctness, and not giving two shits about the internals was, and will always be, incentivized.
What effort? PHP foundation has one employee!
> The bandaid mentality is what got us in this situation.
> We're a clown industry.
We are clown industry becauee nobody would sponsor solid research, infrastructure and fixing all those bugs! PHP is junk literslly written over nights by some volunteers!
And yet everyone knows this, and millions of people still continue to use it and develop new software with it, to avoid learning from our mistakes. The software industry is just not interested in fixing these problems; I've heard people upset that AI is pointing out flaws, instead of being upset that flaws exist. Deeply unserious.
The CISC vs RISC debate hasn't been interesting in a quarter century at least. The only real difference is that the instruction decoding (which CISC and RISC both have) is likely going to need more transistors on x86 than other contemporaries.
But I'm not sure what you mean by "stop doing things like that". The ISA is "the API". Sometimes the best CPU implementation (for whatever definition of "best") will need to change the ISA-to-microcode translation.
It's not reasonable to assume that a decades old ISA will have a 1:1 instruction to microcode mapping. Hell, it's not even 1:N. Macro-op fusion makes the mapping N:M. So you could say that RISC also has variable length instructions, in a way.
And RISC-V has two sizes of instructions, with RVC. So it's not even "super transistor efficient because all instructions are 32bit".
Then there's the "reverse micro-op" that is instructions intended to cause traps for software to handle. E.g. Alpha's PALcode that handled (among other things) unaligned memory accesses.
What you wrote reads a bit like ye olde typical "nyeeeh javascript! you're only a dev if you write everything in assembly! kids these days!"
My guess is aviation or .. defense?
We don’t have billions to throw away on making sure our about-dialog is memory safe.
The real clowns union paradoxically is the least clownish industry one can find.
At least put some formal verification on top of that GenAI pile.
How can even call these people an "industry"
That’s what I started to do 10 months ago.
You want a safer language AND transpilers from PHP, JS, Python etc. into it? So you can find issues in your original code using source maps, or just speed up your PHP by 10x and your Python by 100x? Here you go:
What the heck have you been doing instead of pointing out the obvious?
Your analysis is severely flawed and naive.
Software devs often patch and sidestep the root issues for the same reason why every single engineering field resorts to patching ans sidestepping root issues.
Why do you think there is such a thing as aviation duct tape? This is a field where people's lives are on the line.
There is a very puerile belief around opinionated junior devs which an inconvenience in the code justifies redesigning whole systems, even if they are still quite capable of performing their functions. Things need to be clean and ideally elegant, and any minor deviation is cause to tear everything down and start over.
In the meantime, experienced and competent engineers instead get the system back in working order and downgrade the criticality of existing issues until it's convenient to address them.
Go ask a project manager if all bugs should block a release, or if it is ok to release something with a known bug. Listen to them. Perhaps then you'll understand why patching works.
I'll believe it when I see it.
Otherwise, I completely agree.
No we don't need to have documentation and keep updating it what you can't read code? No we don't need to rewrite system that was patched ad absurdum so codebase became fragile and its hard to navigate layers of abstractions. We need to deliver this project yesterday at all costs since somebody up there slept on requirements for 6 months and didn't do their basic job, and we will never pick up half-assed pieces we were forced to deliver. No we don't need to update those 12 years old libraries, too much work and testing. I could go on and on.
It seems like you consider engineering to be delivery of perfect things, or utter failure. Thats not how things are anywhere, sw dev is more unstructured but you also don't have 5 million ways to build a good wall using every possible substance in the universe, do you.
Been saying to boos and rotten veggies "it's just electrical state in a machine; yall are deluding and debasing yourself for money." And "if you want to improve security stop using leaky abstractions to configure your machines".
Even better is that AI is replacing all knowledge work it just reinforces how absolutely bonkers the US "services economy" is and giving social stature to credentialed randos whose skills are whittled down to cooking frozen meals, grubhub, and Excel Sheet expert; unserious country peddling before the eyes of the poorest manual workers all these years that their degree in accounting earned them the right to wander through someone's home town across the world via resource intensive travel
Or better yet just being born rich earns them that!
This is an unserious country and social culture top to bottom to continue to assume modern people of nations rebuilt since Murica bombed them to the stone age don't see how Americans are drinking their own piss since the end of WW2; refusal to acknowledge externalities like generational churn (among all the others) makes it clear America is an unserious country.
HR and accounting and even a law degree do not make the individual worker bee irreplaceable themselves; whole lot of arrogant low skilled "knowledge workers", biological fuzzy VHS of often debunked pseudoscience studies now 30 years outdated... can pound sand.
Set aside the circumlocutions inherent to old thinkers like Marx and Adam Smith and capitalism is a social/communal discovery of services and prices; seems pretty fucking social and communal. But that's not "the Sacred Jedi Texts!"[1]
Top to bottom American society is a clown car stuffed full
[1] will take to my grave Luke screaming about Jedi Sacred texts was a metaphor for dogmatic people in general
But we are out in the pacific now, and boats that sink make no profit, so we will evolve again, and again.
But it’s hard to blame Moana standing on a pacific island for not inventing a nuclear powered battleship.
(Trying not to be too blame-y on either side)
Every SW developer must use AI to test the security in existing and future projects before deploying. I cannot believe it has not been done yet for all public facing software. And a system must be deemed insecure if it does not pass an LLM stress test. This should also become standardised and maybe included in OWASP.
The world didn't end. It was a complete black box, but we followed the runbooks and kept things running, and only learnt enough of the code as needed to fix any issues or add any enhancements that popped up. Diving in, doing some software archaeology, and spot-changing relevant code became a skill we had to develop.
At scale and over time, I would guess that the percentage of code running on machines that is actually understood by anybody approaches 0. Yet the world does not end.
I'm working on a repo these days that's larger than _entire companies_ I worked with in the past. A 10-person team maintaining more code than 100s at a previous job. The _scale_ makes this wildly different from what we're used to, no matter how much "legacy code" you had to maintain before.
We, too, have to adjust to this change, this new abstraction layer, because whether we like it or not, the code an LLM will produce in no more than five years will arguably be much, much better than the code any 10x developer could produce even if given months of time and an infinite supply of caffeine.
We "just" need to find a way to confirm that our work in this new abstraction layer - primarily prompt engineering - results in the code functionality that we had in mind, not necessarily the code implementation that we had in mind.
But software powers so much of our modern world, seeing companies decide "well maybe we don't understand the code but trust the governance and harness will allow AI to always fix it" is essentially that above hypothesis in action today.
It's like an over-eager junior engineer that will implement whatever pattern they read about last week. It just doesn't feel trained on high-quality enterprise, battle-hardened codebases.
Even Opus 5.5 on High thinking still littered a root directory of a JS project with source files without thinking to put it in a 'src' directory. It had to be told to use a testing framework. Had to be told to also test with Firefox (the project already had established Chrome /and/ Firefox targets).
I have to continuously burn tokens and effort correcting it.
I imagine it performs a bit better with a huge corpus of architecture and style guides. But I did expect to get some that for free with the "leading" model.
Same with that situation. One shot code from prompt is still not great. Maybe if you had a prompt with highly detailed requirements for structure and code formatting it would be ok.
I generally hate the look of AI gen code, so I have some pretty detailed code formatting rules for even small edits. And the AIs still ignore them some of the time.
I don't know what I'm getting at here; other than. It is acting pretty human like at this point in the code delivery phase. Human as in asking someone to do your work for you and you not always getting back what you want; as opposed to being good enough to replace your actual work (assuming you are good at the task you are asking from the Agent -- does work pretty fast though. which makes it a trade off worth considering; but then your time is in picking through the code to confirm it is correct).
If AI's code is sloppy but bug-free, is it better than the alternative?
All those "paying down" technical debt with AI, I would advise reading the code _very_ carefully. Sometimes the "solution" which passes some test or adheres to some described functionality is incredibly narrow / brittle, and/or has failure cases that are non-obvious.
Yes I'm using $latest_model on high, its still not there. Unless your threshold for "fixed" is "the 1M line lean proof runs, we don't know how it works", it still requires a lot of attention, hand-holding, and scrutiny, especially when fixing issues / working around failures (where it tends to shortcut or invent workarounds).
Turns out nobody wants to use them, they caused many subtle bugs in existing features and is a distraction for many things we do.
The developer left the team, and I am left with purging all of this.
Also, those very average developers are also the ones doing the code review.
Anthropic is literally creating their own git alternative because they are slopping so much code. You think its 100% secure? Even if it has bugs at 10% the rate, there is 10x more of it to go around.
Do you think Anthropic's git alternative tool is more secure and better written than git? Hah, I bet it was just some vibe-coded thing they did over a couple of days, when it starts bogging down, dropping commits, or getting unstable, they just have to prompt harder! I wonder why they won't open source or release to the public, its probably too dangerous to release!
There is a concept of the hourglass model [0] of internet protocols, where IP sits at the waist. I believe that similar things are probably true in any "stack" based structure, such as computing, where the protocol at the waist has the most staying power (which at the current moment could be e.g. x86, or something) because it's essentially the universal translation layer that enables all the language protocols built above it to be agnostic to all the transport protocols below it. So, I see it as an open question as to what the best way to affect change in a situation like this is. I'm interested in if anyone else has any thoughts along these lines.
So, the headline should read,
"AI is helping us eliminate 40 years of technical debt."
Since AI found the bug, and probably also generated the patch at this point.
An abundance of solutions is a problem for people who sell solutions.
AI removed 80k lines of code and nothing broke. much of this code was written by AI few months earlier.
It's insane that we haven't yet migrated to capabilities based Operating Systems with default deny instead of default permit.
Maybe this will be the push to get us over the hump?
With enough tokens, all bugs are shallow.
Thanks to The Lord everytime someone discovers the vulnerability he reports it right to the owners/maintainers and there are no bad actors out there keeping it as secret and using for years.
Anthropic is arguing for formal verification [0]. This is an excellent idea on the edge of feasibility, but it's hard to see how this can work for the majority of software that has to adapt rapidly and are so open ended that it's difficult to even conceptualize all the input modes. It's an easy prediction that we will see verification on large trunks of fundamental software in the next few years, and a sub-verification confidence scheme for the software on top of it.
my webserver never needed a million lines of code just to pass bytes to other people
nothing i'm proud enough to open to the world yet, but my personal public server will be my first deployment, and will definitely "Show HN" then too :)
My approach is https://tix.im/ - not launched yet. But from expedience: modeling everything as workflows of composeable nix flakes (expert systems from programs, skills, agents, workflows and their snippets, DBs blobs, service descriptions, ...) and then run everything in highly isolated environments. It is not only so much more efficient, reduces errors, increases quality, reduces unnecessary cognitive load, ...
I start to move more and more daily tasks into the systems. Even UI programs become interactive workflow steps, which allow me to attach from anywhere back to a task in an environment optimized for the task.
Dependency updates for example, a workflow. A subgraph from a security scanner expert checks each change in the dependency tree.
tix.im combines conecepts of expert systems with LLMs and other AI systems. Everything is composable via nix flakes. Any change is modeled via workflows that run in isolation. Each step type, is composed from the nix flakes defined and installed in the environment. Not only the projects nix flake (devshell), but also the tix project enabled experts. vx-maintainer is my software development expert - does only know about conecept of software development. Each workflow implemented is steps and workflows. For example, each change lands via land-feature workflow, it has ~40 steps. Workflows have complex parameters that define the flow inside the workflow DAG. In this case, rebase is mechanical, if it fails, medium smart rebase fixer is spawned, then mechanical step checks if all commits arrive in the rebase. Then it builds a collections, spawn a review swarm, open-code-review, etc... everything is tracked in an own issue tracking system and workflows can be restarted with minimal overhead.
Then I have an optimized queue-manager, an own agent prompt with an goal that can never be fulfilled. He manages that items from the tracker get done and land, extra workflows mechanically later check the landing.
rust expert, knows about rust specifics, has snippets, agents, skills etc. security expert has workflows with red-teaming, cyber models that get registered at the internal LLM gateway for usage, ...
I start to model everything in my daily live as an expert system now, with workflows that can be used by other expert flakes.
Workflow steps can be shared and also run wayland and x11 apps, rmux multiuser sessions etc. So, my goal is to move most of my tasks into some specialized environment.
And this is just a small part of the architecture - it is fully decentralized and user owned.
>But from expedience: modeling everything as workflows
No thanks. I like private computing. I like all the fun stuff you can do with Computers. I'll never want agent based computers.
Just consider how laughable some working conditions in software are and then come to realize how architecture is shaped by the organization communication patterns and not reality. You will see it in a different light then.
I've never considered this problem from this perspective, but damn, I think you're dead on.
[1] https://www.theverge.com/ai-artificial-intelligence/949601/a...
[2] https://openai.com/index/coordinated-disclosure-of-critical-... - "To help more defenders use these capabilities, we’ve committed $1 billion in subsidized Daybreak access through Daybreak for Frontline Defenders, focused on organizations with limited security resources protecting essential services."
[3] https://www.anthropic.com/glasswing - "Anthropic is committing up to $100M in usage credits for Mythos Preview across these efforts, as well as $4M in direct donations to open-source security organizations."
i hope we get to a place where we keep the same number of developers employed as today, but leverage ai to make all software better across the board. hopefully the people in power realize that we've been understaffed this whole time.
Not technical debt, just a preference for doing things a different way (which admittedly might be a better way, but just because there's a better way doesn't mean the current way is bad)
AI is enabling us to fix longstanding software security issues that nobody had the time, skill, or desire to find
All a matter of perspective, I suppose.
They've always had the first two to varying degrees - it's the desire that killed most motivation.
Should be something like:
> nobody is paying to find and fix
AI lowers the cost, but certainly doesn't eliminate it. I think we can hope significantly more technical debt will be paid off, but don't expect too much.
Aren't there still vulnerable services right now being hacked?
I hope the effects of AI result in a massive reduction of PHP and Python prevalence.
What do you think the chance of nonzero budget and time being allocated for this is, given that almost no company has seen real consequences to the business?
Yeah, hmm a lot of people don't actually auto update their PHP so.. it's not like the vulnerability disappeared from the wild.
I fear it's only going to get worse.
We'd be replacing decades of technical debt with debt we'd have no hope of paying.
This summer I had my Docker registry poisoned with malware artefacts, which again is something that no sane attacker would do before as it required downloading my images, carefully modifying them and then overwriting them, ensuring they work as before. Now it's just a simple prompt away. I am definitely ramping up my defenses, everything that doesn't need to be Internet connected goes behind double VPN and port knocking schemes, essentially making my infrastructure invisible from the outside, all unknown packet types get hard dropped, end-to-end encryption of all internal traffic, web endpoints behind CDN proxies and WAF providers (as much as I hate doing that), double and tripe security mechanisms everywhere, maximum restriction of privileges, ultrafast automated patching and AI based continuous monitoring, audits and interventions. You should also get used to that, this will surely still get much worse as attacker tooling gets better.
Back then, you could log in as admin to any phpBB forum by copying a generic admin cookie from a shady web site. You could often then also compromise the hosting company that was running the forum, because nothing was really separated.
You would try to trick your friends into installing Sub7 so you could open their CD drive.
You could easily capture other people's data on public wifi networks in restaurants and hotels.
You could change the price of the pizza you were ordering through devtools in your browser.
You could infect half the world by emailing a picture of a blonde tennis player.
Sure, there have been quite a lot of pretty serious zero days recently. But many of them have been pretty hard to actually abuse, in part thanks to all these layers we've added over time. So I guess I'm not as pessimistic as many of you are. Especially because we all seem to be incredibly aware of what's happening and are acting on it.
The hack was simple enough that you could change the price in the HTML and it could be purchased for that amount. You were suppose to implement verification yourself on checkout but no one did.
Everybody wants a $1 Website, avoid security updates, pay nothing for maintenance, and done yesterday.
It has nothing to do with AI or a specific language or stack. As long as cost cutting will be the culture, driven by the economical model of competition, then we will accumulate technical debt BECAUSE it is the strategy.
That said, if we were a closed source project, I don't know that our own tooling would have discovered all the issues using LLMs as we are seeing more and more creative ways of people exposing exploits that I never would have thought to put into the LLM prompts.
If all you had was an API endpoint, you wouldn’t realistically have any way of figuring out how the internals work and finding obscure exploits.
A 1000 of us regular devs scanning a piece of code is not as effective as a single review by, say, Tavis Ormandy. So "enough eyeballs" is only "enough" when one of those set happens to belong to a Tavis O. or the likes.
Not to mention, this assumes a 1000 of us even look at the code, which is statistically never true. Approximately 100% of us just install the software without looking at a single line of code. Hence the code auditability aspect of open-source software never really applied. And hence, "supply chain attacks."
Unfortunately, this misguided "law" was taken as gospel by many, and as you found out, still is.
Instead they court martial anyone who talks about the designs. Because obviously, telling everyone every aspect of your security isn’t actually more secure. How would you know how to do a 24-step process to exploit something if you have no idea what code is running on their server?
Imagine trying to build a cheat for CS:GO if you had no access to the game and could only play it via a remote connection. Good luck.
It's true but the problem is assuming, just because something is open source, it has received sufficient eyeballs. AI now gives us near unlimited eyeballs so, if we survive the bumpy transition, open source should indeed become very secure compared to closed source.
Except we won't get the expected benefit, because all those eyeballs are attached to a very small number of different "brains" (LLM models.)
The original saying depends on an implicit assumption that eyeballs are proportional to minds, and that among those varied independent scans, different people will catch what others miss.
In other words, we shouldn't assume 5.5x review thoroughness when we hire 11 QA eyeballs but they all belong to Bobby the Beholder.
I don't understand how you get to that conclusion.
Do you think that an open source project will receive more AI eyeballs than a closed source project?
Using open source source software lets you share responsibility and oversight with a large number of people. But it brings with it a much larger attack surface than you'd have if you only implemented the part of that software that you need, and a much more complicated threat model for supply chain risk.
If a large number of people collaborate on open source software for something, especially if it's security or infrastructure related, that makes the project itself a much higher value target than any individual company's home grown mail server or http proxy client would be. Participation makes your vulnerabilities more public, since interacting with the public open source project, making blog posts or hiring ads mentioning it, hosting it (and thus serving traffic in a way that signals or directly tells clients what implementation it's using), bundling it with your site or binaries, etc. tells prospective hackers 1. how to find potential exploit targets for a general open source vulnerability 2. where to look for or introduce vulnerabilities to pwn a particular target.
AI auditing isn't really a silver bullet because it costs a non-trivial amount of money for each commit or PR, and scales with the number of contributors to a project and the project's size. Normally you want more of those with a software project, but in this case it makes AI auditing more expensive unless it's shared across the project and basically part of its CICD (and I don't think that's really been fully adopted yet). But then that introduces other risks like adversarial payloads where the attacker verifies that the AI security checks in place for a project don't trip when they actually send the malicious code for review, because they can run the same checks offline and tweak the payload until it passes.
Personally I think we're headed toward an outcome where only very challenging, well-resourced, and critical open source software is worth using for developers. For smaller things it makes more sense to just use AI to implement your own version of it, or fork/take inspiration from a project and mold it to fit your needs.
I agree on this part, but what's your point here? Are you suggesting closed source is better?
Also, closed source software can similarly be analysed with AI, but there's no guarantee that the company involved will deal responsibly with disclosures.
Do you have examples of people saying this? I don't think I've come across idea being espoused...
Instead we're spending the time churning out busy work fixing bugs that were too low value to care about a year ago. We have a new street lamp so we're working on anything it illuminates.
I haven't really seen the same kind of push towards verifiable software. It's mostly around solutions that will perpetually burn tokens and justify usage of the new toys.
Mine is a cynical take for sure but I honestly really miss meaningful feature work but that's not what the market's interested in right now, I guess
... "by legacy sites"? :O
That's a pretty spectacular mischaracterisation of PHP's place on the web.
<cough> Wordpress <cough>....
Bridges don't get driven on until they're inspected. And they only pass inspection if they were built according to standards, and meet design specifications that have to take safety into account.
How we get there, how we enforce it, is another conversation. The point is that we have to start getting serious and be real engineers. The bare minimum standard should be that you can drive a truck over it without worry. How much software can you confidently say that about?
It's only been the latest years where software has had a hard crash in quality.
I'm not a PHP person, but so much of the world actively runs on it silently.
All technologies have gaps. PHP was affected differently not because it's old, but because it's so ubiquitous. Python is as old, so is Javascript, and many others.
At my current day job, if I mention “hey, how about you update PHP to at least a supported version” people start whining about how that takes a lot of time and if really anyone would try to attack our public facing services written in… PHP.
Next time we get hit I can sit back, eat some popcorn and say “told ya’”.
I've been bullish on Rust for years because memory safety is simply too important and Rust can essentially prove an implementation correct and solve a certain class of very important bugs. It doesn't solve every problem and there is a complexity cost.
I've also said that writing multithreaded code is simply too complex. In an era of out-of-order execution, different levels of caching, asymmetric cores, hyperthreading (although this is largely dead now?), branch prediction and having to support multiple architectures it's simply too hard for most people to write correct multithreaded code. Period. If you find yourself as a non-library developer creating a mutex or spawning a thread, somebody has screwed up.
This is also why I think the single-threaded async/await model with post-request teardown of PHP is the correct choice for most people.
We're going to go through a dark period of a lot of 0days. As the article notes, this is paying 40 years of technical debt. It will result in a more secure ecosystem however. I believe this will ultimately also hamper black markets, governments and 3 letter agencies who trade in those 0days.
As painful as this all is, it will ultimately be a good thing, one of the few to come out of AI (IMHO).
Well now, Great Responsibles, it's clear you too were out of your collective depth and were all paying for your smug hubris. Perhaps take a bite out of that humble pie you've obviously never tasted?
I think one should, of course, be critical of those who write C code for PHP, but at the end of the day, some part of that criticism also goes to C. C is both a king and a problem. And it seems very hard to fix the problems of C.
Wow. Love it or hate it, but tell me you have no idea what PHP's place in the web ecosystem is without telling me you have no idea what PHP's place in the web ecosystem is.
Keep in mind that every PHP application globally was advised to completely cut network access or entirely shut down until the patch was available, so this was global critical infrastructure failure. I'm surprised lives weren't lost as a result.
And no, from what I've seen, it had nothing to do with the few entities that did rightly ignore the embargo after the exploit was already being circulated, even though the PHP devs are seemingly still putting resources into spinning it that way.
I'm sure the defender community will eventually come up with a way to patch security vulnerabilities just about as fast as they can be discovered and exploited.
AI does find things, but it is a small percentage the overall vulnerabilities.
IEEE is of course and industry owned organization that shills for BigAI, NSA and any other entity with money or influence.