The need for security update is largely due to poor development practices where safe and unsafe code is mixed together, lots of dependencies with unclear provenance and quality, etc.
We had a recipe for a much stabler stack decades ago: separate runtime (might need to be patched regularly) from a high-level business logic (never needs to be patched if done properly).
E.g. old way of developing web front-end was like that: you code directly in JS. It never needs to be patched, only browser needs to be patched.
Same thing with Excel/VBA, etc.
But new devs don't know any of that, they just want to use latest "framework" which pre-installs whole bunch of vulns. And if there's a patch you need to rebuild. Constant churn just to satisfy the trend
Or in the past code just sat unpatched via obscurity because fewer people were looking. After all there are plenty of exploits from injection to CSS that we have fixed or migrated away from for code from the far past
The idea that everything is so broken that it needs to be patched is just wrong.
A C program which just manipulates strings and other data structures can have a remote code execution vulnerability because C is a shitty language with no memory safety, data and control flow can be mixed, etc.
But that's just not true for high level code, say, in Python. If you don't use some low-level hacks, Python code just cannot corrupt memory, by construction, and it cannot cause RCE. You can execute attacker's code only if you use a language function which might execute code, say, eval or unpickle. But there's only a handful of such constructions and Python developers could easily implement hardening which would forbid any such calls, guaranteeing that only code which was written by developer gets executed.
Yes, occasionally there might be a logic flaw in code which needs to fixed, but it's not same as weekly updates - framework version 1.2.3 uses package 4.5.6 which has a vuln. That's only recent lunacy.
I'm not saying that e.g. everything written in Python in safe - but that old platforms were almost ready for "works forever" software, and we don't have that anymore,.
Separating the runtime from the business logic doesn't really work because the business logic has the authority to do anything it has the authority to do. It's the https://xkcd.com/1200/ problem all over again.
I don't think so. Business logic just works with data it has access to. Backup, encryption, access control can be separate concerns. A good programming stack would make sure you don't have RCE.
Flawed business logic might corrupt data, but that's much less rare than security vulns, and might be solved by versioning data (e.g. copy-on-write, even Windows had Volume Shadow Copy service which can take a snapshot of all data).
The main problem is that there's no incentive for software vendors to separate parts: e.g. app which processes financial records might also send/receive data over internet. If user had a more explicit control over flow of data (e.g. imagine n8n style pipeline) many logic flaws like sending data to wrong place could be eliminated.
It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.
> Business logic just works with data it has access to. Backup, encryption, access control can be separate concerns. A good programming stack would make sure you don't have RCE.
The problem is that the business logic tells everything else what to do and has authority to do everything that the program can do. Exploiting that way is fiddlier (it's like doing ROP only more so), but ultimately once the software gets into an unintended/unexpected state it's game over.
> It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.
Many have tried. If you try to require fine-grained permissions and user in the loop people just say yes to everything. Ultimately the user thinks they want to do the thing they said to do, and asking them again won't change that.