javv

Kubernetes-runtime-native container-vulnerability triage.
Discovers what's actually running in your clusters, scans it with Trivy and Grype side by side, and gives every vulnerability its own fully-audited triage lifecycle: an immutable record of who changed what, and when. Plus rich dashboards, whole-app time-travel, and one-click CSV. Without the weight of a full ASPM platform. An AI agent can also read and triage the findings through the MCP endpoint.

Docs · Repo map · Run the stack · API · Configuration · Architecture

_{The fleet · one cluster's findings · a single CVE, its per-scanner evidence and its own audit trail · the risk-accept queue · the journal. Real data from a two-cluster dev environment.}

Why

Vulnerability tooling splits into two worlds: triage tools (DefectDojo, Dependency-Track) with
rigid reporting, and log-analytics dashboards with no concept of auditing a finding. JAVV fills
the seam: a real triage lifecycle and exploratory dashboards, over what's live in your clusters.

Three things it does differently:

• Scans what's running, not a registry. JAVV discovers the images actually deployed in your
  clusters and scans those: the vulnerabilities you're exposed to right now, not a catalogue.
• Two scanners, never merged. Trivy and Grype run per-image and are kept side by side. JAVV
  never dedupes a CVE across scanners. Instead it flags where they disagree, so you see the
  blind spots a single-scanner tool hides.
• Every vulnerability is auditable. Each finding carries its own immutable history: a six-state
  triage lifecycle (+ VEX and risk-accept), every decision journaled with who, what, and when, plus
  whole-app time-travel that rewinds every screen to any point in the past. Most tools have no
  concept of auditing a single finding; here it's the core.

Features

• Runtime discovery: scan the images live in your clusters. Choose what to scan by namespace, image and workload kind.
• Per-scanner, side by side: Trivy + Grype kept separate; disagreement is surfaced, never merged away.
• Per-finding audit trail: every vulnerability keeps its own immutable history, with each triage action, decision, and note journaled by who, what, and when, replayed in causal-revision order.
• Triage lifecycle: a six-state machine (five operator-settable; stale is set by the staleness sweep), VEX export (OpenVEX / CycloneDX), risk-accept, decisions that apply across scanners.
• Whole-app time-travel: a global picker rewinds every screen to any point ≤ now, reconstructed from the append logs.
• Append-only audit log: immutable, per-finding and per-user, exportable to CSV.
• Multi-tenant + RBAC: isolated by immutable cluster_id; capability-based roles, local auth + bootstrap admin.
• Server-side everything: every count and page comes from an OpenSearch aggregation, never computed on the client.
• Screens & exports: overview, running-images inventory, scanner status, contributors, approvals, SLA tracking, one-click CSV.
• Dashboards: make your own dashboards from a catalog of panels. Share each one with everyone or with some roles, and copy dashboards to a different JAVV as a file.
• AI agents (MCP): connect an agent such as Codex, VS Code or Cursor to the MCP endpoint of JAVV. Each MCP token has one level: read, write, or write and risk accept. No token can change users, roles, settings or tokens, or delete data. Each tool call writes a row in the audit log. The endpoint is off by default (Use the MCP server).
• Data inspector + repair actions: a read-only OpenSearch console and a small set of sanctioned, journaled maintenance jobs.
• No external broker: coordination is OpenSearch, and the backend runs its own background jobs on cron schedules. No Redis/Kafka/RabbitMQ, and no CronJob per job: one backend container and one frontend container.

Architecture

flowchart TB
    subgraph CLUSTER["Your cluster · one per cluster_id"]
        direction TB
        SCAN["Python scanner module<br/>Trivy + Grype adapters, one JAVV-built image each<br/>run as CronJobs, kept per-scanner and never merged"]
    end

    subgraph JAVV["JAVV · central, never writes to a monitored cluster"]
        direction TB
        API["FastAPI async backend<br/>server-side aggregations"]
        STORE[("OpenSearch · single store<br/>findings · append logs · audit · config")]
        UI["Vue 3 frontend<br/>PrimeVue · Pinia · ECharts"]
        API <--> STORE
        API --> UI
    end

    SCAN -->|"scan envelopes<br/>token-authenticated ingest"| API

Ingest is authenticated with a per-cluster bearer token that is scope-bound: a token cannot push
another cluster's data. JAVV only ever receives pushes, so it needs no credentials for, and no
network path into, the clusters it reports on.

Deploy: docker compose on one machine, or Helm charts on Kubernetes
(docs/DEPLOYING.md). Full detail on layers, data flow, and the index
model lives in docs/engineering/ARCHITECTURE.md and
docs/engineering/INDEX-MAP.md.

Running it

On one machine: deploy/compose/ starts OpenSearch, the backend and the
frontend with docker compose up -d, on the images the release publishes, and scanners in any
cluster push to it. On Kubernetes: the javv-opensearch and javv charts, and javv-scanner
in each cluster you scan. The guide for both, including http or https and pointing scanners at
JAVV, is docs/DEPLOYING.md, also on the
docs site with configuration, sizing, upgrades and the
API.

From source, for development: bring the stack up by hand (backend + UI against a local OpenSearch, or the full end-to-end path
with real Trivy/Grype scanning a live k3d cluster) by following
development/RUNNING-THE-STACK.md (paths A / B / F). On a
fresh Ubuntu host, bash development/setup/setup-dev.sh installs every prerequisite first
(idempotent; verify readiness with preflight.sh).

Documentation

Operator docs: https://danube-labs.github.io/javv/latest/. Deploying, configuration, sizing and
scaling, upgrading, release notes, the API and the ingest contract, published from the files in
this repository whenever they change on main.

Canonical engineering set (docs/engineering/):

Supporting:

Stack & toolchain

Python 3.12 · FastAPI (async) · AsyncOpenSearch · Pydantic v2 · Vue 3 (<script setup>) · PrimeVue ·
Pinia · vue-echarts. OpenSearch is the single store. Open-source components throughout.

Gate-tool versions (the ones that decide lint/type/test results, so local matches CI) are pinned in
versions.yaml (D42). Bump them there; development/setup/setup-dev.sh reads
it directly and development/scripts/check-versions.sh drift-checks every consumer.

Supported versions

The externally-owned scanners + datastore JAVV pins and supports live in
versions.yaml (D41/D42). Renovate watches it, the compatibility gate
(scanner-images CI) validates a new scanner version before it's published, and a drift check keeps
the Dockerfiles + dev compose in step. To change support, edit versions.yaml.

Scanner images are published per supported version as
ghcr.io/danube-labs/javv-scanner-{trivy,grype}:<ver>; an operator pins/swaps a tag in their own
deploy (JAVV never changes versions in a running cluster). Each published image is signed (cosign
keyless) with a signed SBOM attestation: how to verify one.

License

JAVV is source-available under the Business Source License 1.1:

• Free to use, modify, and self-host, including in production, for any team or company.
• What you may not do: offer JAVV itself to third parties as a hosted/managed service (i.e. sell JAVV-as-a-service).
• Time-delayed open source: on the Change Date (2030-06-10) this version automatically converts to the Apache License 2.0.

Bundled/invoked tools (Trivy, Grype, OpenSearch) remain under their own Apache-2.0 licenses with
attribution. For other licensing arrangements, contact Danube Labs.