Trivy Vulnerability Scanner Collector
Automatically scans repository dependencies for known CVEs using Trivy. Supports Go, Node.js, Python, Java, Rust, and many other ecosystems. Writes normalized vulnerability data to .sca for use with the SCA policy. No secrets or vendor accounts required.
trivy to your lunar-config.yml:uses: github://earthly/lunar-lib/collectors/trivy@v1.0.5
What This Integration Collects
This integration includes 5 collectors that gather metadata from your systems.
auto
Auto-scans the repository filesystem for dependency vulnerabilities using Trivy. Writes normalized findings to .sca with severity counts, CVE IDs, affected packages, and fix versions.
cicd
Detects Trivy executions in CI pipelines. Captures the command,
version, and input arguments for audit and compliance tracking.
Routes results by scan type: an image scan (trivy image <ref>) is
normalized to .container_scan, while a filesystem scan (trivy fs)
stays in .sca — so a container scan already running in your pipeline
is collected automatically with no extra configuration.
rescan
Re-runs the dependency (SCA) scan on a schedule and overwrites .sca so
the SCA policy re-evaluates against CVEs published since the commit was
first scanned — closing the gap where a branch passes at scan time but a
dependency picks up a new CVE later. Runs the same scan as the auto
collector (the sibling auto.sh) in the Trivy collector image.
Opt-in scan history: with scan_history_size > 0 the re-scan first snapshots the current .sca (counts + summary + source, including the scan timestamp) into a bounded .sca.history[] array before overwriting .sca, preserving point-in-time scan results for audit. The SCA policy keeps reading the current .sca and behaves identically whether history is on or off. Default 0 keeps today's overwrite-only behavior — no history, no schema change for existing consumers.
container-scan
Automatically scans the container image this component published, as soon as it's detected. Via the after-json hook, resolves the pushed image from the docker collector's record (.containers.native.docker.cicd.cmds[]) and scans it with Trivy into .container_scan.
container-rescan
Re-scans the most recently shipped container image on a schedule. Resolves
the image from what the component actually pushed — the most recent
docker push (or --push build) in the docker collector's recorded
commands (.containers.native.docker.cicd.cmds[]), read via lunar component get-json. That's already-persisted data, so no collector dependency is
required. Pulls the image, scans it with Trivy, and overwrites
.container_scan so a shipped image is re-evaluated against CVEs published
after it was built. Override with the container_image input. No code
clone needed.
How Collectors Fit into Lunar
Lunar watches your code and CI/CD systems to collect SDLC data from config files, test results, IaC, deployment configurations, security scans, and more.
Collectors are the automatic data-gathering layer. They extract structured metadata from your repositories and pipelines, feeding it into Lunar's centralized database where guardrails evaluate it to enforce your engineering standards.
Learn How Lunar Works →Example Collected Data
This collector writes structured metadata to the Component JSON. Here's an example of the data it produces:
{
"sca": {
"source": {
"tool": "trivy",
"version": "0.69.3",
"integration": "cron",
"collected_at": "2026-07-08T02:00:07Z"
},
"vulnerabilities": {
"critical": 0,
"high": 2,
"medium": 5,
"low": 3,
"total": 10
},
"findings": [
{
"severity": "high",
"package": "golang.org/x/net",
"version": "0.7.0",
"ecosystem": "gomod",
"cve": "CVE-2023-44487",
"title": "HTTP/2 Rapid Reset Attack",
"fix_version": "0.17.0",
"fixable": true
}
],
"summary": {
"has_critical": false,
"has_high": true,
"all_fixable": true
},
"history": [
{
"source": {"tool": "trivy", "version": "0.69.3", "integration": "code", "collected_at": "2026-07-01T02:00:11Z"},
"vulnerabilities": {"critical": 0, "high": 1, "medium": 5, "low": 3, "total": 9},
"summary": {"has_critical": false, "has_high": true, "all_fixable": true}
},
{
"source": {"tool": "trivy", "version": "0.69.3", "integration": "cron", "collected_at": "2026-07-05T02:00:09Z"},
"vulnerabilities": {"critical": 0, "high": 2, "medium": 5, "low": 3, "total": 10},
"summary": {"has_critical": false, "has_high": true, "all_fixable": true}
}
],
"rescan_count": 2,
"native": {
"trivy": {
"cicd": {
"cmds": [
{"cmd": "trivy fs --scanners vuln .", "version": "0.69.3"}
]
},
"results": {
"SchemaVersion": 2,
"ArtifactName": ".",
"ArtifactType": "filesystem",
"Results": [
{
"Target": "go.sum",
"Class": "lang-pkgs",
"Type": "gomod",
"Vulnerabilities": [
{
"VulnerabilityID": "CVE-2023-44487",
"PkgName": "golang.org/x/net",
"InstalledVersion": "0.7.0",
"FixedVersion": "0.17.0",
"Severity": "HIGH",
"Title": "HTTP/2 Rapid Reset Attack",
"Description": "The HTTP/2 protocol allows a denial of service...",
"References": ["https://nvd.nist.gov/vuln/detail/CVE-2023-44487"],
"CVSS": {"nvd": {"V3Score": 7.5}},
"CweIDs": ["CWE-400"],
"PublishedDate": "2023-10-10T14:15:10Z"
}
]
}
]
}
}
}
},
"container_scan": {
"source": {
"tool": "trivy",
"version": "0.69.3",
"integration": "ci"
},
"image": "myregistry.io/app:v1.2.3",
"os": {
"family": "alpine",
"version": "3.19"
},
"vulnerabilities": {
"critical": 0,
"high": 1,
"medium": 4,
"low": 7,
"total": 12
},
"findings": [
{
"severity": "high",
"package": "libssl3",
"version": "3.1.4-r5",
"ecosystem": "alpine",
"cve": "CVE-2024-2511",
"title": "OpenSSL unbounded memory growth in TLSv1.3 session handling",
"fix_version": "3.1.4-r6",
"fixable": true
}
],
"summary": {
"has_critical": false,
"has_high": true,
"all_fixable": true
},
"native": {
"trivy": {
"results": {
"SchemaVersion": 2,
"ArtifactName": "myregistry.io/app:v1.2.3",
"ArtifactType": "container_image"
}
}
}
}
}Configuration
Configure this collector in your lunar-config.yml.
Inputs
| Input | Required | Default | Description |
|---|---|---|---|
scan_history_size
|
Optional |
0
|
Maximum number of prior SCA scans to retain in .sca.history[] on each cron re-scan. Snapshots are ordered oldest-first and the current scan stays in the main .sca fields, so the SCA policy is unaffected. Each entry carries its own source (integration + collected_at), so the release-time scan is identifiable as the integration="code" entry — that's .sca.history[0] when history is enabled from the component's first scan (the intended setup for release-time audit). Enabling it later on a component that has already been re-scanned captures the current .sca as the oldest entry, since the release-time scan was already overwritten. 0 (default) disables history entirely — .sca is overwritten each run exactly as today and no .sca.history is written, so existing consumers see no change. When the cap is reached the oldest entry (index 0) is preserved and the second-oldest is dropped. Only the rescan (cron) sub-collector maintains history; the on-push auto scan ignores this. |
max_rescans
|
Optional |
0
|
Stop re-scanning a component after this many scheduled re-scans; 0 (default) means unlimited. Counted independently via .sca.rescan_count (a monotonic tally of completed re-scans), so it stands alone and does not depend on scan_history_size — scan_history_size bounds how many scans you KEEP, max_rescans bounds how many you RUN. Once the limit is reached the cron skips the component, keeping the last scan and its history. |
container_image
|
Required | — | Pin the image the container scans (container-scan + container-rescan) scan. Default: the most recently pushed image in .containers.native.docker.cicd.cmds[] (recorded by the docker collector). e.g. "ghcr.io/acme/app:latest". |
Secrets
This collector requires the following secrets to be configured in Lunar:
| Secret | Description |
|---|---|
REGISTRY_USERNAME
|
Username for pulling private container images in the container-rescan cron. Optional — public images need no auth. REGISTRY_USER is accepted as an alias. |
REGISTRY_USER
|
Alias for REGISTRY_USERNAME (common registry/CI convention). Optional; used only when REGISTRY_USERNAME is unset. |
REGISTRY_PASSWORD
|
Password or token for pulling private container images in the container-rescan cron. Optional. |
Documentation
View on GitHubTrivy Vulnerability Scanner Collector
Scans source code dependencies for known vulnerabilities using Trivy.
Overview
This collector runs Trivy filesystem scans against repository source code to detect known CVEs in dependencies. It supports all ecosystems Trivy covers (Go, Node.js, Python, Java, Rust, Ruby, PHP, .NET, etc.) and writes normalized vulnerability data to .sca in the Component JSON, making results immediately consumable by the existing SCA policy. A scheduled rescan re-runs the same scan on a cron and overwrites .sca, so a previously-clean commit is re-evaluated against CVEs published after it was first scanned. Prior re-scans can optionally be kept in a bounded .sca.history[] for point-in-time audit (off by default).
No secrets or vendor accounts are required — Trivy's vulnerability database is downloaded at scan time to ensure the latest CVE data.
Collected Data
This collector writes to the following Component JSON paths:
| Path | Type | Description |
|---|---|---|
.sca.source |
object | Source metadata (tool name, version, integration method, and collected_at scan timestamp) |
.sca.vulnerabilities |
object | Severity counts (critical, high, medium, low, total) |
.sca.findings[] |
array | Individual vulnerability findings with CVE, package, fix info |
.sca.summary |
object | Summary booleans (has_critical, has_high, all_fixable) |
.sca.history[] |
array | (opt-in) Bounded list of prior scan snapshots (source, counts, summary) for point-in-time audit; oldest first. [0] is the oldest retained scan — the release-time (integration="code") scan when history is enabled from the first scan. Absent unless scan_history_size > 0 |
.sca.rescan_count |
number | (opt-in) Monotonic tally of completed re-scans, used to enforce max_rescans independently of the (capped) .sca.history[] length. Present when scan history or max_rescans is enabled |
.sca.native.trivy.cicd |
object | CI command detection data (command, version) |
.container_scan.source |
object | Source metadata for the container image scan (tool, version, integration) |
.container_scan.image |
string | The scanned image reference (e.g. registry/app:tag) |
.container_scan.vulnerabilities |
object | Severity counts for the image scan (critical, high, medium, low, total) |
.container_scan.findings[] |
array | Individual image findings (OS and application packages) |
.container_scan.os |
object | Detected base-image OS family and version |
.container_scan.summary |
object | Summary booleans (has_critical, has_high, all_fixable) |
.container_scan.native.trivy |
object | Raw Trivy results for the image scan |
Collectors
This integration provides the following collectors (use include to select a subset):
| Collector | Hook Type | Description |
|---|---|---|
auto |
code | Auto-scans the repository filesystem for dependency vulnerabilities → .sca |
cicd |
ci-after-command | Detects Trivy executions in CI; routes image scans (trivy image <ref>) to .container_scan and filesystem scans (trivy fs) to .sca |
rescan |
cron | Re-runs the auto scan on a schedule (daily by default) and overwrites .sca so the SCA policy re-evaluates against newly-published CVEs; optionally snapshots prior scans into .sca.history[] (opt-in via scan_history_size — see Scan history) |
container-scan |
after-json | Automatically scans the image the docker collector records as pushed (.containers.native.docker.cicd.cmds[]) as soon as it's published; writes .container_scan |
container-rescan |
cron | Re-scans the most recently pushed image on a schedule, catching CVEs disclosed since it was built |
Installation
Add to your lunar-config.yml:
collectors:
- uses: github://earthly/lunar-lib/collectors/trivy@main
on: ["domain:your-domain"]
Zero configuration required. Works with any language Trivy supports.
By default this also enables the rescan cron sub-collector, which re-runs the
scan daily on each component's default branch and overwrites .sca. To keep the
on-push (auto) and CI-detection (cicd) scans but turn the scheduled re-scan
off, exclude it:
collectors:
- uses: github://earthly/lunar-lib/collectors/trivy@main
on: ["domain:your-domain"]
exclude: [rescan]
Scan history (point-in-time audit)
By default the rescan cron overwrites .sca each run — the SCA policy
always sees the latest scan and the previous result is discarded. Because an
unchanged artifact accrues newly-disclosed CVEs over time, you may want to
keep each scan as a point-in-time record (e.g. "here's what the scan looked
like when we shipped this release"). Opt in by keeping a bounded history:
collectors:
- uses: github://earthly/lunar-lib/collectors/trivy@main
on: ["domain:your-domain"]
with:
scan_history_size: "30" # keep up to 30 prior scans in .sca.history[]
max_rescans: "0" # 0 = keep re-scanning forever (default)
With scan_history_size > 0, each re-scan snapshots the current .sca
(source + counts + summary, including the collected_at timestamp) into
.sca.history[] before overwriting .sca:
.sca(unchanged) — the current scan the SCA policy evaluates..sca.history[0]— the oldest retained scan, preserved even once the cap is reached. When history is enabled from the component's first scan (the intended setup) this is the release-time scan; each entry carries its ownsource(integration+collected_at), so the release-time scan is theintegration: "code"entry — not an assumption about position..sca.history[1..]— successive prior re-scans, oldest first.
Enabling history on an already-scanned component: if a component has already been re-scanning (overwriting
.sca) before you turn onscan_history_size, its release-time scan is already gone, so.sca.history[0]will be the current.scaat enable time (anintegration: "cron"entry), not the originalcodescan. For guaranteed release-time capture, enable history from the component's first scan.
The SCA policy never reads .sca.history, so enabling this changes nothing for
policy evaluation — .sca behaves identically whether history is on or off.
| Input | Default | Effect |
|---|---|---|
scan_history_size |
0 |
Max entries kept in .sca.history[]. 0 disables history (today's overwrite-only behavior). At the cap the oldest entry ([0]) is kept and the second-oldest is dropped. |
max_rescans |
0 |
Stop re-scanning a component after this many re-scans (0 = unlimited). Counted independently via .sca.rescan_count, so it stands alone — no dependency on scan_history_size. |
Both default to off, so existing installs are unchanged. Only the rescan cron
maintains history — the on-push auto scan ignores these inputs.
Container image scanning. Beyond source dependencies, this collector scans built container images into the normalized .container_scan path (consumed by the container-scan policy). Three sub-collectors feed it, none installing Trivy in your pipeline:
cicd(detect) — if your pipeline already runstrivy image <ref>itself, that scan is captured to.container_scanautomatically. Atrivy fsscan still routes to.sca. No install, no extra config.container-scan(on-push) — automatically scans the image as soon as it's published. Hooksafter-jsonon.containers.native.docker.cicd.cmds, so a scan fires the moment the docker collector records a push — no schedule lag.container-rescan(scheduled re-scan) — a daily cron that re-scans that image, catching CVEs disclosed after it was built.
All three scan the shipped image itself in the Trivy collector image — no install in your CI. Enable the docker collector alongside this one so its docker push commands are recorded:
collectors:
- uses: github://earthly/lunar-lib/collectors/docker@main
on: ["domain:your-domain"]
- uses: github://earthly/lunar-lib/collectors/trivy@main
on: ["domain:your-domain"]
container-scanneeds a Hub with theafter-jsonhook. Without it,exclude: [container-scan]and rely on thecontainer-rescancron (the other sub-collectors work on any Hub).
Private registries: the container-rescan cron pulls the image, so a private registry needs the REGISTRY_USERNAME (or REGISTRY_USER) / REGISTRY_PASSWORD secrets. Trivy's vulnerability database is a modest download at scan time.
Note: If you already use the
snykcollector, thetrivycollector will overwrite.scadata since both write to the same paths. Use one SCA scanner per component, not both.
Open Source
This collector is open source and available on GitHub. Contribute improvements, report issues, or fork it for your own use.
Common Use Cases
Explore guardrails that use data from Trivy Vulnerability Scanner Collector.
Ready to Automate Your Standards?
See how Lunar can turn your AGENTS.md, engineering wiki, compliance docs, or postmortem action items into automated guardrails with our 200+ built-in guardrails.
AI agent rules & prompt files
Post-mortem action items
Security & compliance policies
Testing & quality requirements