When to use

• Scanning container images for known CVEs before deployment
• Hardening Kubernetes Pod security contexts and runtime policies
• Managing secrets without baking them into container layers
• Generating Software Bills of Materials (SBOM) for compliance
• Signing container images for supply chain verification
• Setting up CI pipelines that block vulnerable images from reaching production

Consider Snyk Container Registry Sync (GA Apr 7, 2026) if you manage large registries: it automates importing new images to scan and pruning stale images using customizable rules to reduce alert fatigue and focus remediation on images that are actually deployed (Snyk blog, Apr 7, 2026).

When NOT to use

• Application-level SAST/DAST scanning — use Snyk Code or Semgrep instead
• Network security and firewall rules — use NetworkPolicies or a service mesh
• Cloud IAM and permissions management — use cloud-provider IAM tools
• Dockerfile authoring best practices — reach for the dockerfile-mastery skill

Core concepts

• CVE scanning: check image layers against vulnerability databases (NVD, GitHub Advisory)
• SBOM: Software Bill of Materials — a manifest of every package in an image (SPDX or CycloneDX)
• Image signing: cryptographic proof that an image was built by a trusted pipeline (cosign / Sigstore: fulcio/rektor)
• securityContext: Kubernetes Pod/container-level security settings (non-root, capabilities, seccomp)
• Runtime policy: OPA/Gatekeeper or Kyverno rules enforcing security constraints at admission
• Distroless: minimal images with no shell or package manager — reduced attack surface
• Supply chain: the pipeline from source to running container — every step is an attack surface
• Trivy: open-source scanner for vulnerabilities, misconfigurations, and secrets in images
• Snyk Container: commercial scanner with fix recommendations, base image suggestions, registry integrations, and Container Registry Sync (GA Apr 7, 2026) for automated image management and runtime-intelligence prioritization

Workflow

Step 0: (If you used Trivy during Mar 19–23, 2026) Immediate remediation checklist

1. Identify exposure
   • Search for the compromised digests in local image stores, registry mirrors, artifact repositories, CI caches, and self-hosted runners. Docker published the digests above; Trivy advisory lists the exposure windows for binaries, images, and actions.
2. Assume breach for any exposed environment
   • Rotate all CI/CD secrets, cloud credentials, SSH keys, and tokens immediately. Treat this incident as a pipeline compromise and assume secrets were exfiltrated.
3. Remove and quarantine
   • Remove compromised images from registries, caches, and CI/runner stores. Replace pipeline steps that referenced floating tags (including latest) with pinned digests or commit SHAs.
4. Rebuild and harden runners
   • Rebuild self-hosted runners from known-good images, revoke long-lived tokens that runners used, and enable ephemeral credentials/OIDC where possible.
5. Pin and verify scanner tooling
   • Pin scanner actions/binaries to explicit commit SHAs or image digests (example: uses: aquasecurity/trivy-action@<commit-sha>). When available, verify signatures (sigstore/cosign) and record verified digests in build metadata. Prefer scanner artifacts published with sigstore signatures or by vendors that support immutable releases.

References: Trivy GitHub security advisory GHSA-69fq-xp46-6x23 (Mar 21, 2026), Docker blog "Trivy supply chain compromise" (Mar 23, 2026).

Step 1: Scan images in CI (updated recommendations)

• Integrate Trivy and/or Snyk into CI but always pin scanner artifacts to immutable references and verify integrity before running them.
• Fail builds on CRITICAL or HIGH severity by policy, but use runtime-prioritization signals (if available) to focus remediation on exploitable vulnerabilities.
• Avoid floating tags for tooling (no latest). Record the digest/commit used in pipeline metadata for provenance.
• If you maintain a large registry, consider Snyk Container Registry Sync to import and prune images by rules so scans target in-use images (Snyk blog, Apr 7, 2026).

Example (pin Trivy action by commit SHA):

• uses: aquasecurity/trivy-action@<commit-sha>

Example (verify image digest before running in CI):

• Run a lightweight step before the scanner: pull digest via registry API and compare to expected sha256; fail if mismatch.

Step 2: Harden the Kubernetes securityContext

• Drop all capabilities and add back only what is required
• runAsNonRoot: true
• readOnlyRootFilesystem: true (use emptyDir writable mounts where needed)
• seccompProfile: RuntimeDefault or custom restrictive profile

Step 3: Manage secrets securely

• Never bake secrets into image layers. Use Kubernetes Secrets with external secret operators or CSI drivers.
• Use short-lived CI secrets and OIDC-based tokens for pipeline steps where supported.

Step 4: Generate and store an SBOM

• Generate SPDX or CycloneDX SBOMs at build-time and attach them to images in the registry.
• Store SBOMs alongside signed images and make them queryable by your registry-security tooling.

Step 5: Sign images and verify signatures

• Sign every production image with cosign (keyful or keyless) after build and scan.
• Verify signatures in admission controllers (Kyverno/OPA) before scheduling workloads.
• Verify scanner artifacts' signatures when vendors publish them (sigstore).

Step 6: Enforce policies at admission

• Block Pods that violate required constraints (e.g., unsigned images, runAsRoot, missing SBOM) using Kyverno or OPA Gatekeeper.
• Enforce automountServiceAccountToken: false for workloads that don't need K8s API access.

Examples

(Examples preserved — CI scanning step updated to demonstrate pinning and digest verification.)

Decision tree

• Need basic vulnerability scanning → start with Trivy (free, fast), but pin versions and verify integrity
• Need prioritized fix guidance and base-image advice → add Snyk Container
• Compliance requires SBOM → generate CycloneDX or SPDX with Trivy or Snyk and attach to image with cosign
• Supply chain verification needed → sign images with cosign and verify with Kyverno/OPA
• Pods must not run as root → set securityContext.runAsNonRoot + drop ALL capabilities
• App needs writable filesystem → readOnlyRootFilesystem + emptyDir mounts
• Secrets required at runtime → use Kubernetes Secrets with CSI driver or external-secrets-operator
• Need runtime threat detection → deploy Falco or similar syscall-level detection

Edge cases and gotchas

1. A backdoored scanner is a full pipeline breach — rotate secrets, rebuild runners, and invalidate tokens.
2. Immutable releases and sigstore mitigate tampering — prefer artifacts protected by GitHub immutable releases or signed with sigstore.
3. Trivy exposure windows differ by artifact (binary vs action vs Docker image) — consult the Trivy advisory for precise start/end times.
4. readOnlyRootFilesystem will break apps that expect writable directories — provide writable emptyDir volumes for those paths.
5. cosign keyless requires CI OIDC support — GitHub Actions supports OIDC-based keyless signing out of the box; other CI systems need explicit OIDC provider setup.
6. Scanners differ — run multiple scanners (Trivy + Snyk) if you need broader coverage, but triage by CVE ID.
7. Pod-level vs container-level securityContext — set both to avoid gaps.
8. Distroless images have no shell — use ephemeral debug containers (kubectl debug) instead.
9. SBOMs must be regenerated on every build/release — they do not reflect runtime-mounted packages or on-the-fly modifications.
10. Use registry VEX/attestation signals where available to deprioritize non-exploitable findings (Docker/Mend.io and Snyk products are adopting VEX/prioritization patterns).

Evaluation criteria

• CI pipeline scans every image before push and blocks CRITICAL/HIGH vulnerabilities
• Scanner tooling is pinned to immutable digests or commit SHAs and scanner artifacts are integrity-verified
• Kubernetes Pods run with runAsNonRoot, drop ALL capabilities, and use seccompProfile
• readOnlyRootFilesystem is enabled with emptyDir mounts for writable paths
• No secrets are baked into image layers (check with trivy image --scanners secret)
• Production images are signed with cosign and signatures are verified at admission
• SBOM is generated for every production image and stored alongside it
• Kyverno or OPA Gatekeeper policy enforces signed images in production namespaces
• automountServiceAccountToken is false unless explicitly required
• CI and runner credentials are short-lived and rotated after any suspected supply-chain compromise

Research-backed changes

• Added explicit Trivy advisory GHSA-69fq-xp46-6x23 references, precise exposure windows, and Docker-published compromised digests with timestamps (Trivy GitHub advisory; Docker blog Mar 23, 2026).
• Emphasized pinning and sigstore-based verification for scanner tooling and CI steps after the March 2026 incident.
• Included Snyk Container Registry Sync (GA Apr 7, 2026) as an operational option for large registries to reduce alert fatigue and focus remediation on in-use images (Snyk blog, Apr 7, 2026).