Add Trivy for IaC/container scanning; reassess Grype against the deployed stack

Start by reading osv-scanner.yml, leaked-secrets-scan.yml, the manifests under k8s/, and the manual image audit in #199; also review #216 for the broader scanning-stack decision. Done means the project has a settled tool boundary, a choice of SBOM format and release handling, and an automated approach that works with locally built images rather than only registry pulls.

Narrowed. The evaluation in the comment below stands and should not be re-run - it is thorough
and its comparison of Trivy against Grype is sound. What has changed is the baseline it was
measured against.

Amendment to the original verdict

The evaluation concluded "use both": Trivy as the primary scanner, Grype as a secondary layer
for its EPSS/KEV risk scoring. That verdict did not account for OSV-Scanner, which is
already deployed across smartem-devtools, smartem-decisions and smartem-frontend
(osv-scanner.yml), alongside gitleaks (leaked-secrets-scan.yml) and Renovate, which itself
raises vulnerability alerts.

Implementing the verdict as written would leave a solo-maintained project running four
overlapping security tools, three of which report dependency CVEs against the same lockfiles.

Revised scope

Add Trivy

Trivy has a capability none of the currently deployed tools provide: infrastructure-as-code
and Kubernetes misconfiguration scanning. OSV-Scanner, Renovate and gitleaks all ignore the
manifests under k8s/ entirely.

That gap is not hypothetical. Two known manifest problems are currently tracked by hand on
#179 - :latest image tags in the staging and production manifests, and the complete absence of
NetworkPolicies. Both are exactly what an IaC scanner reports automatically, and would keep
being reported rather than needing to be rediscovered.

Container image scanning is the secondary benefit, and becomes more relevant as images are
published for deployment.

Reassess Grype rather than adopting it

Grype's distinguishing feature is prioritisation - composite risk scoring from CVSS, EPSS and
KEV - which is genuinely better than plain severity labels. But it prioritises a finding stream
that OSV-Scanner and Renovate already produce, so it adds a third opinion on dependency CVEs
rather than new coverage.

The question to answer before adopting it is narrower than the original one: does EPSS/KEV
prioritisation justify a third dependency scanner, or would the same benefit come from
prioritising OSV-Scanner's existing output? Adopting Grype and retiring OSV-Scanner is also a
legitimate answer, and possibly the better one, since it consolidates rather than adds.

Add deep image inspection

The May 2026 Docker image audit (#199) established that this is a real need, and did it by
hand: docker create + docker export per image, then gitleaks against the extracted
rootfs, plus docker history --no-trunc and docker inspect for layer provenance. That found
a genuine leak in a published image. It has not been repeated since, and nothing runs it
automatically.

This is a distinct capability from dependency CVE scanning: it asks what is actually in the
built image, not what does the lockfile claim. The two disagree regularly - build context
leaks, forgotten COPY directives, and stale layers are invisible to a lockfile scan.

Trivy covers most of this natively. It scans image filesystems for secrets and misconfiguration
as well as packages, which is precisely the manual procedure from #199 turned into a CI step.
dive is the specialist option for layer composition and wasted-space analysis, and has a CI
mode with configurable thresholds, but it answers a narrower question.

Note the audit's tooling finding, which still applies: trufflehog's docker --image mode
insists on pulling from a registry rather than using the local daemon, which made it unusable
against a private GHCR repository. Whatever is chosen needs to work against locally built
images, not only published ones.

Add SBOM generation

Not currently produced anywhere. Two distinct purposes, and the choice of tool depends on which
is wanted:

• As scanning input - generate an SBOM once, then scan it repeatedly without rebuilding.
  Useful for re-checking already-published images against newly disclosed vulnerabilities.
• As a supply-chain artefact - publish the SBOM alongside each release so consumers can
  audit what they are deploying. For a facility system with long-lived deployments and a
  seven-year data-retention context, this is the more likely motivation, and it implies
  attaching and signing SBOMs at release time rather than merely generating them in CI.

These are not mutually exclusive, but they lead to different placements in the pipeline.

Tooling, in order of how well it fits what is already proposed:

• Trivy emits both CycloneDX and SPDX, and can scan an SBOM it produced. If Trivy is adopted
  for the reasons above, SBOM generation is close to free.
• Syft is the dedicated generator and is Grype's natural companion. It only makes sense as a
  pair with Grype.
• GitHub's actions/attest-sbom handles attestation and signing at release time, and is
  complementary to whichever generator is chosen rather than an alternative to it.

Decide the format too - CycloneDX and SPDX are both viable, and the answer depends on what
consumes it. If DLS has an existing convention, follow it rather than choosing independently.

Decide the stack as a whole

This should be settled together with #216 (SAST layer - Semgrep, CodeQL, or both) rather than
tool by tool. The useful question is what the complete scanning stack should be and what each
tool is uniquely responsible for, not whether each individual tool is good. Every tool added
in isolation is defensible; the aggregate is what becomes unmaintainable.

Current coverage, for that conversation:

Trivy is the strongest candidate precisely because it closes three of these gaps at once -
IaC misconfiguration, image-content scanning including secrets, and SBOM generation - rather
than adding one tool per row.