Skip to content

Trivy (Container Scanning)

Enable container image vulnerability scanning and workload misconfiguration detection. You can bring your own Trivy scanner or let KubeManta run scans on demand.

What it gives you

  • CVE detection — container image vulnerabilities with CVSS v3.x scores (each with its version, source and vector) and fix availability, listed one row per CVE by default
  • Misconfiguration detection — workload security misconfigs (e.g., insecure capabilities, root containers)
  • Posture score — A–F grade + trend over time
  • Findings export — CSV, JSON, Markdown and HTML export for compliance reporting
  • Risk acceptance — exclude accepted findings with a reason (Free, for admins); time-boxed acceptance with an expiry is Pro

Tier: Free (read reports, risk acceptance with a reason); Pro (self-scan trigger, risk acceptance with an expiry)

Prerequisites

Choose one scan source:

Option A: Bring your own scanner (trivy-operator)

If you already run trivy-operator in your cluster:

  1. trivy-operator installed — the operator creates VulnerabilityReport and ConfigAuditReport custom resources as it scans your images.
  2. Nothing else to do — KubeManta auto-detects the operator and reads its reports. You're set.

trivy-operator does not say by default which source (NVD, Red Hat, GitHub) a CVSS score came from, so KubeManta shows the source as not stated. To have it named, configure the operator to include each vendor's scores: trivy.additionalVulnerabilityReportFields containing CVSS.

This is the Free, recommended path if you already have the operator.

Option B: KubeManta self-scan (built-in Trivy Job)

If you don't have trivy-operator and want KubeManta to scan on demand:

  1. Pro license — required to trigger scans (viewing reports is Free).
  2. Expert mode enabled — the Helm value expertMode.enabled=true allows KubeManta to create privileged scan Jobs.
  3. Network path — the scan Job downloads the Trivy databases at scan time (from mirror.gcr.io, falling back to ghcr.io), and your nodes pull the scanner image (aquasec/trivy) from Docker Hub. Ensure those are reachable — the full list is on Network Egress. On a sealed network, mirror them instead — see Air-gapped install.

There is no Trivy-server option

trivy k8s has no client/server mode — only trivy image does — so there is nothing for KubeManta to point at. If you want KubeManta to deploy no scanner of its own, use Option A (trivy-operator), which is the supported bring-your-own path.

Configure in KubeManta

For trivy-operator (auto-detected)

No configuration needed. If the operator is installed and discoverable, KubeManta reads its reports automatically.

Verify: 1. In the sidebar, click Vulnerability Scanner (shield icon). 2. Open the Settings sub-tab. 3. You should see Source: Operator and a count of deployed scan resources.

If you want to switch to self-scan later, see below.

For self-scan

  1. Enable Expert Mode (only needed once, at install or upgrade). Scanning itself is on by default, so no flag is required to read reports or trigger a scan — but the built-in self-scan runs through the privileged expert-exec path, so it additionally needs Expert Mode (and a Pro license):
helm upgrade kubemanta oci://registry.kubemanta.com/kubemanta/charts/stable/kubemanta \
  --version CHART_VERSION \
  -n kubemanta-system --reset-then-reuse-values \
  --set expertMode.enabled=true

  1. In KubeManta, navigate to Vulnerability Scanner → Settings.

  2. Under Scan source, pick one:

  3. KubeManta built-in scanner — KubeManta spawns a Trivy Job per scan. Requires Pro + expert mode.

  4. Use my trivy-operator instead — KubeManta reads the operator's reports (Free, no Pro needed).

  5. Click Save source if you changed the source.

Which version?

Replace CHART_VERSION with the release you are installing. The newest is at the top of the Changelog, or read it from the registry once you are logged in:

helm show chart oci://registry.kubemanta.com/kubemanta/charts/stable/kubemanta | grep '^version:'

Always pin it. An unpinned install resolves to whatever stable points at today, which is not necessarily the release you tested against.

Verify

Check that scanning is enabled

  1. Click Vulnerability Scanner in the sidebar (shield icon).
  2. Open the Settings sub-tab.
  3. You should see:
  4. Source: one of Operator, Self-scan, or None
  5. Status: green "ready" or orange "not configured yet"

Trigger a scan (self-scan only)

If you chose self-scan:

  1. In the Settings tab, click the Scan now button (appears only for admins).
  2. A scan Job is created. You'll see Status: Running.
  3. Wait for it to complete, visible in real time: usually one to three minutes for a small namespace (the first scan downloads the CVE database); large namespaces take much longer.
  4. Once done, check the Findings sub-tab to see CVEs and misconfigs.

Expected states

State Meaning Next step
Source: None No scanner detected — trivy-operator isn't installed and self-scan isn't configured (or scanning was turned off) Install trivy-operator, or configure self-scan (Pro + Expert Mode), then pick a source
Source: Operator trivy-operator is running (its Deployment has a ready replica) and KubeManta is reading its reports No action needed; wait for a scan to run
Badge: "also showing a stopped trivy-operator's reports, newest …" trivy-operator is installed but not running. Under the default auto mode built-in scan is the source, and the stopped operator's reports are still shown with the age of the newest Scale trivy-operator back up, or switch the source to built-in scan if you removed it on purpose
"trivy-operator status could not be checked" (Scanner tab: "status unknown") KubeManta was refused, or timed out, listing Deployments. An operator it cannot check is not counted as running See trivy-operator stopped or not checked
Source: Self-scan, Status: Ready Configured and ready. Scan on demand. Click "Scan now" to trigger a scan (or wait for scheduled scans if configured elsewhere)
Findings tab shows CVEs/misconfigs Success! Review findings, optionally exclude accepted ones

Troubleshooting

"Source: None" in the Scanner tab

Has scanning been turned off? It's on by default, so this only applies if someone set security.scanning.enabled=false:

kubectl get deploy -n kubemanta-system kubemanta-agent -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="SECURITY_SCANNING_ENABLED")].value}'

If that prints false, drop the --set security.scanning.enabled=false from your install (or set it back to true) and re-run the Helm upgrade.

Is trivy-operator installed? Check if the CRD exists:

kubectl get crd | grep vulnerabilityreports
# or
kubectl api-resources | grep VulnerabilityReport

If not, KubeManta falls back to self-scan mode (if Pro licensed).

trivy-operator stopped, or could not be checked

KubeManta counts trivy-operator as running only when its Deployment has at least one ready replica. It finds the Deployment by the label the official chart and static manifest both set, app.kubernetes.io/name=trivy-operator, or else by the default name trivy-operator. Check it from the cluster side:

kubectl get deploy -A -l app.kubernetes.io/name=trivy-operator

It should list the operator with a ready replica. Scaling it to zero or uninstalling it leaves its reports in the cluster, and KubeManta keeps showing them with the age of the newest, so frozen findings are visibly frozen. Under auto mode built-in scan becomes the source as soon as no running operator is seen; under operator mode nothing refreshes those findings until the operator runs again. Changes show up within about a minute.

"Could not be checked" means KubeManta's reader ServiceAccount was refused or timed out listing Deployments. Confirm it may list them cluster-wide:

kubectl auth can-i list deployments -A \
  --as=system:serviceaccount:<release-namespace>:<reader-service-account>

Scan is stuck in "Running"

Is the scan Job still there? Check:

kubectl get jobs -n kubemanta-system -l app.kubernetes.io/managed-by=kubemanta

If a job is running and taking >60 seconds, it's still downloading the Trivy database or scanning your images. This is normal for large clusters on first run.

Is the scan Job failing? Check logs:

kubectl logs -n kubemanta-system -l app.kubernetes.io/managed-by=kubemanta --tail=50

If the Job pod has ImagePullBackOff, KubeManta couldn't pull the Trivy image. Check your image pull secrets and network egress to the registry.

"A scan of … is running" when you start a scan

One built-in scan runs at a time across the whole install. Starting another, for any namespace, is refused with the scan already running: its namespace, who started it, when, and how many images it has covered. The scan console attaches to that scan, so every admin watches the same one. Through the API, POST /security/scan answers 409 with the same details. A scheduled scan is not refused: it waits its turn and its namespaces run one after another.

Wait for the running scan to finish, or cancel it from the scan console; any admin can, and the run records who did. To run several scans at once on a cluster sized for it, set security.scanning.selfScan.maxConcurrentScans and security.scanning.selfScan.cache.enabled=false; with the CVE-database cache on, the limit stays at one. See Helm values: Container scanning.

"Scan now" button is disabled or shows "Admin only"

Are you an admin? Only admins can trigger scans. If you're a viewer, ask an admin to trigger the scan.

Do you have a Pro license? Self-scan requires Pro. If you're on Free, switch to operator source or upgrade.

Is expertMode.enabled=true? Self-scan needs expert mode. Check:

kubectl get deploy -n kubemanta-system kubemanta-expert-exec

If it is not found, Expert Mode is off.

If not set, the "Scan now" button is disabled (read-only mode is the default for safety).

Findings are empty or "not found"

Did a scan actually run? Check the History sub-tab — if there are no scan runs, no scans have completed yet. Trigger one with "Scan now" and wait.

Is trivy-operator configured correctly? Verify the operator's reports exist:

kubectl get vulnerabilityreports -A | head

If nothing appears, the operator may not have scanned any images yet (can take a few minutes after install).