Trivy
Free · OSSVulnerability scanner
Know what's exploitable before an attacker does — containers, IaC, and filesystems.
Trivy homepage ↗Scans containers, filesystems, and infrastructure-as-code for known vulnerabilities and misconfigurations. CI-friendly defaults, generates SBOMs, makes patch-priority decisions easy.
Code complete and exposed in the dashboard, but rough edges remain. Do not pin compliance claims to this pack.
What it watches
- CVE findings in container images + OS packages
- Misconfigurations in IaC (Terraform, k8s, Dockerfiles)
- Exposed secrets in code + images
- SBOM generation + license findings
- Newly-disclosed CVEs matched against your existing inventory
MITRE ATT&CK coverage
Tactics this connector gives CyberCLI visibility into.
Every alert this connector surfaces
1 event type
Every matrix-covered event_type on the passthrough lane — pinned by the engine's coverage matrix.
The right column shows the operator-friendly phrase the dashboard renders. High-severity
AI-lane signals are summarized in What it watches above (Warden + Herald
handle those); the rest take the substrate's passthrough lane (no AI tokens burned).
| event_type | dashboard renders |
|---|---|
| trivy_ | Vulnerability scan on trivy |
What it helps you catch
What you'd see in CyberCLI
illustrativeTurns the CVE firehose into prioritized signals — patch the exploitable-and-exposed first, not all 4,000.
Routed to Warden (triage) → Scribe (record)
⛓ every step hash-chained · replayable
What CyberCLI reads from Trivy
audit our mathTrivy emits one JSON per scan; our `trivy-to-ndjson.sh` helper flattens it to per-finding NDJSON — each line is one CVE, misconfig, or leaked secret with scan context attached. The 40 fields we read carry scan identity (scan_run_id, scan_target, scan_mode = image/fs/config/k8s/sbom), finding taxonomy (finding_class, finding_id, cve_id), package state (package_name, installed_version, fixed_version), severity + cvss_score + published timestamps, plus secret_category and misconfig_resource. Dual dedup IDs answer what's exposed, what's fixable, and what's still open since last scan.
Full field index · 40 fields ↓
.action.agent_name.cve_id.cve_references.cvss_score.cybercli_class.cybercli_low_signal.cybercli_parse_status.cybercli_wire_format.event_id.event_timestamp.event_type.finding_class.finding_id.finding_instance_id.finding_stable_id.fixed_version.host_id.installed_version.misconfig_resource.os_family.package_name.result_class.result_target.result_type.rule_level.scan_artifact_type.scan_mode.scan_run_id.scan_target.scanner_label.secret_category.severity.vulnerability_description.vulnerability_last_modified_at.vulnerability_last_modified_at_raw.vulnerability_published_at.vulnerability_published_at_raw.vulnerability_status.vulnerability_title MITRE techniques typically mapped
- T1588.006 ↗
Acquire Capabilities: VulnerabilitiesResource Development
- T1190 ↗
Exploit Public-Facing ApplicationInitial Access
- T1552.001 ↗
Unsecured Credentials: Credentials In FilesCredential Access
- T1610 ↗
Deploy ContainerDefense Evasion · Execution
- T1525 ↗
Implant Internal ImagePersistence
- T1078 ↗
Valid AccountsInitial Access · Persistence
Trust Ladder ceiling · L0 → L3
- ·L0–L2: digest the finding, notify Herald on CRITICAL/HIGH and any secret-class hit, summarize the fixable-vs-no-fix split per scan for the operator
- ·L3 (Knight verification): pivot cve_id against KEV/EPSS, check fixed_version against host package state, correlate finding_stable_id across scans for unresolved-since dates
- ·L4+: containment — Trivy is point-in-time assessment, not enforcement; package upgrades, image rebuilds, IaC edits, and secret rotation route through operator-owned CI/CD
- ·Suppression decisions (.trivyignore, VEX) stay operator-owned — the AI never rewrites the policy it's judged against
Full ladder semantics · /trust →
Field count + sample event auto-derived from src/cybercli/connectors/trivy/vector.vrl at build time. Numbers update the moment the engine's parser changes — no drift.
Close more of the kill chain
Trivy covers 2 of 14 ATT&CK tactics. Pair it with these to widen coverage:
How to connect
- 1 Run Trivy in CI and/or scheduled against your images + IaC repos.
- 2 Emit JSON results.
- 3 Run `cybercli onboard trivy` and point it at the results path/endpoint.
- 4 Confirm findings in the dashboard's Connectors panel.
sudo apt install trivy # or: brew install trivy
Fully local. Trivy scans on your infrastructure; findings stay in your network.