Skip to content

Vulnerability Scanner

The Vulnerability Scanner tab (sidebar: Vulnerability Scanner, shield icon) surfaces container image vulnerabilities (CVEs) and Kubernetes workload misconfigurations, rolled up into a cluster posture score. The underlying capability is container scanning — a non-AI feature that works with AI disabled or entirely absent.

What it does

  • Image vulnerability scanning (CVEs) — severity, affected package, installed vs. fixed version, fix-availability
  • Workload misconfiguration checks — privileged containers, runAsRoot, missing resource limits, dangerous capabilities, and other common Kubernetes hardening gaps
  • Posture dashboard — an A–F letter grade and a 0–100 score, a severity breakdown (critical/high/medium/low), and a health trend over past scans
  • Per-workload drill-down — expand any workload to see its full CVE list and misconfiguration findings, filterable by namespace and severity

Engine: Trivy — one tool covers both image CVE scanning and Kubernetes config-audit checks.

Scan-source adapter — "already have Trivy? Use it."

KubeManta detects whether trivy-operator is already installed in the cluster and, if so, reads its existing reports instead of scanning again:

  • Operator present (VulnerabilityReport / ConfigAuditReport custom resources found) — KubeManta reads those reports directly. This is read-only against the operator's own database: zero additional egress, no duplicate image pulls, and it respects whatever offline/air-gapped CVE database the operator was configured with.
  • Operator absent — an admin can trigger an on-demand self-scan: KubeManta spawns an ephemeral Trivy Kubernetes Job that scans the target namespace's running workloads for both image CVEs and misconfigurations in one pass, then parses the results back into the same internal schema.

Both paths write to the same tables, so the Vulnerability Scanner tab shows one unified view regardless of which source produced a finding — the source badge on the tab (and on the drill-down table) tells you which one is in play.

Choosing your scan source (BYO scanner)

The scan source is admin-selectable at runtime in the Vulnerability Scanner → Scanner tab (persisted in scanner_source; this runtime setting overrides the security.scanning.mode Helm seed). Choosing a source is Free — you should never have to pay to point KubeManta at your own scanner.

Source Behavior
auto Defers to the Helm seed. An admin can trigger a self-scan on demand.
operator BYO. KubeManta deploys no Trivy and only reads your trivy-operator reports. Self-scan is hard-disabled (409).
self KubeManta deploys its own Trivy Kubernetes Job.
trivy_server Experimental. The self-scan Job runs trivy k8s --server <url> against your existing Trivy server (no local CVE-DB pull). --server support on trivy k8s varies by Trivy version; an unsupported build surfaces as a normal scan failure with the Trivy error in the Job log tail.

Set the source with PUT /security/scanner/source (admin, Free). GET /security/scanner reports the current source, effective mode, and every KubeManta-deployed scan resource.

The Scanner tab also manages the platform's own scan Jobs: list recent self-scan Jobs (GET /security/scan/jobs), read a Job's _scrub-redacted Trivy logs (…/jobs/{id}/logs), retry a failed run, or delete one — all admin-gated.

Scheduled recurring scans

Recurring self-scans are configured at runtime (GET/PUT /security/scan-schedule, admin): {enabled, interval_hours, namespaces, source}. A background scheduler runs the scan when due, so a manual scan and a scheduled one never stack. Configuring the schedule is Free; the scan execution stays Pro (scanning_selfscan) and never runs when the effective source is operator.

KubeManta's footprint is labelled and removable

Everything KubeManta deploys for scanning is name-prefixed kubemanta-scan-<run> and labelled app.kubernetes.io/managed-by: kubemanta + app.kubernetes.io/component: scanner (on both the Job and its pod template), so:

kubectl get jobs -A -l app.kubernetes.io/managed-by=kubemanta,app.kubernetes.io/component=scanner

shows KubeManta's entire scanner footprint at a glance. To rely on your own scanner instead, one click removes it all — DELETE /security/scanner (admin + Expert Mode, Free) deletes every label-matching Job cluster-wide via expert-exec and reconciles any still-running scan runs. It does not change the source, so switch the source to operator first (via the source PUT) so a later scan doesn't redeploy Trivy.

Posture grade, history, diff & export

  • A–F grade — capped by the worst unfixed severity band, then adjusted by finding density over the workloads covered and by fixable-weighting (a fixable finding is treated as lighter than an unfixed one). The denominator is distinct workloads covered, so one bad pod can't drag a large clean fleet to F. The reason for the cap is shown (grade_cap_reason).
  • Health trend — a per-scan 0–100 health score plotted as a sparkline (higher = healthier).
  • Scan history & diff — GET /security/history lists past runs; GET /security/scan/diff shows what changed since the previous run of the same scope (new vs fixed vulns and misconfigs).
  • Findings filters & export — fixable-only, group-by-image, free-text search, and CSV/JSON export honoring the active filters.
  • Risk exclusions — Exclude a CVE/misconfig with a required reason; an exclusion drops the finding from both the grade and the default findings view, and it's listed in the Exclusions sub-tab (admin-only). Basic exclusion (reason, no expiry) plus list/revoke is Free for admins; only the auto-reactivating expiry policy (expires_at) is Pro.

How to get there

Click Vulnerability Scanner in the sidebar. The tab opens on the posture dashboard:

  • Source badge — operator, self-scan, or (if nothing has scanned yet and no operator is present) a setup card prompting you to either install trivy-operator or run a self-scan (Pro).
  • Posture score + severity breakdown + trend — the cluster-wide score, current open findings by severity, and how that's moved across past scans.
  • Scan now — admin-only button that triggers an on-demand self-scan of the current namespace. Requires Expert Mode and a Pro license; Viewers see "Scan now (Admin only)" and Free-tier accounts see the Pro upsell instead of a working button.
  • Below the summary, a per-namespace/workload table — image, open finding counts by severity, and an expandable row showing the full CVE list (CVE ID, severity, package, installed → fixed version, fix-available) plus misconfiguration checks (check ID, severity, message). Filter by namespace or severity.

Tiering

  • Free — read any existing trivy-operator reports, and the full posture dashboard (score, severity breakdown, trend, drill-down) built from whatever has already been scanned. Nothing here requires a license.
  • Pro — on-demand self-scan (POST /security/scan) when no operator is installed, gated behind Admin role, Expert Mode, and a Pro license.

Scheduled recurring scans are configurable by any admin (execution is Pro — see above), and the Alert Rules Engine includes a scan_severity_threshold condition that fires on the same deduped, suppression-filtered findings the Vulnerability Scanner tab shows — so you can alert when findings cross a severity threshold. A pre-deploy "apply-gate" that blocks risky images at the Resource Builder's Apply step remains a planned follow-up.

Requirements

  • Self-scan requires Expert Mode enabled (expertMode.enabled=true) — the scan Job is launched via the same expert-exec path used for other privileged writes.
  • Self-scan needs egress to pull the Trivy vulnerability database (unless you're consuming an already-installed operator, which uses its own database). An offline/pre-mirrored CVE database option is a planned fast-follow for air-gapped clusters.
  • Private-registry images aren't yet supported by the self-scan path (Trivy pulls layers itself, independent of the workload's imagePullSecrets) — public/anonymous-pull images work today. Use the operator-reader path if your images are in a private registry and you need scanning now.

Enabling it (Helm)

Container scanning is opt-in — a vanilla install doesn't broaden the reader ClusterRole until you turn it on:

security:
  scanning:
    enabled: true      # grants read access to trivy-operator CRDs + CRD discovery
    mode: auto          # auto | operator | self
    selfScan:
      image: "aquasec/trivy:0.56.2"
      waitSecs: 60
      resources:
        requests: { cpu: "250m", memory: "256Mi" }
        limits:   { cpu: "1",    memory: "1Gi" }
  • mode: auto (default) — an admin can trigger a self-scan on demand regardless of whether trivy-operator is installed.
  • mode: operator — hard-disables self-scan; trivy-operator's reports are treated as the sole source of truth.
  • mode: self — KubeManta deploys its own prefixed Trivy Job.

mode here is only the seed. An admin can override it at runtime in Vulnerability Scanner → Scanner (the stored scanner_source then wins), which additionally supports the experimental trivy_server source. See Choosing your scan source above.

Self-scan additionally requires rbac.allowWrites=true and expertMode.enabled=true (the Job itself is created via expert-exec's privileged path, not the reader ServiceAccount).

Screenshots coming

A walkthrough of the posture dashboard, source badge states, and the drill-down table will be added here in a follow-up pass (Phase 2).