Relevant Tony Hoare quote: “There are two approaches to software design: make it so simple there are obviously no deficiencies, or make it so complex there are no obvious deficiencies”.
Of course it's trivially NOT true that you can defend against all exploits by making your system sufficiently compact and clean, but you can certainly have a big impact on the exploitable surface area.
I think it's a bit bizarre that it's implicitly assumed that all codebases are broken enough, that if you were to attack them sufficiently, you'll eventually find endlessly more issues.
Another analogy here is to fuzzing. A fuzzer can walk through all sorts of states of a program, but when it hits a password, it can't really push past that because it needs to search a space that is impossibly huge.
It's all well and good to try to exploit a program, but (as an example) if that program _robustly and very simply_ (the hard part!) says... that it only accepts messages from the network that are signed before it does ANYTHING else, you're going to have a hard time getting it to accept unsigned messages.
Admittedly, a lot of today's surfaces and software were built in a world where you could get away with a lot more laziness compared to this. But I could imagine, for example, a state of the world in which we're much more intentional about what we accept and even bring _into_ our threat environment. Similarly to the shift from network to endpoint security. There are for sure, uh, million systems right now with a threat model wildly larger than it needs to be.
To be clear, I'm not one of the people who believes that software is going away or that UX is going away. I think those are both still very important. But I do think that a lot of legacy software can be replaced, and then we'll end up with a new level of software in the longer term.
Then the social proof moved to proprietary darknets, e.g. Facebook pages, which is easier - you don't have to learn anything.
I've seen no local small business care about its webpage, but I've seen a lot of them painfully struggle with crappy LOB smartphone apps.
I expect software and UX to only decline in quality.
Usually the way this happens in practice is that you take what has been learned about the market and the requirements from older, bloated, not-working-anymore products, and then start a new company and a new product that is simpler and hits 80% of the use cases with 20% of the complexity. There's even a name for this in business: "Disruptive Innovation". The simple product will eventually become bloated and complex and fail once it gets popular and lots of people start working on it, but then you start the cycle anew.
The economy is actually very well structured to accommodate this. One of the great parts of capitalism and market economies is that it tolerates partial failures extremely well: you just buy from a different supplier. This is in contrast to other systems like fascism, communism, socialism, bureaucracy, and state capitalism where the failure of the system usually means the failure of the state as well, because there is no way to replace parts of the system without a revolution.
There is arguably a problem with the current U.S. economy where the government has become overly involved in certain "too big to fail" industries, thus creating a system much closer to state capitalism that can no longer tolerate partial failures and so is condemned to one huge failure. This is unfortunate, but the eventual resolution is the same: throw it out and start again.
- a very large codebase
- a codebase which is not modularized into cohesive parts
- niche languages or frameworks
- overly 'clever' code
You need to check out how Claude uses Ghidra MCP or even tell it to use radare2 to disassemble even proprietary hardware ROMs.
We don't even come close to what LLM can understand in just a few minutes.
I regularly run it on large codebases because I'm not able to grasp it in any reasonable timeline.