Container image scanning options for FPC CI
- Verified: 2026-08-10
- Scope: the locally built
fpc-api:ciimage in GitHub Actions. ADR 0010 adopts the implementation described here; this research does not prove a particular hosted workflow run has completed.
Implemented seam
The Docker job in .github/workflows/ci.yml builds fpc-api:ci, then runs the full-SHA-pinned aquasecurity/trivy-action before starting test containers. The scan targets that local image, enables vulnerability and secret scanning, and fails the job for HIGH or CRITICAL findings. The initial baseline is remediated through narrowly scoped existing-dependency overrides before the blocking gate is enabled, rather than suppressing findings. The same job is eligible for pull requests to dev and main and pushes to those branches when the change classifier identifies an image-affecting change.
This is a strict CI gate for eligible runs, not a claim that every image has been scanned or that a successful scan proves the absence of vulnerabilities. Trivy matches detected packages and secret patterns against the scanner's available data; newly published advisories require a later eligible CI run or a recurring-scanning service. Trivy Action, Trivy container-image documentation, Trivy secret scanning
Do not add a second scanner for the MVP. Reconsider Grype only if FPC needs an independent detection comparison; reconsider Docker Scout when image-to-production comparison and supply-chain policy become concrete needs; reconsider Snyk when paid continuous registry monitoring and remediation workflows justify an account, token, and usage limits.
Enforcement timing and Dependabot boundary
The image scan is mandatory for its eligible pull-request and protected-branch-push CI runs. A draft pull request can obtain the same hosted feedback before review. The workflow intentionally does not impose this Docker build and scan on arbitrary feature-branch pushes, and the scan remains outside pre-commit because it requires Docker, scanner execution, and advisory data. A developer may run it locally for earlier feedback, but that is optional and does not substitute for the CI result. GitHub workflow events, Trivy Action cache, Trivy cache
Dependabot's docker ecosystem entry for apps/api proposes weekly Docker base-image version updates to dev. This is separate from Dependabot alerts and Dependabot security-update pull requests: GitHub creates security-update pull requests against the repository default branch (main), and the target-branch setting does not redirect them. No Dependabot security-update configuration is added here. Dependabot is complementary to Trivy: it can update declared Docker image references but does not scan the final image filesystem. Dependabot configuration options, Dependabot security updates
Comparison
| Option | Coverage and output | Cost and maintenance boundary | FPC fit |
|---|---|---|---|
| Trivy | Scans local container images for vulnerabilities and secrets; supports SARIF and CycloneDX/SPDX output. | Open-source action; no vendor account is required. FPC must pin the action and permit advisory-data refresh. | Selected now. It scans the exact image built in CI using the existing scanner vendor. |
Grype via anchore/scan-action | Scans container images, filesystem paths, OS packages, and language packages; supports SARIF and CycloneDX. | A second scanner/action and vulnerability-data lifecycle. | An independent comparison or alternative, but duplicative for the MVP. |
| Docker Scout | Builds an image SBOM, matches CVE/VEX data, and provides image-policy checks. | Product and plan coupling for continuous repository monitoring. | Reconsider later for image comparison and supply-chain policy. |
| Snyk Container | Scans final-image OS packages, unmanaged software, and application manifests; supports registry rescans. | SaaS account, token, usage limits, and recurring cost. | Reconsider when continuous monitoring and remediation workflow justify it. |
| GitHub-native capabilities | Dependabot updates declared dependencies and Docker references; Code Scanning accepts third-party SARIF. | Security-update behavior remains tied to the default branch; Code Scanning entitlement must be confirmed before SARIF upload. | Complementary reporting and update layer, not a final-image scanner. |
Deferred controls
Google Artifact Analysis or another registry-side scanning service, and scheduled or continuous rescans of unchanged images, are deferred to post-MVP hardening because they introduce recurring registry or CI cost. The decision must be revisited before relying on long-lived production images; the present CI gate only reassesses an image after an eligible rebuild.