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

When to consider Snyk Container Registry Sync (GA April 7, 2026): If you manage large registries or face alert fatigue from many stale images, Snyk’s Container Registry Sync (GA Apr 7, 2026) can automatically import new images to scan and prune stale images using customizable rules. For large fleets this reduces noise and focuses remediation on images that are actually deployed. (See Snyk blog: "Secure What Matters: Scaling Effortless Container Security for the AI Era", 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: checking 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)
• 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 (since Apr 7, 2026) Container Registry Sync for automated image management and runtime-intelligence prioritization

Workflow

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

1. Check whether your environment pulled affected Trivy images or action tags. Search for the known compromised digests in registries, local caches, mirrors, or artifact repositories (see Docker advisory digests above and Trivy GitHub advisory exposure window).
2. If you used any affected artifact during the exposure window, rotate all CI/CD secrets, cloud credentials, SSH keys, and tokens immediately. Treat this as a breach and assume secrets were exfiltrated.
3. Remove compromised images from registries and CI caches. Replace any pipeline steps that referenced floating tags (including latest) with pinned digests or commit SHAs.
4. Inspect self-hosted runners for persistence or malware. Rebuild runners from known-good images and revoke long-lived tokens used by runners.
5. Pin scanner tooling in CI to explicit commit SHAs or image digests and validate integrity (example: use uses: aquasecurity/trivy-action@<commit-sha> or pin to a digest where supported).

References: Docker advisory (Mar 23, 2026), Trivy GitHub security advisory (GHSA-69fq-xp46-6x23).

Step 1: Scan images in CI (updated)

Integrate Trivy and/or Snyk into the CI pipeline. Fail the build on CRITICAL or HIGH severity vulnerabilities. Important hardening additions after the Trivy incident:

• Pin the scanner action/binary to a specific commit SHA or image digest (avoid floating tags like latest).
• Prefer known-good/signed artifacts. When vendors publish signatures, verify them before running the scanner.
• Add a CI step that verifies the scanner image digest or action SHA before running it and records the digest in your build metadata.
• If using GitHub Actions, avoid pull_request_target for workflows that checkout or run external code; prefer safer patterns.
• For large registries, consider Snyk Container Registry Sync (GA Apr 7, 2026) to auto-import and prune images so scanning is focused on in-use images and reduces alert fatigue.

Example (pin Trivy action by tag or commit SHA):

• uses: aquasecurity/trivy-action@v0.35.0 # or uses: aquasecurity/trivy-action@<commit-sha>

Step 2: Harden the Kubernetes securityContext

Apply restrictive security settings at both the Pod and container level. Drop all capabilities and add back only what is needed. Set runAsNonRoot, readOnlyRootFilesystem, and an appropriate seccompProfile.

Step 3: Manage secrets securely

Never bake secrets into image layers. Use Kubernetes Secrets, external secret operators, or mounted volumes from a secrets manager. Ensure CI secrets are short-lived and rotated automatically where possible.

Step 4: Generate an SBOM

Produce an SPDX or CycloneDX SBOM for every production image. Store it alongside the image in the registry. Prefer build-time generation and attach SBOMs to signed images.

Step 5: Sign images with cosign

Sign every image after a successful build and scan. Verify signatures before deployment with a Kyverno or OPA Gatekeeper policy. Attach SBOMs and provenance to the signed artifact when possible.

Step 6: Enforce policies at admission

Use Kyverno or OPA Gatekeeper to block Pods that violate security constraints (e.g., running as root, no resource limits, unsigned images). Consider enforcing image scanning results, required SBOM presence, and signature verification in admission policies.

Examples

(Examples preserved — updated CI scanning step above to demonstrate pinning to safe versions/digests and to mention registry-sync pattern for large fleets.)

Decision tree

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

Edge cases and gotchas

1. Scanner compromise is a full pipeline breach — A backdoored scanner can silently exfiltrate secrets while producing apparently normal scan results. Treat any confirmed scanner compromise as a breach: rotate secrets, rebuild runners, and invalidate tokens.
2. Verify scanner artifacts — Don’t rely on tag names. Pin to digests/SHAs and verify signatures when available.
3. Trivy timeout on large images — Multi-GB images can exceed default scan timeout. Set --timeout 15m or scan the filesystem directly with trivy fs.
4. readOnlyRootFilesystem breaks many apps — Node.js apps that write to /tmp, log files, or cache directories will crash. Mount emptyDir volumes for writable paths.
5. cosign keyless requires OIDC — Keyless signing works automatically in GitHub Actions (via OIDC) but requires manual OIDC provider setup in other CI systems.
6. Snyk Container Registry Sync reduces alert fatigue — automated import/prune rules let you focus scans on images that matter and tie runtime signals into prioritization for faster remediation.
7. Snyk vs Trivy result differences — Scanners use different vulnerability databases and scoring. Running both catches more issues but can produce conflicting severity ratings. Triage by CVE ID, not by tool.
8. securityContext at Pod vs container level — Pod-level settings apply to all containers. Container-level settings override Pod-level. Missing either can leave gaps. Always set both.
9. Distroless has no shell for debugging — Use ephemeral debug containers (kubectl debug) instead of exec. This is a feature, not a bug — no shell means attackers cannot get a shell.
10. SBOM drift — An SBOM generated at build time does not reflect runtime changes (e.g., volume-mounted packages). Regenerate SBOMs on every release.

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 the workload explicitly needs the K8s API
• CI and runner credentials are short-lived and rotated after any suspected supply-chain compromise

Research-backed changes

• Added Snyk Container Registry Sync (GA Apr 7, 2026) as an operational option for large registries and guidance to use import/prune rules to reduce alert fatigue (Snyk blog, Apr 7, 2026).
• Confirmed and expanded the March 2026 Trivy supply-chain compromise remediation steps and exposure windows with Docker advisory and Trivy GitHub security advisory references (Mar 19–23, 2026).
• Reinforced CI hardening: pin scanner artifacts to SHAs/digests and verify signatures before running any third-party tooling.