VEX turns container scanning into queue discipline

The most tiring security dashboard is the one that is technically correct and operationally useless.

You know the one.

The scanner finds 417 vulnerabilities. Some are real. Some are inherited from a base image. Some affect a package that is present but never reachable. Some are already patched in the image you are actually running. Some are awaiting upstream metadata. Some require a rebuild. Some require nothing except another meeting where everyone agrees that red numbers are bad.

Then the dashboard sends the whole pile to developers.

This is how teams learn to ignore security tools.

Not because developers hate security. Most do not. They hate being handed a queue where every item has the same color, the same urgency, and a different amount of truth behind it.

Docker published a useful example of the better direction this month: Docker Hardened Images now work with Aikido scanning using built-in VEX support. In plain English, Docker can publish signed statements about whether a vulnerability actually affects a specific hardened image, and the scanner can use those statements during triage instead of dumping every theoretical CVE into the active queue.

That is not as flashy as "AI fixes your vulnerabilities."

Good.

It is much closer to the work security teams actually need.

the queue is the product

Vulnerability management is usually sold as detection.

Find more things. Scan more layers. Cover more repositories. Add more sources. Detect faster. Shift left. Shift right. Shift everywhere until the diagram needs a bigger slide.

Detection matters, obviously. But once a team has enough detection, the next bottleneck is not finding red badges.

It is deciding which red badge deserves a human.

That is queue design.

A useful vulnerability queue has to answer a few boring questions very well:

does this finding affect the thing we run?
can an attacker reach the vulnerable code path?
has the publisher already fixed it in this image?
is the evidence signed or just inferred?
who owns the next action?
what can safely leave the active queue?

Without those answers, scanners become expensive notification generators. The team spends attention proving that something does not matter. Then, when something does matter, it arrives looking exactly like the previous hundred things that did not.

This is why VEX is interesting.

VEX, the Vulnerability Exploitability eXchange format, is not magic. It is a way for a supplier to say, in a machine-readable form, how a known vulnerability applies to a specific product or artifact. Fixed. Not affected. Under investigation. Affected. With a justification attached.

The important part is not the acronym.

The important part is moving exploitability context from a human exception spreadsheet into the supply chain itself.

containers make this especially painful

Container scanning has a particular talent for making developers feel responsible for things they do not control.

You pick a base image. That image brings an operating system layer, libraries, certificates, package metadata, and sometimes a surprising amount of historical baggage. Your application may use a tiny slice of it. The scanner sees all of it.

Now every vulnerability in that inherited surface becomes your queue item.

Sometimes that is fair. If your production image contains a vulnerable package and an attacker can reach it, you own the risk whether or not you wrote the package.

But sometimes the finding is more subtle. The vulnerable component may not be present in the final image the way the scanner thinks it is. The affected code path may not exist in the hardened build. The image publisher may have already patched the package and published a new digest. A distroless image may not expose the shell or package manager assumptions that older scanning workflows expect.

This is where naive scanning breaks trust.

It says "CVE found."

The engineer has to discover whether that means "drop everything," "rebuild from the latest base," "wait for upstream," "document an exception," or "this is not exploitable here."

Multiply that across services, base images, teams, and release trains, and the security program becomes a queue-management problem wearing a compliance badge.

hardened images are not just smaller images

The current interest in hardened images is easy to explain badly.

"Use smaller images. Smaller is safer."

That is true, but incomplete.

The more useful version is that hardened images are an attempt to put ownership and maintenance around a shared dependency that most application teams cannot reasonably own themselves.

A base image is infrastructure. It is just infrastructure that looks like a line in a Dockerfile.

If a company has hundreds of services all using general-purpose images, every unnecessary package is a future triage item waiting for a CVE feed. Every shell, package manager, library, and utility is another thing that can light up the scanner even if the workload never needed it.

Minimal images reduce that surface. Signed SBOMs explain what is inside. Provenance gives the team something to verify. Maintenance promises matter because the image is not a one-time artifact; it is a dependency stream.

But even that is not enough.

The scanner still needs to understand the publisher's context.

Docker's Aikido integration is useful because it connects those pieces. Aikido can detect the Docker Hardened Image, read the signed SBOM, match components, and apply Docker's OpenVEX statements. If Docker has marked a CVE as fixed or not affected for that image, the scanner can suppress it from the active queue while keeping the evidence available for audit.

That last part matters.

Suppression without evidence is just another way to hide risk.

Suppression with signed, attributable context is queue hygiene.

false positives are not free

Security people sometimes talk about false positives as if they are merely annoying.

They are more expensive than that.

Every bad finding trains the organization. It teaches developers how much attention to give the next alert. It teaches managers how much to trust the dashboard. It teaches security teams whether they need to escalate louder just to be heard.

Enough noise creates a local culture where the first instinct is disbelief.

That is dangerous.

The goal should not be to make dashboards look clean. A clean dashboard can be a lie. The goal is to make the active queue honest.

If a finding is real, keep it visible. If the image is under investigation, say that. If the vulnerability applies and there is no fix yet, keep pressure on the owner. But if the supplier has signed a statement that a specific image digest is not affected, and that statement is part of the artifact metadata, the developer should not have to rediscover that fact manually.

Attention is a scarce production resource.

Security tools spend it.

Good tools spend it carefully.

this is where AI makes the problem sharper

There is also an AI angle here, but not the usual one.

I do not think the interesting story is "AI will fix all CVEs." Maybe agents will help with boring upgrades, and I hope they do. But the first-order effect of AI-assisted development may be more code, more services, more generated dependency choices, and more automated rebuilds.

That means more things entering the supply chain.

It also means more vulnerability discovery. Research tools are getting better. Attackers are getting automation too. CVE volume is not going to become pleasantly human-sized again because we asked nicely.

So the platform has to get better at sorting.

If agents are going to create pull requests for dependency upgrades, container rebuilds, and base image migrations, they need a queue that distinguishes "actually exploitable in this artifact" from "scanner saw a package name somewhere." Otherwise we will automate the wrong work faster.

An agent that fixes noisy findings is not productive.

It is a very expensive way to move red badges around.

The better workflow is more boring:

use curated base images where that makes sense
require SBOMs and signed attestations
let scanners consume VEX automatically
keep suppressed findings auditable
route affected findings to the owning team
measure how often the queue produces useful action

That is not a moonshot.

That is the kind of thing that makes security programs less theatrical.

what i would do first

If I were running a platform team, I would start by treating the vulnerability queue like an engineering interface.

First, I would pick a few important base images and ask what percentage of the active findings are actually actionable by application teams. Not total findings. Actionable findings.

Then I would separate inherited base-image issues from application dependency issues. They have different owners and different fixes.

Then I would require every suppression to have provenance. A signed VEX statement from the image publisher is very different from "Bob clicked ignore until December." Both may be valid in context, but they should not look the same.

I would also make the queue visible to developers in the language of action:

rebuild on a newer digest
change the base image
update this direct dependency
wait for publisher fix
accepted risk until this date
no action: not affected by signed VEX

That sounds simple because it is.

Most useful platform work is simple after you remove the ambiguity.

Finally, I would watch the trend that matters: how much human time does it take to turn a scan into a correct decision?

Not how many CVEs were detected.

Not how red the dashboard looked.

How quickly did the team reach the right action?

That is the operational metric.

the punchline

VEX-aware scanning for Docker Hardened Images is a small integration, but it points at the right future.

Container security does not need more panic. It needs better queues.

Hardened images reduce the amount of unnecessary software we carry into production. SBOMs describe what remains. Signed attestations make publisher knowledge portable. VEX tells scanners whether a known vulnerability actually matters for a specific artifact.

Put together, that changes the job from "stare at a wall of CVEs" to "work the findings that apply."

That is less dramatic than the usual security marketing.

It is also more useful.

The teams that get this right will not be the ones with the biggest vulnerability dashboard. They will be the ones where developers trust the queue enough to act on it, security teams can explain why something is suppressed, and auditors can see the evidence without forcing everyone through archaeology.

Security is not only about finding risk.

It is about preserving enough attention to handle the risk that is real.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

推荐订阅源

DEV Community