🐳 CI/CD pipeline with Docker Scout

You build the image, tag it, ship it... everything looks great. Then your security team flags a CVE in a package you didn’t even know was in there.

Docker Scout is Docker’s built-in vulnerability scanning and SBOM (Software Bill of Materials) tool. No extra install, no separate tooling: it scans your images against 20+ advisory sources (NVD, GitHub Advisory DB, CISA KEV, etc.) and lets you enforce policy evaluation before an image is allowed to ship. It turns container security from a one-time checkbox into a continuous process.

Worth knowing: Docker Scout isn’t the first attempt at this. Before Scout, Docker shipped docker scan, which relied on Snyk’s engine under the hood. Vulnerability scanning for local Docker images was introduced in late 2020 with the command docker scan. The Docker Scan command would use Snyk’s engine to scan Docker images for security vulnerabilities. The docker scan command is deprecated and will no longer be supported after April 13th, 2023. Run the docker scout cves command to continue to get vulnerabilities on your images. So Scout is Docker’s own engine, not a rebrand of the old plugin. itnext
dev

One more thing worth knowing: Docker Scout’s native Slack integration is being retired on July 30, 2026. So the practical move is to run docker scout cves / docker scout policy directly inside your pipeline and route the result to your own notification channel.

A minimal Jenkins step, report first, enforce once you trust the signal:

stage('Image Scan') { steps { script { // Report only for now. Flip exitCode to 1 to fail the build on HIGH/CRITICAL. def exitCode = sh( script: ''' docker scout cves myorg/backend:${GIT_COMMIT} \ --only-severity critical,high \ --exit-code 0 ''', returnStatus: true ) if (exitCode != 0) { slackSend(channel: '#ci-alerts', color: 'danger', message: "Critical CVEs found in myorg/backend:${GIT_COMMIT}") } } } } 

Notification best practices, in short:
→ Alert only on HIGH/CRITICAL and pipeline failures, not every scan.
→ Keep webhook URLs in Jenkins Credentials, never in the Jenkinsfile.
→ A failed notification shouldn’t fail your build; wrap it, don’t gate on it.
→ The point: a broken build at 2am shouldn’t surface at 9am. Good alerting is signal, not noise.

Scan continuously, alert on what matters, decide your own threshold for when to block. That’s what makes container security part of the daily workflow instead of a quarterly audit.