The average software product is worse. Lots worse.

And half the software products are worse than that.

Any organisation that said "let's move fast and break things" is now busy finding out what's actually broken.

Depends. Security is and never was only bug free software.

If no attacker reaches system X you are not as exposed as with your internet facing frontend.

Security is an onion, it has layers.

But, and it's a big but.

Each layer must be made as security as possible or one flaw can lead to all the layers below it collapsing.

Not reaching system X is just security by obscurity. People have learned the hardware just because something isn't directly connected to the internet that doesn't mean attackers can't reach it. For example clever data poisoning attacks can reach deep into organizations and breach systems you'd never expect.

Unlike Postgres, the average product isn't written in C or C++, so it's probably better. People (even the Rust fans) underestimate how many footguns are everywhere in C and C++. Even the best developers write security bugs not infrequently.

And the average product is solving much easier problems (in terms of low-level programming, which is where the worst bugs tend to be) than a high-performance database.

> People (even the Rust fans) underestimate how many footguns are everywhere in C and C++.

The process of learning C++ (and to a much lesser extent, C) is almost exclusively one of learning about the footguns and how to avoid them. It's a life-long process, nobody ever finishes it.

It's a lifelong process, the earlier you start the longer it takes.

Most likely pretty bad. It's not all that difficult to sweet talk Fable into doing a security review of a code base. I've pointed it at a few of the major open source projects in the main tech stack I work with and it found dozens of bugs in each. Many were fairly minor, and some of the more significant issues relied on fairly narrow attack vectors (for example, a compromised DB server being used to attack a web server). But this was just a single search pass, literally a few lines of prompt and an hour's worth of agent time.

Postgres is old but a lot of its features are new. You can't really say it's mature software, as much as it has changed over its lifetime.

Truly mature software doesn't get used, because people see low activity on github and assume it's "dead" or see no new features in years and assume that it's stagnating.

Note how Robert mentions a sharp increase in back-patched commits. Many of these bugs have indeed been around, silently, for a long time.

And if developers were working on the old features instead of adding new ones, perhaps they would have found and corrected those old bugs. Then you could say that the code was "mature." But improving old code is not exciting, and it doesn't get attention.

Simply put, this is where LLMs are good, they don't have an ego.

But they do have a cost, and somewhere a human is still making decisions about spending that money on old bugs vs. new features.