Claude Prompt to Build a Container Security Scanning Pipeline

What this prompt does

This prompt makes the AI assemble a complete container security scanning pipeline that runs as part of your CI/CD, stopping unsafe images before they reach [environment]. It walks through eight ordered stages — Dockerfile linting with [dockerfile_linter], dependency CVE scanning of your [package_manager] lockfile via [dep_scanner], image vulnerability scanning with [image_scanner], secret detection, SBOM generation in [sbom_format], an OPA/Gatekeeper runtime policy, a [compliance_framework] report, and an audited suppression file for false positives.

The structure works because it mirrors the real order a security gate executes: cheap static checks first, then dependency and image scans, then policy and reporting. Filling [severity_threshold] controls how aggressive the gate is, [policy_rules] defines what the cluster will refuse to run, and [compliance_framework] aligns the output with the standard your auditors actually use. Because each stage names a concrete tool, the model produces runnable config rather than abstract advice.

When to use it

• You are shipping container images and want to catch CVEs at build time instead of in production.
• A leaked API key or credential in an image layer is a risk you need to detect automatically.
• An auditor or customer requires an SBOM and a [compliance_framework] report for every release.
• You want a hard gate that fails builds on critical/high vulnerabilities rather than an advisory warning.
• You need an OPA/Gatekeeper policy to block images that violate [policy_rules] at deploy time.
• You are standardizing scanning across multiple repos and want one consistent pipeline template.

Example output

Expect a structured pipeline definition for [ci_platform] — typically a YAML workflow with discrete jobs for linting, dependency scanning, image scanning, secret detection, and SBOM generation — plus a separate OPA/Gatekeeper policy manifest, a sample suppression file, and a short description of how the compliance report is produced. Each stage includes the command invocation and the fail condition.

Pro tips

• Set [severity_threshold] deliberately: blocking on CRITICAL and HIGH is a sane default, but expect to manage the false-positive suppression file actively or the gate becomes noise.
• Match [package_manager] to every lockfile you actually ship; if you have both pnpm-lock.yaml and requirements.txt, name both so nothing is skipped.
• Keep the [image_scanner] and [dep_scanner] choices consistent across repos so results are comparable; a single tool reused everywhere beats a different scanner per project.
• Make [policy_rules] enforce digests and non-root explicitly — those two rules catch the most common deploy-time mistakes.
• Treat the suppression file as audited code: require a reason and an expiry for every entry, or stale exceptions will quietly reopen the gate.
• Generate the [sbom_format] artifact even if you do not consume it yet; you will want it the first time a new CVE drops and you need to know which images are affected.