Container Image Scanning

We've all been there. You're setting up a new microservice, and the security team drops a requirement: "Scan your images, generate an SBOM, and sign them." Suddenly you're juggling Grype, Syft, Trivy, and Cosign. Each tool has its own YAML schema, its own flags, and its own quirks. You spend three days writing shell scripts to glue them together, only to realize your SBOM is missing relationship rules and your scanner is flagging false positives because you forgot to configure VEX support.

This fragmentation is the norm. Most teams treat scanning as an afterthought, slapping a docker scan command onto a pipeline without understanding the mechanics. You might pick a scanner because it's fast, but speed means nothing if you're missing critical CVEs in your base image. Or you might generate an SBOM, but if it's not structured correctly, your compliance audit fails. We built this skill so you don't have to reinvent the wheel. If you're also looking to Optimizing Docker Images to reduce your attack surface, you'll need a scanning workflow that integrates seamlessly with your build process. The reality is that container security isn't a single tool; it's a workflow. And without a defined workflow, you're leaving your supply chain wide open.

What Inconsistent Scanning Costs Your Pipeline

Ignoring a robust scanning workflow isn't just a "nice-to-have" omission; it's a liability. When you ship a vulnerable image, you're not just risking a CVE; you're risking production stability and customer trust. A single unpatched dependency can lead to a full-blown incident, forcing your team to drop everything for an emergency patch. The cost of a breach extends far beyond the immediate fix. You're looking at downtime, reputational damage, and potential regulatory fines.

The cost accumulates in hidden ways. CI/CD pipelines run for 20 minutes, only to deploy an artifact that contains a critical vulnerability. That's 20 minutes of wasted compute and a false sense of security. If your scanner isn't configured to filter fix-state vulnerabilities, you're wasting time triaging issues that are already resolved. If you don't enforce policies in the pipeline, vulnerable images slip into production, and by the time you catch them, they're already running in production. This is where a structured approach pays off. By integrating scanning with your broader reliability practices, like the SRE Golden Signals Playbook, you can catch issues before they impact your users.

Furthermore, the lack of a standardized workflow creates technical debt. Every new developer on the team has to figure out the scanning toolchain from scratch. They might use different tools, different configurations, and different standards. This inconsistency makes it impossible to get a holistic view of your security posture. You're essentially flying blind. As the CNCF Cloud Native Security Whitepaper notes, coupling vulnerability scans of container images with pipeline compliance rules ensures that only sufficiently patched applications are deployed to production ^[3]. Without these rules, you're not just wasting time; you're actively increasing your risk exposure.

How a Misconfigured Scanner Lets Critical CVEs Slip Through

Imagine a platform engineering team at a fintech company. They're deploying a Python microservice to Kubernetes. Their CI/CD pipeline includes a basic scan step, but it's configured with default settings. They use a popular scanner to check for CVEs, but they don't configure it to ignore known false positives or apply VEX documents. The scanner is fast, but it's not accurate.

During a routine audit, the security team discovers that the base image contains a critical CVE that the scanner missed because it wasn't tuned to the specific namespace of the vulnerability. The image had already been deployed to production. The team had to roll back the deployment, investigate the blast radius, and manually patch the image. This scenario is common. As the CNCF Cloud Native Security Whitepaper notes, coupling vulnerability scans of container images with pipeline compliance rules ensures that only sufficiently patched applications are deployed to production ^[3].

The team realized they needed a more robust workflow. They needed to generate a Software Bill of Materials (SBOM) to track dependencies, sign their images to verify provenance, and enforce policies to block critical vulnerabilities. The CNCF's map for Kubernetes supply chain security emphasizes that in a secure software supply chain, the build system signs metadata like provenance data, vulnerability scan reports, and SBOMs to produce a verifiable artifact ^[4]. By implementing a structured workflow, the team could prevent this incident in the future.

This isn't just about tools; it's about process. You need a workflow that defines security requirements, builds secure base images, scans for vulnerabilities, generates SBOMs, signs and verifies images, and enforces policies in CI/CD. This is exactly what we've built. If you're interested in diving deeper into supply chain security, check out the Supply-Chain-Security-Pipeline repository for a complete CI/CD pipeline that implements these controls ^[2].

Locking Down Your Supply Chain in Six Phases

Once you install the Container Image Scanning Pack, your workflow changes. You no longer have to guess how to configure Grype or Syft. You get a production-grade, six-phase workflow that handles everything from defining security requirements to enforcing policies in CI/CD.

Phase 1 defines your security requirements, ensuring you're aligned with your team's risk tolerance. You'll know exactly what standards you need to meet. Phase 2 helps you build secure base images, reducing the attack surface. This is where you can apply best practices from Optimizing Docker Images to minimize the number of vulnerabilities in your base layer.

Phase 3 integrates Grype scanning with a production-grade configuration. You get ignore rules, VEX support, fix-state filtering, and namespace exclusions out of the box. This means you're scanning efficiently and accurately, without drowning in false positives. The configuration is tuned for real-world usage, not just a quick scan.

Phase 4 generates a comprehensive SBOM using Syft. The configuration includes parallelism for speed, hashers for integrity, cataloger selection for accuracy, and relationship rules for context. You'll have a valid SBOM that passes compliance audits. As highlighted by Cy5, an SBOM elevates cloud-native vulnerability management by enabling faster triage, better compliance, and DevSecOps automation from build to runtime ^[5].

Phase 5 handles cryptographic signing and verification using Cosign. You get a reusable script for key generation and attestation, ensuring your images are tamper-proof. This is critical for proving the integrity of your artifacts.

Phase 6 enforces policies in your CI/CD pipeline using Trivy and Open Policy Agent (OPA). The Rego policy blocks critical and high vulnerabilities, ensuring that only secure images are deployed. This is where you shift left and prevent vulnerable images from ever reaching production.

The result is a streamlined, automated workflow that catches vulnerabilities early, generates verifiable artifacts, and integrates seamlessly with your existing tools. This level of security is essential when you're building a scalable platform, especially if you're also implementing an Internal Developer Platform to standardize developer experiences. By standardizing the scanning workflow, you reduce the cognitive load on your developers and ensure that security is baked into every build.

What's in the Container Image Scanning Pack

• skill.md — Orchestrator skill defining the 6-phase container image security workflow, referencing all templates, scripts, validators, and references.
• templates/grype-config.yaml — Production-grade Grype configuration with ignore rules, VEX support, fix-state filtering, and namespace exclusions.
• templates/syft-config.yaml — Production-grade Syft configuration for SBOM generation, including parallelism, hashers, cataloger selection, and relationship rules.
• templates/trivy-policy.rego — Open Policy Agent (OPA) Rego policy for Trivy to enforce CVE severity thresholds and block critical/high vulnerabilities.
• templates/cosign-signing.sh — Reusable script for cryptographic image signing and verification using Cosign, including key generation and attestation.
• scripts/supply-chain-audit.sh — Executable workflow script that orchestrates SBOM generation, vulnerability scanning, policy enforcement, and signing in sequence.
• validators/sbom-validator.sh — Programmatic validator that checks SBOM JSON structure, verifies required fields, and exits non-zero on failure.
• references/canonical-knowledge.md — Curated authoritative knowledge covering Grype scanning mechanics, Syft cataloging, Trivy policy enforcement, VEX documents, and SBOM standards.
• examples/ci-pipeline.yaml — Production GitHub Actions workflow integrating all phases: build, Syft SBOM, Grype scan, Trivy policy, Cosign sign, and upload artifacts.

Stop Guessing, Start Signing

Stop guessing. Start signing. Upgrade to Pro to install the Container Image Scanning Pack and lock down your supply chain. This isn't just another tool; it's a complete workflow that saves you hours of configuration and ensures your images are secure by default.

If you're serious about container security, you need a workflow that covers all bases. From scanning to signing, from SBOM generation to policy enforcement, we've built this so you don't have to. Install the pack and ship with confidence.