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

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:

| Layer | Tool | Status |
|-------|------|--------|
| Secrets | gitleaks | deployed |
| Dependency CVEs | OSV-Scanner | deployed |
| Dependency updates and vulnerability alerts | Renovate | deployed |
| IaC / Kubernetes misconfiguration | none | **gap - Trivy proposed** |
| Container image contents (deep inspection) | none | **gap - done once by hand in #199, never automated** |
| SBOM generation and attestation | none | **gap** |
| SAST | none | tracked in #216 |

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.