Most Software Is Insecure in Boring Ways

When people imagine breaking into software, they picture something clever: a novel exploit, a chained zero-day, a researcher staring at a disassembler at 3am. Having spent time auditing real applications and their infrastructure, I can tell you the reality is far more boring, and that is exactly what makes it dangerous.

Most software is not insecure because someone found a brilliant new attack. It is insecure because it is carrying vulnerabilities that were public, documented, and patched months or years ago, and nobody applied the fix.

The vulnerabilities are already public

You rarely need a zero-day. You need a changelog.

A huge share of what an audit turns up is n-days: known CVEs sitting in dependencies that were never updated. A web app pulls in a library, the library ships, and three years later that exact version has a published advisory with a CVSS score and, often, a working proof of concept. The attacker does not have to discover anything. They read the same advisory the defender ignored.

Two concrete flavors of this that I have run into:

• A years-old SQLite CVE still present in a shipping dependency, because the app vendored a library once and never tracked it again.
• regreSSHion (CVE-2024-6387), the OpenSSH unauthenticated remote code execution from 2024. A forgotten SSH daemon on an exposed host turns a "we don't really use that box" into unauthenticated root.

Neither of these is exotic. Both are the kind of thing a single apt upgrade or a dependency bump would have closed. The vulnerability is not the bug. The vulnerability is that nobody owns the dependency tree.

A patch announced is not a patch applied

The other recurring lesson is from re-auditing after fixes. When you tell a team about a finding and come back to verify the remediation, a surprising amount of the time the patch is not actually a fix.

Sometimes the version got bumped in one place and not another. Sometimes the vulnerable code path is still reachable through a route nobody thought to test. Sometimes the "fix" was a config change that a later deploy quietly reverted. Verifying a patch is its own audit, and skipping that verification is how teams end up confidently shipping the same hole twice.

Why it keeps happening

None of this is because engineers are careless. It is structural:

• Software ships when it works, not when it is secure. Those are different finish lines, and only one of them has a deadline attached.
• Nobody owns the dependency tree. The library you added in year one is still there in year four, and "update the dependencies" is never anyone's ticket until it is an incident.
• Security debt is invisible. A missing patch produces no failing test and no user complaint. It sits silently until someone with the advisory finds it.
• "It passed a pentest once." Security is treated as a one-time gate instead of a property that decays the moment the next CVE drops.

The unglamorous defense

The fixes are as boring as the failures, which is good news, because boring is cheap and repeatable:

• Inventory what you actually run. You cannot patch a dependency you do not know you have. Most teams are surprised by their own software bill of materials.
• Patch on a schedule, not on a scare. Treat dependency updates as routine maintenance, not an emergency response triggered by the news cycle.
• Verify the fix. Re-test the specific path. A remediation you did not confirm is a hypothesis.
• Reduce what is exposed. The forgotten SSH daemon, the debug endpoint, the admin panel on a public IP. Every service you do not need is one more advisory that can ruin your week.

It is the same lesson, all the way down

I spend most of my time much lower in the stack, on firmware and boot security, where the instinct is to assume the network and the peripherals are already hostile and to shrink the set of things you have to trust. Auditing applications taught me the same thing from the other end. The exposure is rarely the exotic attack you did not anticipate. It is the known, documented, public weakness you did not get around to closing.

Security is not mostly about being clever. It is about doing the boring, unglamorous maintenance that the clever attackers are counting on you to skip.