There's a strange ritual playing out inside modern infrastructure teams. Every morning starts the same way: a fresh container image build, a scan, and then the flood. Hundreds of CVEs. Red, orange, yellow. Dashboards light up. Tickets get filed. Auditors nod gravely. And somehow, the actual security posture barely moves.
People dealing with containers at scale are starting to say the quiet part out loud: this isn't security. It's choreography.
The promise of containers was clean isolation, reproducibility, and speed. Instead, many teams ended up inheriting entire Linux distributions they never asked for, stapled inside an image, dragged through scanners that treat every theoretical flaw as an emergency. Alpine, slim, distroless — swap the base, repeat the process, watch the numbers change but never really disappear.
Online discussions around container security keep circling the same frustration. Teams aren't failing because they don't scan. They're failing because scanning became the strategy.
The CVE number that doesn't matter
CVE counts feel objective. They're measurable. They look great in reports. But they've quietly become one of the most misleading signals in container security.
People running real systems will tell you the same thing: a huge percentage of reported CVEs sit in packages that never execute, never listen on a port, and never get called by the application. A vulnerability in a library that exists only to satisfy a dependency chain still shows up as a blocker. Compliance teams don't care if it's reachable. The scanner saw it. The checkbox demands action.
This is where the fatigue sets in. Engineers patch an image, rebuild, rescan, and watch new CVEs appear almost immediately. It feels like chasing a shadow that keeps moving. The problem isn't negligence. It's that the system rewards noise.
One particularly spicy take floating around is that most teams could ignore the vast majority of CVEs and be safer for it. That idea alone is enough to make security Slack channels erupt. But the underlying point lands: not every vulnerability is equal, and pretending they are wastes time and attention.
Base images: the original sin
A lot of this mess starts at the foundation. Standard base images come loaded with tools, libraries, and utilities that made sense for general-purpose servers but have no business living inside production containers.
Shells, package managers, localization files, debugging tools — all useful somewhere, just not inside a runtime that's supposed to do one thing well. Each extra package is another entry in a scanner report. Another false emergency. Another compliance headache.
Some teams try to slim things down manually. Others jump between distros hoping one will magically produce fewer alerts. It rarely works for long.
What does help is starting from images that were never bloated to begin with. Minimal images, hardened images, and scratch-based builds consistently show up in conversations as the first real reduction in noise. Not because they hide vulnerabilities, but because there's simply less there to break.
That's why projects like hardened container images and minimal OS layers keep getting attention. They shift the conversation from "how do we patch faster" to "why is this package here at all?"
Distroless isn't a silver bullet, but it's a direction
Distroless and scratch-based images get evangelized a lot, sometimes recklessly. People online are quick to point out the trade-offs. Debugging becomes harder. You lose shells. Pipelines break if they assumed too much about the runtime environment.
But when teams automate these builds properly, something interesting happens. CVE counts drop dramatically. Not to zero, but close enough that security work becomes deliberate again.
Single-binary containers come up often as the ideal. If your app is a compiled binary, a scratch image gives you exactly one thing to worry about: the code you shipped. That's not always realistic, especially for ecosystems like Node or Python, but the principle scales even when the implementation doesn't.
The real win isn't the image type. It's the mindset shift away from accepting a full OS as collateral damage.
Scanning without prevention is just surveillance
Most container scanners do their job well. Tools like Trivy and Grype aren't the villains here. They surface issues accurately. The problem is that they show up too late.
By the time an image hits a scanner, the damage is already done. The packages are baked in. The remediation path is rebuild-and-hope. Nothing about that loop stops the same problem from happening again tomorrow.
This is why more teams are talking about image hygiene instead of vulnerability management. Build-time decisions matter more than post-build alerts. If the base image starts clean, the scanner becomes a confirmation step instead of a siren.
Some teams go further and wire rebuilds to actual threat intelligence instead of raw CVE feeds. If a vulnerability is known to be exploitable in the wild and relevant to the workload, rebuild. If it's theoretical noise, log it and move on. That approach alone can collapse ticket volume without increasing risk.
SBOMs: painful, necessary, and overdue
Software bills of materials are another sore spot. Everyone agrees they're important. Almost no one enjoys generating or maintaining them.
In practice, SBOMs often end up manual, inconsistent, or detached from the build pipeline. When audits arrive — especially the heavy ones tied to government frameworks — teams scramble to reconstruct what shipped and when. That scramble feels unnecessary in 2026, yet it's still common.
People who've figured this out embed SBOM generation directly into CI/CD. Every image produces one. Automatically. No heroics. No spreadsheets. When auditors ask, the answer already exists.
It's not glamorous work, but it removes an entire class of stress from the process.
The uncomfortable truth about outsourcing
There's a blunt answer that pops up in some discussions: pay someone else.
Managed image providers, hardened image vendors, and curated base image services exist because this problem is real and expensive. For some organizations, buying the solution makes sense. For others, it feels like surrendering control.
The tension shows up fast. Some engineers trust these providers deeply. Others point out that no image is immune to zero-days and that outsourcing doesn't eliminate responsibility. Both sides are right.
What's interesting is that teams using these services often report fewer distractions. Not zero vulnerabilities, but fewer meaningless ones. Fewer rebuilds triggered by noise. More time spent on actual application risk.
That trade-off is becoming harder to ignore.
Kubernetes didn't cause this, but it amplified it
None of this exists in a vacuum. Orchestration platforms like Kubernetes made containers unavoidable. Scale magnified every inefficiency.
When you're running hundreds or thousands of images, manual fixes don't scale. Neither does reactive security. The platform didn't create the CVE problem, but it made pretending less viable.
That's why so many of these conversations happen in Kubernetes-heavy circles. The pain shows up there first.
Security theater is comfortable. Real security is quieter.
Chasing CVEs feels productive. It generates activity. It creates artifacts. It satisfies checklists. But it often fails to reduce actual risk in a meaningful way.
The teams making progress aren't louder. They aren't posting screenshots of empty dashboards. They're quietly changing how images are built, what gets included, and when rebuilding happens.
They accept that zero CVEs is a fantasy. They aim for relevance instead. Exploitability over raw counts. Prevention over reaction.
That shift doesn't make for flashy metrics, but it does make for fewer incidents and calmer audits.
And maybe that's the real controversy here. Container security didn't get harder because attackers got smarter. It got harder because we optimized for the wrong signals and kept going long after it stopped helping.
If the industry wants fewer breaches and fewer burned-out engineers, it might be time to admit that scanning everything and fixing nothing meaningful was never the plan. It was just the easiest thing to measure.