feat: container security reusable workflows [parent]

[ms280690]

Overview

Reusable GitHub Actions workflows for container security across all Sparkgeo repositories. Covers the full lifecycle from Dockerfile authorship through to runtime threat detection in production.

All workflows are stack-agnostic — they work regardless of what language or framework runs inside the container.

Four contexts, four tools

#	Context	Tool	Workflow	What it does
#13	Pre-commit	hadolint	container-lint.yml	Lints Dockerfile against CIS best practices before commit — no image build required
#14	PR / CI	trivy	container-scan.yml	Scans the built image for OS + library CVEs, misconfigs, and embedded secrets; SARIF → GitHub Security tab
#15	Registry	cosign	container-sign.yml + container-verify.yml	Signs images after CI passes (keyless Sigstore); verifies signatures before every deploy — blocks unscanned or tampered images
#16	Runtime / Ops	falco	falco-rules-lint.yml + falco-deploy.yml	eBPF/syscall runtime threat detection in cluster; lints custom rules on PR, deploys via Helm on merge

Tool selection rationale

Each tool was chosen as the single best fit for its context — no overlap, no redundancy:

• hadolint (pre-commit): only tool that works on the Dockerfile alone before an image is built; fast enough to block a commit
• trivy (PR/CI): covers OS + language libs + misconfigs + secrets in one binary; SARIF output; EPSS scores align with §5.5 triage policy; faster than a syft→grype pipeline
• cosign (registry): answers a different question than trivy — not "does this image have CVEs?" but "is this image exactly what CI produced?"; keyless Sigstore signing via GitHub OIDC, no stored signing key
• falco (runtime): the only tool that detects exploitation at syscall level after the container is running; static scanners cannot see what happens after deploy

Shared prerequisites

• Consuming repos must have a Dockerfile (or equivalent) in the repository root or under a documented subdirectory
• ECR or GHCR registry must be configured in the consuming repo's deployment workflow
• For cosign (feat: container security — image signing and verification (registry) #15): GitHub Actions OIDC must be enabled (no additional secrets required for keyless signing)
• For falco (feat: container security — runtime threat detection (ops) #16): EKS cluster accessible from the deploying workflow; Wazuh instance available for falcosidekick integration

Base image strategy

All consuming repo Dockerfiles should use Chainguard Wolfi (cgr.dev/chainguard/) base images. Wolfi:

• Eliminates 80–90% of trivy findings at source (minimal attack surface by design)
• Ships FIPS 140-2 compliant variants for regulated workloads
• Signed by Chainguard — verifiable with cosign

Task list

• feat: container security — Dockerfile linting (pre-commit) #13 — Dockerfile linting (pre-commit) — hadolint
• feat: container security — image vulnerability scanning (PR/CI) #14 — Image vulnerability scanning (PR/CI) — trivy
• feat: container security — image signing and verification (registry) #15 — Image signing and verification (registry) — cosign
• feat: container security — runtime threat detection (ops) #16 — Runtime threat detection (ops) — falco