Evaluate alternative scanners and portable database snapshots

[andreashaerter]

ConClear currently uses Trivy for vulnerability, secret, and configuration scanning.

Evaluate whether another scanner stack is useful. Using Syft and Grype would not replace the Trivy secret and configuration checks, so this option adds tools and another vulnerability database.

The design must retain exactly one authoritative vulnerability verdict, bind database snapshots by digest across workers, and define record, attestation, verification, and rescan behavior.

Also decide whether workers need an explicit transport for scanner database snapshots.

[andreashaerter]

Evaluated on 2026-09-14: Trivy, Syft and Grype on the same Debian 13 OCI layout in private Podman stores.

• Grype's CVE set is a strict subset of Trivy's, yet it reports 38 fixable HIGH or CRITICAL findings against Trivy's 14, because it uses NVD severities where Trivy uses the Debian vendor's. A second matcher therefore means a second verdict.
• Cross-consumption breaks rescans: Trivy reading a Syft SPDX document finds no operating system; reading CycloneDX it silently keeps 20 of 196 entries while the package assessment check still passes.
• Both databases run offline and have stable digests, but adding Grype would need a second database digest and freshness rule, a second SBOM predicate type, schema and architecture changes and repeated drills, and would make a snapshot transport mandatory.

Recommendation: keep Trivy as the sole scanner and SBOM producer; no snapshot transport. Worth a separate issue: record the severity source per gate finding.

[andreashaerter]

Relabeled blocked: upstream. Trivy cannot consume Syft's SPDX or CycloneDX output without losing the operating system or most packages, and Grype's NVD severities contradict the vendor severities Trivy uses, so a second matcher means a second verdict. Revisit when a second scanner can share Trivy's SBOM and severity source.