`trivy` integration

Trivy is Aqua Security's all-in-one scanner — containers, filesystems, IaC, secrets, licenses, and OS/library vulnerabilities, all from one binary. Cilock wraps the same trivy invocation, signs its SARIF output, and links it to the git commit and host environment it ran against.

Upstream	Trivy · Aqua Security · Apache-2.0
Category	vulnerability-scan (primary)
Catalog source	attestor-backed (ships a native cilock attestor)
Emits format	sarif
Predicate type	`https://aflock.ai/attestations/trivy/v0.1`
Recommended trace	off — no syscall tracing needed
Detected when	preargv_prefix: trivy

Confirm CI/lock detects it:

cilock plan --format=json -- trivy [...]

The facts in this box are generated from the CI/lock binary's own catalog (cilock tools list). Do not hand-edit — run npm run gen:catalog.

Validated invocation

Cilock invokes trivy directly as the wrapped command — no bash -c "cp ..." shim. The real tool is what cilock executes, traces, and records.

cilock run --step trivy-scan \
  --signer-file-key-path _validation/key.pem \
  --outfile attestation.json \
  --attestations sarif,environment,git \
  --enable-archivista=false \
  -- trivy fs --scanners vuln --format sarif --output trivy.sarif .

This is the exact line validated end-to-end in tool-trivy-sarif — don't paraphrase it.

Trivy exits non-zero when it finds vulnerabilities at or above its severity threshold. The validated example uses Trivy's default exit-code behavior; cilock surfaces that exit code in the command-run/v0.1 predicate, so policies can reason about scan results without re-parsing.

What gets captured

A single run with --attestations sarif,environment,git produces these predicate types in the signed envelope:

https://aflock.ai/attestations/command-run/v0.1 — the actual argv, exit code, and traced syscalls of trivy.
https://aflock.ai/attestations/material/v0.3 — Merkle hashes of every input file Trivy read.
https://aflock.ai/attestations/product/v0.3 — Merkle hash of trivy.sarif as written by the run.
https://aflock.ai/attestations/sarif/v0.1 — structured parse of the SARIF report, ready for policy.
https://aflock.ai/attestations/environment/v0.1 — host OS, kernel, env vars (with redaction).
https://aflock.ai/attestations/git/v0.1 — repo commit, branch, dirty/clean state.

Why this shape

Pattern	What cilock sees	Verdict
`-- trivy fs --scanners vuln --format sarif --output trivy.sarif .`	Real `trivy` argv, real exit code, real syscalls. SARIF written into the workdir is picked up by `product/v0.3` and parsed by `sarif/v0.1`.	Use this.
`-- bash -c "trivy fs ... && cp trivy.sarif out/"`	`bash` argv, `bash` exit code, `bash` + `cp` syscalls. Trivy's real exit code is hidden behind the shell.	Antipattern.

The direct invocation matters because the command-run attestor records what cilock actually executes. Wrapping the scanner in bash -c means a vuln-induced non-zero exit gets either silently swallowed or attributed to bash, and the syscall trace is the shell's, not Trivy's.

Validate it locally

# 1. Generate an ephemeral signing key.
mkdir -p _validation
openssl genpkey -algorithm ed25519 -out _validation/key.pem

# 2. Clone the validated example and run it.
git clone https://github.com/aflock-ai/attestor-compliance-examples.git
cd attestor-compliance-examples/tool-trivy-sarif
cilock run --step trivy-scan \
  --signer-file-key-path ../_validation/key.pem \
  --outfile attestation.json \
  --attestations sarif,environment,git \
  --enable-archivista=false \
  -- trivy fs --scanners vuln --format sarif --output trivy.sarif .

# 3. Confirm the expected predicate types are present.
jq -r '.payload' attestation.json | base64 -d \
  | jq '.predicate.attestations | map(.type)'

Expected output (order may vary):

https://aflock.ai/attestations/command-run/v0.1
https://aflock.ai/attestations/environment/v0.1
https://aflock.ai/attestations/material/v0.3
https://aflock.ai/attestations/product/v0.3
https://aflock.ai/attestations/sarif/v0.1
https://aflock.ai/attestations/git/v0.1

FAQ

Does cilock support Trivy?

Yes — through the generic sarif attestor (documented on this page). Run Trivy with --format sarif and cilock captures the report as a signed sarif/v0.1 attestation, the same uniform predicate it produces for every SARIF-emitting scanner (Grype, Semgrep, gosec, …).

What does Trivy scan when called from cilock?

Cilock doesn't change what Trivy scans — Trivy still scans whatever target you pass it (filesystem, container image, repository, Kubernetes cluster, IaC tree). The validated invocation runs trivy fs --scanners vuln ., which scans the working directory for OS-package and language-library vulnerabilities. Swap in trivy image <ref> or add --scanners vuln,secret,misconfig,license to widen coverage; cilock wraps whichever invocation you choose.

Will the SARIF be empty if Trivy finds nothing?

Yes — and that's fine. Trivy still writes a valid SARIF document with an empty results array, the product/v0.3 attestor still records the file's content hash, and the sarif/v0.1 predicate is still produced. The collection shape doesn't depend on findings being non-empty, so a clean scan still proves the scan ran against the signed inputs.

Validated invocation​

What gets captured​

Why this shape​

Validate it locally​

FAQ​

Does cilock support Trivy?​

What does Trivy scan when called from cilock?​

Will the SARIF be empty if Trivy finds nothing?​

See also​