Trivy 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:

Collectors

This integration provides the following collectors (use include to select a subset):

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 own source (integration + collected_at), so the release-time scan is the integration: "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 on scan_history_size, its release-time scan is already gone, so .sca.history[0] will be the current .sca at enable time (an integration: "cron" entry), not the original code scan. 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.

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 runs trivy image <ref> itself, that scan is captured to .container_scan automatically. A trivy fs scan still routes to .sca. No install, no extra config.
• container-scan (on-push) — automatically scans every image as soon as it's published. Hooks after-json on .containers.native.docker.cicd.cmds, so a scan fires the moment the docker collector records a push — no schedule lag. A pipeline that pushes several images (an app and its migrator, say) gets them all scanned into one .container_scan: image / os describe the most recently pushed one, images[] breaks the counts down per image and every findings[] entry names its image. On a pull request it scans the images that commit pushed, so PR-time scanning needs your pipeline to push on PR builds; otherwise there is nothing to scan until the merge. Because the scan is dispatched the instant the push is recorded, it can briefly run ahead of that record becoming readable; it retries for a few minutes rather than reporting "nothing was pushed", and fails the run if the record never arrives — the on-push scan fires once per commit, so a silent skip would leave that commit unscanned.
• container-rescan (scheduled re-scan) — a daily cron that re-scans those images, catching CVEs disclosed after they were 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-scan needs a Hub with the after-json hook. Without it, exclude: [container-scan] and rely on the container-rescan cron (the other sub-collectors work on any Hub).

Scan provenance. A container scan records what it scanned and when: source.collected_at, source.collected_sha (the commit the run was bound to) and the registry digest of each image, resolved from the scanner's own output. The digest is the field that matters — the recorded reference is usually a floating tag like registry/app:main, so counts alone cannot tell you whether a scan covers the artifact you are about to promote. Compare digest against the digest you are promoting; if they differ, the numbers describe different bytes. A digest the registry does not report is left absent rather than guessed.

collected_sha is provenance, not identity: on a cron re-scan it is the latest ingested default-branch commit, which need not be the commit that built the image.

Container scan history. Set container_scan_history_size above 0 and each cron re-scan snapshots the current .container_scan into a bounded .container_scan.history[] before overwriting it, so the scan a release shipped with stays readable after later re-scans replace the live counts:

collectors:
  - uses: github://earthly/lunar-lib/collectors/trivy@main
    on: ["domain:your-domain"]
    with:
      container_scan_history_size: "30"

Entries hold source, image, digest, vulnerabilities and summary only — findings[], images[] and native are concatenated across collectors by the Hub, so snapshotting them would double them. At the cap the oldest entry is kept and the second-oldest dropped. Only the container-rescan cron maintains history; the on-push container-scan ignores the input. If the re-scan cannot read the current Component JSON it skips that tick rather than write a record without history. Running two scanners' crons on one component concatenates their histories, as it does images[] and findings[] — tell them apart by source.tool.

Private registries: the container-rescan cron pulls the images, 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.

Resources: container-scan and container-rescan declare size: large, because they pull and unpack the shipped image (and download the vulnerability database) inside the collector pod, and the default profile's 1Gi ephemeral-storage limit is too small for real-world images. The cicd sub-collector runs natively on your CI runner, so no pod size applies to it.

Note: If you already use the snyk collector, the trivy collector will overwrite .sca data since both write to the same paths. Use one SCA scanner per component, not both.