Cloud Edition
Every change to your cluster passes through Kyverno.
Source: N4K release notes, v1.13–v1.18, Jan–Sep 2026
Kyverno releases a new minor version about every three months, and community patches move with it. Fleets under change control upgrade slower than that.
Patches go to the latest minor release only. Kyverno's own policy limits them to critical bugs and critical-to-high CVEs, for about three months. After that, your options are an unplanned upgrade or running unpatched.
Each release is supported for 18 months. Kyverno engine fixes and dependency CVEs are backported to every supported branch, so a version you deployed a year ago is still a patched version.
When the apiCall SSRF advisory landed, upstream only patched the latest release, v1.19. Every supported N4K release got the fix the same day.
context.apiCall.service| You run | Upstream Kyverno | Nirmata Enterprise |
|---|---|---|
| v1.18 | ✕ No patch | ✓ Fixed Sep 5 |
| v1.17 | ✕ No patch | ✓ Fixed Sep 5 |
| v1.16 | ✕ No patch | ✓ Fixed Sep 5 |
| v1.15 | ✕ No patch | ✓ Fixed Sep 5 |
| v1.14 | ✕ No patch | ✓ Fixed Sep 5 |
Pick your Kyverno version to see its upstream status and what Nirmata has fixed on that branch.
Not sure? kubectl get deploy -n kyverno -o jsonpath='{..image}'
Kyverno engine CVEs, Go toolchain issues and dependency advisories, including Sigstore, grpc and x/crypto, are triaged against every supported N4K release, not just the latest.
Dependency bumps are the easy part. Engine fixes, like the apiCall SSRF guard, have to be reworked for each older branch by the people who wrote the engine.
Each fix ships as a new N4K build for your branch, such as v1.16.3-n4k.nirmata.16, tested against the Kubernetes versions it supports, with every CVE listed in the release notes.
Same Kyverno, same policies, no fork. The difference is who patches it, and for how long.
| Upstream Kyverno | Nirmata Enterprise | |
|---|---|---|
| Releases that get CVE fixes | Latest minor only | Every supported release |
| Patch window per release | About 3 months | 18 months |
| Kyverno engine fixes backported to older releases | No | Yes, by the maintainers |
| Kubernetes compatibility testing | Current Kubernetes versions only | Tested for each supported release |
| Support | Community Slack and GitHub | 24/7 enterprise support with SLAs for CVEs |
| Upgrade help | Release notes | Planned upgrades, including the 1.20 CEL migration |
| Policies and APIs | Kyverno | Same Kyverno, OSS-compatible |
“The onboarding process for Nirmata is very easy. It's very quick, well-documented, and supported by a well-trained Nirmata team. It took us less than two hours to upgrade.”Kuldeep Tomar, Director Infosec, Games24x7
Scales with your cluster footprint. Tell us what you run and we'll put together a quote.
No. It's an OSS-compatible distribution of Kyverno. Your policies, CRDs and tooling work unchanged. The difference is the release branches we keep patching after upstream moves on.
Not if your version is within its N4K support window. You can move to the patched N4K build for the version you already run, then plan upgrades on your own change-control cycle. Check your version.
Both Kyverno engine vulnerabilities (for example the 2026 apiCall and CEL http SSRF fixes) and CVEs in dependencies and the Go toolchain. Every fix is listed in the release notes.
Rebuilding an image clears CVEs in base packages. It can't change Kyverno's own code. Engine vulnerabilities on older branches need a code backport, and that is maintainer work.
Plans start at $14,800 per year and scale with your cluster footprint. Every plan includes backports, 24/7 support and upgrade planning.
Get patched builds for the version you run today, from the team that created Kyverno.