CI scanning does not close the loop
Most teams already scan images in the pipeline. That is necessary. It is not sufficient.
Between build and runtime there is room for a different image to reach the cluster: a reused tag, a manual deploy, an environment that skips the same gate, a secondary registry. If the only barrier lives in CI, the Kubernetes API server still accepts any Pod that matches the manifest.
The useful question is not whether you scan. It is when you can reject an image with vulnerability evidence and an explicit policy.
What admission control actually decides
A ValidatingAdmissionWebhook runs when the API server evaluates create or update. If the webhook returns allowed: false, the object does not enter. You do not need operators to read a report after the fact.
That turns vulnerability posture from a report into an operational decision: allow, warn or audit under defined rules.
What KATANA does
KATANA is our open-source control plane for that decision. Before a Pod lands, it queries a configured scan backend (JFrog Xray and/or Amazon Inspector on ECR), applies policies (deny, warn, audit), records detections and can enforce the outcome through the native Kubernetes webhook.
In practice:
- policy lives in SQLite or in
ImagePolicyCRDs - the evaluator derives severity and applies namespace exceptions when configured
- dry-run mode shows impact without blocking deploys
- there is a per-cluster UI and a fleet view with Prometheus metrics across environments
The API server remains the component that blocks. KATANA supplies evaluation and evidence.
Why dry-run matters
Turning on enforcement on day one usually creates political friction, not technical doubt. Platform and product teams need to see what would have been blocked, with which message and on which image, before a rule is hardened.
Dry-run turns “this will break production” into a concrete list of findings and exceptions. After that, deny is a documented decision rather than an opinion.
Limits worth stating
KATANA does not replace the scanner. It depends on the quality and coverage of the backend (Xray, Inspector or other integrations). It also does not, by itself, solve signed supply chain, runtime detection or network posture.
Its job is narrow: at admission time, does this image meet the policy the organisation has defined?
How we use it with clients
In DevSecOps and Kubernetes platform work we start from that question. We assess what is scanned today, what reaches the cluster without the same control, and where an admission gate adds more than another report.
KATANA is our own tooling. We make it available to clients when the problem is closing the gap between scanning and runtime.
Repository: github.com/zpol/katana. To review image admission on your platform, book a meeting or see DevSecOps & Automation.