Grype Vulnerability Scanner Collector

Scans source code dependencies for known vulnerabilities using Grype.

Overview

This collector runs Grype — Anchore's open-source vulnerability scanner — against the repository to detect known CVEs in dependencies. It supports the ecosystems Grype covers (Go, Node.js, Python, Java, Rust, Ruby, PHP, .NET, and more) and writes normalized vulnerability data to .sca in the Component JSON, making results immediately consumable by the existing SCA policy. No secrets or vendor accounts are required. By default it scans against the vulnerability database baked into the collector image, so freshness tracks the image rebuild cadence; set db_auto_update: true — on a Hub that honors the size: large profile these collectors declare — to fetch the latest database at scan time and pick up CVEs published since the image was built.

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/grype@main
    on: ["domain:your-domain"]

Zero configuration required. Works with any language Grype 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/grype@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/grype@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 Grype (or its ~1.7GB DB) in your pipeline:

• cicd (detect) — if your pipeline already runs grype <image> itself, that scan is captured to .container_scan automatically. A grype dir:/sbom: 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 Grype collector image (DB baked in) — no install on your side. 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/grype@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/grype@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.

Resources: container-scan and container-rescan declare size: large, because they pull and unpack the shipped image 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: The grype collector writes to the same .sca paths as the snyk and trivy collectors. Use one SCA scanner per component, not several, or they will overwrite each other's .sca data.

Re-scan freshness: By default (db_auto_update: false), each cron re-scan uses the DB baked into the collector image, so freshness is tied to the image rebuild cadence — bumping the pinned grype collector version (a newer image ships a newer DB) is what picks up new CVE data. Set db_auto_update: true (on a Hub that honors size: large) to have each re-scan fetch the latest vulnerability database instead, so CVEs published since the last scan surface on the next tick.