Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It is impossible to write bug-free/exploit-free code.

But some companies are using this as an excuse to not care about the chances of an exploit at all, and just write code in a cheaper way.

We need a middle ground, where there is at least a reasonable effort towards security.



"It is impossible to write bug-free/exploit-free code."

Right, and this should be the single deciding factor for most system programming and core infrastructure development. One doesn't throw away 20+-year-old battle-tested code simply because it's grown ugly bug fixes for edge conditions no one wants to worry about. The idea that it's possible to throw away, say 30-year-old font rendering code and replace it without revisiting a lot of the problems along the way is peak hubris.

And the same goes for choosing and building internal IT systems, KISS should rule those choices because each layer adds additional code, additional updating, etc. Monolithic general-purpose software is not only a waste of resources (having software that 9/10th is just taking up disk/memory/cache space because only 10% of its features are used), but it's a maintenance and security nightmare.

This is the problem with much of the open-source world, too. Having 20 different Linux filesystem drivers or whatever is just adding code that will contain bugs, exploits, and a monthly kernel update containing 80 KLOC of changes is just asking for problems. Faster processes, updates, and development velocity in projects that were "solved" decades ago are just a playground for bad actors.

So, to go back to Andrew Tanenbaum and many others, no one in their right mind should be writing or using OSs and software that aren't built from first principles with clearly defined modularity and security boundaries. A disk driver update should be 100% separate and compatible with not just the latest OS kernel but ones from 10+ years ago. A database update shouldn't require the latest version of python "just because".

Most software is garbage quality written by a bunch of people who are all convinced they are better than their peers. And yet another code review, or CI loop, isn't going to solve this, although it might stop a maintainer from throwing poorly tested code over the fence instead of subjecting it to the same levels of scrutiny they give 3rd party contributors.


> A disk driver update should be 100% separate and compatible with not just the latest OS kernel but ones from 10+ years ago.

People, companies, countries that do this, will be overtaken technologically by others that accept the brittleness and move faster.

I think the solution is to have a balanced approach, both to advance relatively fast and keep things relatively robust. Who knows, in the end, maybe this crash is a reasonable price to pay for all the security Crowdstrike has provided over some time. It's not at all easy to tell.


It is certainly possible to write bug-free code, in terms of meeting a formal specification of behavior, and guaranteeing no behavior outside that specification. It requires formal methods, and it's much more expensive than ordinary software development.

Creating exploit-free code is another matter - you have to be able to craft exploit-free specifications, and there's no real understanding what that might even mean. But bug-free software would be a start.


You're just moving the bugs or exploits to the specification then. Cool trick, what can I say.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: