Scanning, VEX & re-scan

Gate on what matters; catch new CVEs later.

Scanning is where the SBOM becomes actionable, but a scanner that fails the build on every CVE quickly gets disabled. Effective vulnerability management is about gating on what matters, suppressing noise responsibly, and re-scanning over time.

Gate on severity and exploitability

A scanner like Grype or Trivy reports findings by severity, but "fail on any CVE" is unworkable — base images always carry some, and many are not reachable in your code. The workable policy fails the build only on the findings that matter: high/critical severity, with a fix available, and not marked non-exploitable by a VEX statement. Run scanning in CI so a serious finding surfaces in the merge request, not in production, and record the result as a signed attestation so an admission gate can require "scanned, no unaddressed criticals".

# Report everything (visibility) but FAIL only on fixable high/critical.
grype registry.acme.internal/api@sha256:9f2c... \
  --fail-on high --only-fixed -o table
 
# Feed a VEX doc so known non-exploitable CVEs do not block the pipeline:
grype ... --vex vex.openvex.json
# Attach the result as evidence for the admission gate to require:
cosign attest --predicate scan.json --type https://acme.dev/scan/v1 <image@digest>

Suppress responsibly, re-scan always

Suppressing a finding is sometimes legitimate — a false positive, a genuinely unreachable path — but every suppression must carry a justification and an expiry, or the scanner slowly becomes meaningless as exceptions accumulate silently. Just as important, vulnerabilities are discovered continuously, so an artifact clean at build can be vulnerable next week: because you stored the SBOM, you can re-scan deployed artifacts against current data and catch newly-disclosed CVEs without rebuilding. Scanning is not a one-time gate but an ongoing posture.