The road to zero CVEs is littered with bodies of developers

Authored on 2026-10-01

You are a developer who cares about what you build. You care about protecting customer data from Bad People (ok bad people might be the ones you work for but that's a whole different can of worms).

And surely you have a CISO. Every respectable company has a CISO nowadays. Your favorite ramen pop-up is likely to have a CISO and a shortage of BoH staff.

In theory your interests align. In practice CISO is likely to have zero interest in security, they care about numbers. One number in particular, the coveted (and frankly unachievable) "0 CVEs". Some CISOs that fall slightly to the right of normal distribution are likely to mandate a qualifier added to said target, like "0 CVEs with CVSS score of 7.0 or higher".

Of course, 0 is a great number. It's so great that until quite recently the most advanced minds didn't believe it could even be a number. However it's also unrealistic.

There are CISOs that find themselves 2σ to the right. Amazing as those humans (allegedly) are, the only improvement over the stated unrealistic goal of 0 CVEs they make is adding a time component to it. Developers are given "grace period" of anywhere between 24 hours and 30 days to address CVEs as they are published.

Awesome, now you have a ticking time bomb.

The practice

This rant is of course incomplete if I don't demonstrate how these policies lead to developers checking out or worse yet, burning out.

As employers have pushed more and more on the shoulders of developers it didn't happen without some good support framework. It included such gems as repository templates with broken CI patterns, mandatory enterprise enrollment of each and every line of code and deployment flow managed by a roll of duct tape dropped into your version control system which is then proudly proclaimed to be the canonical implementation of industry standard of "GitOps". ¹

Every dependency must be clean of the eternal sin of CVE, every container must be bare and unauthenticated HTTP endpoints are a crime against humanity (fortunately for us corporations are not signatories of Rome Statute so we good).

If your repository just happens to have a dependency with a version that has a recent enough CVE -- boom you can no longer deploy until you bump that dependency to non-vulnerable version. No fix available? Tough luck. But wait, what about just vendoring in the library? Now that is the kind of out of the box thinking we want our developers to have. Perfectly fine from security office perspective of course.

One minor hiccup with this is the default CI also prevents merging into release branch(es) until CVE is addressed. If you are wondering how you can fix the CVE without merging code, keep wondering, thinking is what puts us above machines.

Getting Kafkaesque

But that's just application code that you, the developer, can control (provided you actually updated the CI to allow merging when there are outstanding vulnerabilities reported). What about the release artifacts? Unless you've been living under a rock for the last 10 years or so you must have had hands-on experience with Kubernetes.

It's likely that your favorite matcha spot downtown runs on a Kubernetes cluster. Don't ask why, but they're likely deployed in Oracle Cloud. You never know how quick you gotta scale to keep up with your customers' thirst.

Kubernetes is a fancy control loop over container runtime. How fancy? About 4 million lines of code ² fancy. Fortunately developers aren't required to figure out how that works. They just need to build and ship a container image. ³

So a developer is then given a "base layer" which for some reason is called "golden image" in every place that's using Red Hat (Venn diagram of corporations using Linux and paying customers of RedHat is a perfect circle). I don't know if many people thought about the name, but pure gold doesn't exist and every piece of gold above molecular size is going to have impurities. Golden images can not have impurities sorry I meant CVEs.

Golden images must be free of CVEs.

Which raises a question -- how does one make such a golden image? Unless it's literally a "FROM scratch" there's going to be a risk of shared libraries containing vulnerabilities.

Well the answer is simple -- it's an individual developer's responsibilitiy. No matter that golden images are provided by platform teams, a developer is still the one who requests the image to be created and thus must ensure the image is clean of icky vulns.

Zooming out and actually taking a look at those vulnerabilities in your base ubuntu, debian, centos, alpine, arch one can see a certain curiosity -- none of those are exploitable unless you have shell access to a running container. Nothing makes my life less meaningful than having to convince a security team member that a vulnerability in perl5 module is not impacting a polars number cruncher.

Not to mention your standard kubernetes setup will happily run all containers as root and control plane will be reachable from /0 range. CISO don't care. CISO don't give a shit, it ain't no CVE.

hAIdes

We're in the depths of hell from which only AI can safely pull us out. AI will concurrently make our software safer and kill us all. But before all that it will make sure to make developers' existence across the world comparable to Dante's nine circles of hell as we are going to be faced with having to respond to nonsensical reports about unreachable parts of the code.

Developers can't dismiss bogus reports because developers are not security people so they don't understand security. AI can produce dozens of vulnerability reports because AI is good and can't make mistakes as long as your prompt includes "don't make mistakes".

As you sip soju at this cute new Korean bar you can't help but wonder if AI is any good while looking at menu slop featuring approximations of food as you're asking Claude to create approximations of software.

Your work email is flooded with CVEs that make no sense because they're authored by LLMs and the people supposed to review them have given up and simply let OpenClaw rip through PRs. Your software engineering heroes work on figuring out how to crack the numbers of their Codex Max subscriptions into triple digits. ⁴

You have to keep the numbers low because cyber security but numbers can only go up because cyber security. Cyber. Cyber. CYBER. YOU HAVE NOT PRESSED THE "REPORT THIS EMAIL" BUTTON YOU ARE A FAILURE. YOU HAVE PRESSED THE "REPORT THIS EMAIL" BUTTON TOO LATE YOU ARE A FAILURE. YOU HAVE PRESSED THE "REPORT THIS EMAIL" BUT IT WAS NOT ACTUALLY AN EMAIL HOW ARE YOU EVEN EMPLOYED YOU ARE A FAILURE.

Cyber Security Theater Awareness October

It's hard to keep a jovial tone when faced with the all-powerful force of CISOs on the hunt for the coveted number.

We have got to stop. Not pause, but stop. There is no security in having zero CVEs. CVE is a signal and we keep confusing it with a metric. We're still running containers as root, exposing our bare APIs and treating ../ as the door to Narnia.

Stop doing the security theater. It hurts.