Security Center
Know which findings need your attention.
See vulnerability findings across the fleet, understand their exposure and exploitation context, and follow the decision from finding to remediation.
The problem
A scanner observes. A team has to decide.
Scanning is solved and mostly free. What is missing is everything that happens after the report lands.
The same triage, nightly
You judge an unfixable CVE in a base image, and the next scan presents it again, unchanged, to whoever opens the report next.
Counted once per cluster
One CVE in one shared base image becomes a hundred rows, so the total tells you about your image sprawl rather than your risk.
Severity is not priority
A fixable high in something you shipped yesterday usually outranks an unfixable critical in a base image you do not control.
Decisions
What a finding has to become.
Acknowledging a finding means you have read it, and it stays actionable. Only an accepted risk leaves the count, and only with all four of these attached.
- 01
A reason, written down
Accepting a risk requires a written justification captured at the moment you had the context, not reconstructed from a Slack thread four months later.
- 02
A review date that expires
Every acceptance carries a deadline of at most a year, and can expire itself automatically the moment a fixed version becomes available.
- 03
A scope that outlives the pod
Ankra deploys your add-ons, so it can attribute a finding to the add-on that introduced it. Accept the risk once and it applies across the organisation, including clusters you create later.
- 04
A preview before you commit
Before a policy is written you see how many occurrences, findings, and clusters it touches, what it deliberately excludes, and what your actionable count becomes.
The surface
Six views over one fleet.
Organisation-wide by default, with the same detail available per cluster.
Where the fleet stands
- Overview
- The fleet scorecard: what share of scanned clusters carry no actionable critical or high findings, a plain-language verdict, and the remediation candidates ranked by severity, fix availability, and reach.
- Clusters
- Per-cluster posture and scanner freshness, so a cluster that stopped reporting three weeks ago cannot quietly look clean.
What needs fixing
- Findings
- Every logical finding across the organisation, deduplicated across clusters and workloads. Filter by status, severity, cluster, add-on, namespace, or whether a fix exists at all.
- Network Exposure
- NetworkPolicy over-privilege scored for ingress and egress: unprotected workloads, rules broad enough to admit everything, and what to tighten first.
What you decided, and the proof
- Policies
- The accepted-risk decisions you have made, with their review dates and lifecycle, alongside Kyverno pod-security violations per cluster.
- Compliance
- CIS and NSA/CISA benchmark pass rates per cluster, plus Trivy configuration audit, exportable as an evidence report.
Blast radius
The axis a CVE count cannot see.
Severity describes how bad a vulnerability is in the abstract. It says nothing about what an attacker reaches from the pod that has it.
Scored, not guessed
Each cluster gets separate ingress and egress over-privilege scores, counting the workloads no policy covers and the rules broad enough to admit everything.
Named and fixable
Every finding names the namespace, the workload, and the offending rule, and says what to tighten, so it maps onto a change rather than a worry.
Evidence
Compliance you can hand to an auditor.
Benchmark pass rates per cluster per framework, plus an export that carries the decisions rather than just the numbers.
Benchmarks and config audit
CIS Kubernetes and NSA/CISA results as pass rates per cluster, with Trivy's configuration audit as a second axis. Frameworks are discovered from what Trivy publishes rather than hardcoded.
The evidence report
CSV or JSON over a date window: posture history per cluster, every disposition with its reason and review date and author, an audit summary, benchmark results, and attestations covering MFA, SOPS, and baseline coverage.
Getting started
One action to switch it on.
The Security Center reads from tooling that runs in your cluster. Installing it is a single action, and nothing starts blocking workloads on its own.
- 01
Install the baseline
One click installs pinned Trivy Operator and Kyverno with the pod-security baseline policy set on the cluster you choose.
- 02
Audit before enforce
Kyverno arrives in audit mode, so violations surface without blocking anything. Switching a cluster to enforce is a separate, deliberate step.
- 03
Scoped access
Reading, acknowledging, and writing accepted-risk policies are three separate permissions, and the evidence export additionally requires audit access.
Security review
Reviewing Ankra for your organisation? Talk to security.
Send your questionnaire or ask how a control works. The trust centre holds the rest.
What the trust centre covers.
- Compliance status
- Data handling and sub-processors
- Platform security controls