Whitepaper

CNAPP & Policy-as-Code Complementary, yet distinctly unique

CNAPPs such as Wiz give security teams deep visibility into cloud risk and runtime threats. But most misconfigurations originate before runtime. This whitepaper shows how Nirmata and Kyverno stop them at the source, so your CNAPP surfaces the findings that matter.

Download the whitepaper Request a demo

9 pages · From the creators of Kyverno

CNAPP answers

“Where are we exposed right now?”

Nirmata answers

“How do we prevent issues and enforce everywhere?”

Different layers, different owners
CNAPP detects and prioritizes for security. Kyverno prevents and enforces for the platform.
Prevention removes whole classes of findings
One policy at admission replaces hundreds of recurring tickets.
Nirmata amplifies CNAPP
Fewer hygiene findings means a higher signal-to-noise ratio for the alerts that matter.

Where each layer acts

Kyverno prevents and enforces while CNAPP detects

Every Kubernetes resource is written, built and tested, admitted to a cluster, and then runs. Kyverno acts on the left, where a bad configuration can still be stopped or corrected. A CNAPP acts on the right, where it sees what is running and how exposed it is.

Nirmata + KyvernoPrevent · Mutate · Enforce

CNAPPDiscover · Prioritize · Detect

Code
IaC, Helm, YAML in Git
CI/CD
Pipeline checks before deploy
Admission
Block, mutate, generate defaults
Runtime
Threats, vulns, exposure
Cloud
Posture, attack paths

Kyverno background scans + audit · stop drift on running resources

Where most misconfigurations originate: before runtimeWhere CNAPP sees them

Feedback loop: a CNAPP finding becomes a Kyverno policy, so the same class of finding is never created again.

Without the loop, every CNAPP finding becomes a ticket, and every ticket becomes a manual fix that the next deployment can reintroduce. With the loop, security identifies a risk once, the platform team codifies it once, and the guardrail applies in every pipeline, cluster and namespace from then on.

The challenge

CNAPP alone is not enough for platform teams

Platform teams give hundreds of developers a self-service platform that is safe by default, without becoming a ticket queue. A list of findings, however well prioritized, does not do that on its own.

Where CNAPPs fall short for platform engineering
Limitation	Why it matters to the platform team
Built for detection and prioritization	Cannot enforce across clusters and pipelines with safe defaults, mutation and generation, or consistent exception workflows.
Enforcement scoped to security	Cannot encode platform standards, automate safe defaults, or manage exceptions the way a policy system does.
Policies cover security only	Does not address the operational, cost and compliance standards across the full developer platform SDLC.
Not developer-facing	Developers still rely on tickets and manual remediation instead of getting feedback in the pipeline.
Weak drift prevention	Identifies drift but does not stop it from recurring with the next deployment.

The result: CNAPP insights become alerts and tickets that must be translated into platform changes by hand, which increases MTTR and operational toil.

In practice

From finding to guardrail

A CNAPP flags workloads across many clusters running privileged containers. Without a policy layer, each becomes a ticket for the owning team, and the finding returns the next time someone copies an old manifest. With Nirmata, it becomes a single guardrail.

01 · CNAPP
Detect
Security sees privileged pods, ranked by exposure and attack path.
02 · Platform
Codify
The platform team adopts a Kyverno ValidatingPolicy, AI-assisted or from the policy library.
03 · Nirmata
Enforce
Audit first, then enforce in CI and at admission. Exceptions are scoped and logged.
04 · Both
Verify
Background scans clear existing violations. The CNAPP finding class trends to zero.

disallow-privileged-containersyaml

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationActions: [Deny]          # start with [Audit], then switch
  evaluation:
    background:
      enabled: true                  # also audits resources already running
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: [v1]
      operations: [CREATE, UPDATE]
      resources: [pods]
  variables:
  - name: allContainers
    expression: >-
      object.spec.containers +
      object.spec.?initContainers.orValue([]) +
      object.spec.?ephemeralContainers.orValue([])
  validations:
  - expression: >-
      variables.allContainers.all(c,
        c.?securityContext.?privileged.orValue(false) == false)
    message: >-
      Privileged mode is not allowed. Remove securityContext.privileged
      or request an exception from the platform team.

A Kyverno ValidatingPolicy in CEL, enforcing the Pod Security Standards (Baseline) control on privileged containers. The developer sees the message in the pipeline or at kubectl apply, not in a ticket a week later.

Operating model

Who does what

Each team keeps doing the job it is best placed to do. Security does not have to become a platform team, and the platform team does not have to become a security operations center.

Security
CISO organization
- Runs the CNAPP and owns risk priorities
- Identifies which finding classes recur most
- Approves high-risk exceptions
Platform
Platform engineering / DevSecOps
- Codifies standards as Kyverno policy
- Rolls out via GitOps, audit before enforce
- Owns safe defaults and exception workflows
Developers
Application teams
- Get inline feedback in CI and at admission
- Inherit safe defaults automatically
- Request scoped exceptions, not tickets

What changes

Before: CNAPP alone	After: CNAPP + Nirmata
One ticket per workload, routed by hand	One policy, applied to every cluster through GitOps
The finding reappears on the next deploy	The violation is blocked before it reaches the cluster
Developers learn about problems days later	Developers see a clear policy message in the pipeline
Exceptions live in email and spreadsheets	Exceptions are scoped, time-bound and auditable
CNAPP queues are full of recurring hygiene issues	CNAPP queues surface the findings that need investigation

Better together

Different layers of the security stack

Concern	CNAPPWiz, Prisma Cloud, Sysdig, etc.	Nirmata + Kyverno
Core job	Discovers cloud risk	Prevents risky configurations from being created, with guardrails and safe defaults
Analysis	Analyzes attack paths	Enforces platform guardrails
At deploy time	Detects runtime exposure after deploy	Blocks violations at admission; mutates and generates safe defaults
Owner	Security team	Platform team
Mode	Detection and investigation	Prevention and enforcement

Unique to the policy layer: GitOps-based policy deployment · open reporting that integrates with platform tools · background scanning · low-latency admission control · mutation and generation for automation.

Nirmata amplifies CNAPP

Nirmata doesn’t compete with CNAPP. It amplifies it.

Because misconfigurations are stopped before production, the CNAPP reports fewer findings tied to drift and policy violations. Security teams see fewer alerts and tickets, platform teams do less manual remediation, and tools like Wiz surface the higher-signal findings that truly warrant investigation.

Download the whitepaper Explore Nirmata Control Hub

Getting started

Four steps to close the loop

01
Pick the recurring findings.
Pull the top configuration-related finding classes from your CNAPP: privileged containers, missing resource limits, images from untrusted registries, host path mounts.
02
Map each one to a policy.
Most have a ready-made Kyverno policy in the open-source library or in Nirmata’s curated policy sets; the rest can be drafted with AI assistance.
03
Roll out in audit mode.
Deploy through GitOps, review policy reports with application teams, and agree on exceptions before anything is blocked.
04
Enforce and measure.
Switch to enforce in CI and at admission, then track the matching CNAPP finding classes over time. They should trend toward zero.

Keep going

Product
Nirmata Control Hub
Policies, exceptions and compliance across every cluster, repo and pipeline.
Product
Nirmata Enterprise for Kyverno
A hardened, supported Kyverno build from the people who created it.
eBook
Zero Trust for Kubernetes with Kyverno
Micro-segmentation, least privilege and image verification, mapped to NIST and CISA.
Free tool
Scan manifests in CI
Run the same policies in your pipeline, before a manifest reaches a cluster.

This is not security vs. platform engineering.

It’s security and platform engineering, working together. See how Nirmata turns your top CNAPP findings into guardrails.

Request a demo Download the whitepaper

CNAPP & Policy-as-Code Complementary, yet distinctly unique

Kyverno prevents and enforces while CNAPP detects

CNAPP alone is not enough for platform teams

From finding to guardrail

Detect

Codify

Enforce

Verify

Who does what

Security

Platform

Developers

What changes

Different layers of the security stack

Nirmata doesn’t compete with CNAPP. It amplifies it.

Four steps to close the loop

Pick the recurring findings.

Map each one to a policy.

Roll out in audit mode.

Enforce and measure.

Keep going

Nirmata Control Hub

Nirmata Enterprise for Kyverno

Zero Trust for Kubernetes with Kyverno

Scan manifests in CI

This is not security vs. platform engineering.