[josephg]

> "We can't stop the occasional problem" - yes, you can.

All those tools (checklists, redundancies, etc) exist to increase the reliability rate. And to stop the occasional problem (ground crew forgets to refuel plane) from turning into a disaster[1].

I might be overly generous, but thats my read of the author's intent. That just like in the airline industry, we have tools to stop occasional problems from turning into disasters. Things like:

- Deployment scripts instead of manual processes

- Dependency auditing (ideally automated)

- Automatic OS-level security updates

- Memory-safe languages (Go, Rust, Java) instead of C/C++

- Defence-in-depth (firewalls, host security, etc)

- Sandboxing (OpenBSD's pledge, Linux's seccomp, Deno's capabilities, etc)

Just like checklists in the aeroplane industry, these approaches require active effort. We don't get secure software if nobody cares enough to make it a priority.

[1] https://en.wikipedia.org/wiki/Gimli_Glider

[closeparen]

As long as software has bugs and accepts user input, there are going to be ways to make it do things it shouldn't. You can avoid running specific known vulnerabilities. You can avoid creating certain kinds of dumb and obvious ones. But barring, like, formal verification, it is always possible for someone smarter or more patient than the original software development team to think real hard and come up with an edge case they didn't. And operational or system-level controls can only do so much about that.

Preventing every security vulnerability is the same problem as writing bug-free code. And that is manifestly not happening, not even in the most sophisticated software development operations in the world.

[josephg]

Right; which is why all the things on that list are so important. We can’t seem to stop the endless flood of memory bugs in C/C++ code. Iirc 65% of security issues in chrome are due to memory bugs. But we can move to Rust and friends, where those bugs are a lot harder to write.

We’ll never get the bug count to 0. That isn’t the goal. The goal is to get the number of in-the-wild exploited vulnerabilities as low as possible. And there’s all sorts of ways to move the needle on that, which don’t require humans to suddenly become infallible.

[zefix]

Well said: The point is to make a proper effort to make the tools we use better.

Humans will always make errors. Let's stop denying that and start fixing the mess we are making.

[krisoft]

> And to stop the occasional problem (ground crew forgets to refuel plane) from turning into a disaster[1]. > [1] https://en.wikipedia.org/wiki/Gimli_Glider

While I agree with your general point I have to disagree the particulars here.

The ground crew did not refuel the plane, because the pilots did not request refuelling. There was no-one "forgetting" to refuel, least of all the ground crew.

The pilots did not request fuel because they thought they have enough. And they thought they have enough because they made a unit conversion error in their calculations. (there are even more layers and twists and turns to this cheese lasagne, but no one "forgot" to refuel that is for sure.)

[sand500]

I wonder how well the swiss cheese model works when there is an adversary actively targeting you as opposed to accidental disasters.

[scotty79]

> checklists, redundancies

These things are created and extended because occasional problems happened.