Security and compliance
Four finding lenses plus a runtime feed, fed by Trivy, Kyverno and Falco. What each one ingests, what becomes a finding, and where detection stops.
KubeBolt does not scan your cluster itself. It reads the scanners you already run — or install in one command — normalizes their output onto one severity scale, and gives it a lifecycle: a stable identity across rollouts, a first-seen clock, and resolution when the problem stops being observed.
Scope, plainly. This is detection and posture, not automatic remediation. KubeBolt tells you what is wrong, which workload owns it, and what the remedy is. It does not patch images, rewrite manifests, or enforce policy — enforcement lives in Kyverno, patching lives in your pipeline.
The four lenses
Security & Compliance splits findings into four lenses. Each is a different question with a different fix, so they are never summed into one ranked list.
| Lens | The question | Fed by |
|---|---|---|
| Vulnerabilities | What CVEs and exposed secrets are in what we run? | Trivy |
| Configuration | What is misconfigured or violates policy? | Trivy config-audit, Kyverno / Gatekeeper |
| Permissions | What RBAC is too broad? | Trivy |
| Compliance | Which CIS controls are failing? | Trivy |
The list you act on is workloads, not findings. Hundreds of findings usually collapse to a couple of dozen workloads, and a workload is what actually gets changed. The finding-level counts stay on the card row above it: open criticals, the workloads affected (roles, on the Permissions lens), the share of findings with a published fix, and runtime threats in the last 24 hours. The criticals and runtime-threats cards light red when they are above zero.
The runtime feed
Runtime is the fifth tab and is not a lens. It is a stream of Falco events, stored separately from findings, and it behaves differently on purpose:
- Events are point in time. They age out of the feed rather than being resolved. There is no “resolved” button in the detail view, because there is no state to close and a button that lied about that would be worse than nothing.
- Falco pushes; Trivy and Kyverno are pulled. That is the whole reason Falco needs a token and an endpoint while the other two need neither.
Kobi reads all of this too: get_findings for the posture, get_finding_detail
to re-read one finding live from the scanner, get_finding_workloads to get
them grouped by workload with exposed secrets first, and get_runtime_events
for what Falco saw processes actually do. See Kobi Copilot.
What becomes a finding
Every scanner reports more than is worth acting on. The gates are deliberate and differ per source:
| Source | Ingested | Dropped |
|---|---|---|
| Trivy CVEs | CRITICAL, HIGH | MEDIUM, LOW — thousands of rows nobody finishes reading |
| Trivy config audit | CRITICAL, HIGH, MEDIUM | LOW — mostly “runs with a high UID” and “no CPU/memory limit”, which KubeBolt already raises as a capacity insight |
| Trivy RBAC assessment | CRITICAL, HIGH, MEDIUM | LOW |
| Trivy exposed secrets | Every severity — no gate | Nothing. The matched text is never stored: the finding says where, never what |
| Trivy compliance | Failing controls | Passing controls produce nothing |
| Kyverno / Gatekeeper | result: fail | pass, skip, warn, and error (an engine hiccup is not the workload’s fault) |
Note the asymmetry between the CVE gate and the policy gate. A CVE with no
severity label is dropped; a policy violation with no severity label
becomes a medium finding. A policy is not a fact of nature — someone wrote it
on purpose, so a failure matters even when nobody said how much.
Exposed secrets are counted apart from CVEs: a credential baked into an image is not a dependency to upgrade.
Wiring the sources
Three pages, one each:
- Trivy — CVEs, misconfiguration, RBAC posture and CIS. Feeds three of the four lenses.
- Kyverno and Gatekeeper — your own policies. KubeBolt
reads
wgpolicyk8s.ioPolicyReports, so anything that writes them works. - Falco — runtime syscall events. The only source that needs a token.
Trivy and Kyverno are detected by label, with a namespace fallback, and their status appears as a card on the page: not installed, degraded, or contributing. That attribution row sits above the tabs, because “which of my scanners are reporting” does not change when you switch lens.
Retention
Security findings and runtime events share one horizon. In the open-source
edition it is KUBEBOLT_FINDINGS_RETENTION_HORIZON, default 720h (30 days)
— see Environment variables. Cleanup rides the
hourly retention pass.
Scanner sources are swept every 10 minutes; Falco events arrive as Falco pushes them.
On Cloud the window is a plan dimension:
| Plan | Retention |
|---|---|
| Free | 15 days |
| Team | 30 days |
| Business | 90 days |
| Enterprise | 365 days |
What is not here yet
- No automatic remediation. Kobi can propose and execute workload actions under governance, but nothing in the Security page acts on a finding by itself.
- Runtime events cannot be resolved or acknowledged — see above.
- Falco tuning happens in Falco. Silencing a noisy rule is a
customRuleschange at the source, not a KubeBolt setting. The source stays authoritative.