Docker Scout, Hardened Images, AI & Supply Chain Security

Learn Docker Scout, Multi-Stage Builds, Docker Hardened Images (DHI), SBOM, Docker Model Runner, Ask Gordon AI, and production-ready container security through practical, real-world examples.

Introduction

Docker has become the standard for building and deploying modern applications, but creating a container image is only the beginning. Every image includes operating system packages and application dependencies that may contain known vulnerabilities (CVEs), making container security a critical part of the software delivery lifecycle.

Modern DevOps teams don't just build containers—they scan, optimize, harden, and continuously improve them before deployment.

In this hands-on guide, you'll learn how to secure Docker images using Docker Scout, reduce image size with Multi-Stage Builds, generate SBOMs, build secure applications with Docker Hardened Images, run local AI models using Docker Model Runner, and troubleshoot Docker projects with Ask Gordon AI.

By the end of this tutorial, you'll have a practical understanding of building lightweight, secure, and production-ready Docker containers using modern Docker features.

What You'll Learn

After completing this guide, you'll be able to:

• Understand modern Docker security concepts.

• Scan images using Docker Scout.

• Analyze and prioritize CVEs.

• Generate Software Bill of Materials (SBOM).

• Build optimized images using Multi-Stage Builds.

• Secure containers with Docker Hardened Images (DHI).

• Debug containers without a shell.

• Apply production-ready container hardening techniques.

• Run local AI models using Docker Model Runner.

• Troubleshoot Docker projects with Ask Gordon AI.

• Follow Docker security best practices used in production.

Why Read This Guide?

Most Docker tutorials end after building an image. In production, that's where the real work begins.

Before deploying a container, every DevOps engineer should be able to answer questions like:

• Is the image vulnerable?

• Can the image be made smaller and more secure?

• Are secrets accidentally included?

• Is the container running as a non-root user?

• Can we generate an SBOM for compliance?

• How can AI simplify Docker development?

This guide answers all of these questions through practical examples, real-world scenarios, and production best practices.

Prerequisites

You'll need:

• Docker Desktop (latest version)

• Docker CLI

• Docker Hub account

• Basic Docker knowledge

• Familiarity with Dockerfiles

• Any sample application for practice

The concepts demonstrated in this guide apply to any Dockerized application, regardless of the programming language or framework.

Part 1 — Docker Scout

What is Docker Scout?

Building a Docker image is easy, but knowing whether it's secure is a completely different challenge.

A typical Docker image contains hundreds of operating system packages, libraries, and application dependencies. While these components make your application work, they can also introduce known security vulnerabilities (CVEs). Deploying an image without checking its security posture can expose your application to unnecessary risks.

This is where Docker Scout comes in.

Docker Scout is Docker's built-in security analysis tool that scans container images for known vulnerabilities, identifies outdated packages, recommends more secure base images, and helps developers improve the overall security of their containers before deployment.

Instead of waiting until production to discover security issues, Docker Scout allows you to identify and fix vulnerabilities early in the development lifecycle.

Why Should You Scan Docker Images?

Imagine you've built a Docker image using an older Ubuntu or Node.js base image. Even if your application code is perfectly secure, the base image itself may contain dozens of publicly disclosed vulnerabilities.

Without scanning, these issues remain hidden until they are exploited or discovered during a security audit.

Docker Scout helps answer important questions such as:

• Does my image contain known CVEs?

• Which vulnerabilities are the most critical?

• Are fixes available?

• Can Docker recommend a more secure base image?

• Which packages are responsible for these vulnerabilities?

This allows developers to make informed security decisions before releasing an application.

Hands-on Lab — Scan Your First Docker Image

Now it's time to perform our first security scan using Docker Scout.

We'll build a sample Docker image and analyze it for vulnerabilities.

Step 1 — Clone the Sample Application

We'll use a sample application throughout this guide.

Run the following command:

git clone https://github.com/LondheShubham153/devboard.git

Once the repository is cloned, navigate into the project directory.

cd devboard

Verify the project files.

ls

Step 2 — Build the Docker Image

Now let's build the Docker image.

Replace the image name with your preferred name.

Example:

docker build -t docker-security-demo:v1 .

Docker will begin downloading the required base image, installing dependencies, and building the final image.

Depending on your internet speed, this may take a few minutes during the first build.

Step 3 — Verify the Image

Before scanning, confirm that Docker created the image successfully.

Run:

docker images

You should see your newly created image in the list.

Scan Your First Docker Image with Docker Scout

Now that our Docker image has been built successfully, it's time to analyze its security posture.

Building an image doesn't guarantee that it's secure. Every image inherits packages and dependencies from its base image, and those packages may contain publicly disclosed vulnerabilities.

Docker Scout helps us identify these vulnerabilities before the image reaches production.

In this section, we'll perform our first vulnerability scan and learn how to interpret the security report generated by Docker Scout.

Step 4 — Perform Your First Docker Scout Scan

Docker Scout provides a quick security summary using the quickview command.

Run the following command:

docker scout quickview local://docker-security-demo:v1

Replace docker-security-demo:v1 with your own image name if you're using a different tag.

Docker Scout will analyze the image locally and display a summary of the detected vulnerabilities.

Unlike a detailed CVE report, QuickView focuses on giving you an overview of the image's security posture in just a few seconds.

Up Next → Detailed CVE Analysis

In the next section, we'll use:

docker scout cves local://docker-security-demo:v1

This command provides a detailed vulnerability report, including:

• The affected package

• CVE ID

• Severity level

• Installed version

• Fixed version (if available)

• Recommended remediation steps

We'll learn how to read a real CVE report like a security engineer and identify which vulnerabilities actually require immediate attention.

Part 2 — Analyze Vulnerabilities with Docker Scout CVE Reports

QuickView gives you a high-level overview of your image's security posture, but security engineers don't make decisions based on summary reports alone.

To understand exactly which packages are vulnerable, how severe the vulnerabilities are, and whether fixes are available, we need a detailed CVE report.

Docker Scout provides this information through the cves command, making it easier to identify the components that require immediate attention.

In this section, we'll generate a complete vulnerability report and learn how to interpret it like a DevSecOps engineer.

Step 5 — Generate a Detailed CVE Report

Run the following command:

docker scout cves local://docker-security-demo:v1

Replace docker-security-demo:v1 with your own image name if you're using a different image.

Docker Scout will scan every package inside your container image and display a detailed list of detected vulnerabilities.

Unlike quickview, this report shows exactly where each vulnerability exists and whether an update is available.

What is a CVE?

A Common Vulnerabilities and Exposures (CVE) is a globally recognized identifier assigned to publicly disclosed security vulnerabilities.

Each CVE has its own unique ID, making it easy for developers, vendors, and security teams to discuss the same vulnerability without confusion.

For example:

CVE-2025-12345

A CVE record typically includes:

• Vulnerability description

• Affected software versions

• Severity score

• References

• Available fixes

Think of a CVE as a tracking number for a known security issue.

💡 Pro Tip

Don't rush to fix every vulnerability immediately.

Instead, focus on vulnerabilities that:

• Have an available fix.

• Affect packages exposed to external users.

• Are marked as Critical or High severity.

• Exist in your runtime image rather than build-only dependencies.

This approach helps you prioritize security work more effectively.

⚠️ Common Mistake

Many beginners assume that every reported CVE is equally dangerous.

In reality, vulnerability scanners report the presence of a vulnerable package—not necessarily that the vulnerability is exploitable in your application.

For example, a package used only during the build process poses much less risk than a vulnerable web server library exposed to incoming user requests.

Always evaluate vulnerabilities in the context of your application before deciding on remediation.

Prioritize Vulnerabilities with Docker Scout

Finding vulnerabilities is only the first step. In real-world environments, security teams don't fix every CVE immediately. Instead, they prioritize vulnerabilities based on severity, fix availability, and business impact.

Docker Scout makes this easier by highlighting which vulnerabilities are actionable.

Step 6 — Show Only Fixable Vulnerabilities

Instead of reviewing hundreds of CVEs manually, filter the report to display only vulnerabilities that already have an available fix.

Run:

docker scout cves local://docker-security-demo:v1 --only-fixed

This reduces noise and helps you focus on vulnerabilities that can actually be remediated.

Step 7 — Filter High and Critical Vulnerabilities

Production teams usually prioritize Critical and High severity issues first.

Run:

docker scout cves local://docker-security-demo:v1 --only-severity critical,high

This filters the report and displays only the vulnerabilities that require immediate attention.

Best Practices

• Prioritize Critical and High vulnerabilities.

• Fix vulnerabilities with available patches first.

• Update the base image regularly.

• Re-scan the image after every major dependency update.

Up Next → Compare Your Base Image with Recommended Alternatives

In the next section, we'll use Docker Scout's recommend feature to:

• Check whether a newer base image is available.

• Compare your current base image with recommended alternatives.

• Reduce vulnerabilities by simply changing the FROM image.

• Understand Docker Scout's remediation recommendations.

Part 3 Find a Better Base Image with Docker Scout

After identifying vulnerabilities, the next step is to check whether Docker Scout recommends a more secure base image.

In many cases, simply updating the base image can significantly reduce the number of vulnerabilities without changing your application code.

Step 8 — View Base Image Recommendations

Run the following command:

docker scout recommendations local://docker-security-demo:v1

Replace docker-security-demo:v1 with your image name if required.

Docker Scout analyzes your current base image and suggests newer or more secure alternatives.

Step 9 — Update the Base Image

Open your Dockerfile and replace the existing base image with the recommended version.

Example:

Before

FROM node:22-alpine

After

FROM node:24-alpine

Your recommended version may be different depending on Docker Scout's output.

Step 10 — Rebuild the Image

After updating the Dockerfile, rebuild the image.

docker build -t docker-security-demo:v2 .

Step 11 — Scan the Updated Image

Run QuickView again to compare the results.

docker scout quickview local://docker-security-demo:v2

Compare the vulnerability count with the previous scan.

💡 Best Practice

Always use the latest stable and officially supported base image, then re-scan after every upgrade.

Part 4 — Generate an SBOM with Docker Scout

An SBOM (Software Bill of Materials) provides a complete inventory of all packages, libraries, and dependencies included in your container image. It's widely used for security audits, compliance, and software supply chain visibility.

Step 12 — Generate an SBOM

Run the following command:

docker scout sbom local://docker-security-demo:v2

Docker Scout will generate an SBOM and list all the packages included in your image.

output is too large that's why i mention only two snap's for your reference .

Step 13 — Export the SBOM

Instead of displaying it in the terminal, save it as a JSON file.

docker scout sbom local://docker-security-demo:v2 --format spdx-json > sbom.json

This creates an sbom.json file in your current directory.

Step 14 — Verify the SBOM File

Windows PowerShell:

cat sbom.json

You'll see package metadata in JSON format.

💡 Best Practice

Generate a fresh SBOM every time you release a new application version. It helps track dependencies, simplifies security audits, and improves software supply chain transparency.

Part 5 — Optimize Images with Multi-Stage Builds

A standard Docker image often includes build tools, source code, and temporary files that aren't needed at runtime. Multi-Stage Builds help create smaller, cleaner, and more secure production images by keeping only the required application files.

Step 15 — Build Using the Existing Dockerfile

First, build the application using the standard Dockerfile.

docker build -f Dockerfile -t docker-standard:v1 .

Check the image size.

docker images

Step 16 — Build Using the Multi-Stage Dockerfile

The project already contains a Dockerfile.multistage.

Build the image using it.

docker build -f Dockerfile.multistage -t docker-multistage:v1 .

After the build completes, verify the image size.

docker images

Step 17 — Compare the Image Sizes

Run:

docker images

Compare both images.

Step 18 — Verify the Application

Run the Multi-Stage image.

docker run -d -p 3000:4173 --name multistage-demo docker-multistage:v1

Verify it's running.

docker ps

Open the application:

http://localhost:3000

Part 6 — Optimize Build Context with .dockerignore

Even with Multi-Stage Builds, Docker may still send unnecessary files during the build process. A .dockerignore file excludes files that aren't required during the image build, resulting in faster builds, smaller build contexts, and preventing sensitive files from being included accidentally.

Step 19 — Check the Current Build Context

Build the image once without changing anything.

docker build -t docker-context:v1 .

During the build, notice the following line:

transferring context: XX MB

This shows the size of the build context sent to the Docker daemon.

Step 20 — Create a .dockerignore File

Create a new file named:

.dockerignore

Add the following entries:

node_modules
.git
.gitignore
README.md
Dockerfile*
.vscode
.env
.env.*
dist
coverage

Adjust this list based on your project if needed.

Best Practices

• Always include a .dockerignore file in every Docker project.

• Never include .env files or secrets in the build context.

• Exclude node_modules, .git, logs, cache, and IDE files.

• Review the build context after major project changes.

Part 7 — Secure Your Containers with Docker Hardened Images (DHI)

Docker Hardened Images (DHI) are production-ready base images designed to reduce the attack surface by including only the components required to run your application.

In this section, we'll pull a hardened image, compare it with a standard image, and analyze its security using Docker Scout.

Step 23 — View Available Docker Hardened Images

Open Docker Hub and navigate to the Docker Hardened Images catalog.

👉 Official Docker Hardened Images Catalog

https://hub.docker.com/catalogs/docker-hardened-images

Browse the available images and select the runtime that matches your application (Node.js, Python, Java, Go, .NET, etc.).

Step 24 — Pull a Hardened Image

Pull the Node.js Hardened Image.

docker pull dhi.io/node:22

Replace the image with the runtime you want to test.

After the download completes, verify the image.

docker images

Step 25 — Scan the Hardened Image

Run Docker Scout against the hardened image.

docker scout quickview dhi.io/node:22

Review the vulnerability summary and compare it with the standard Node image scanned earlier.

Step 26 — Compare Standard vs Hardened Image

Compare the results from both images.

✅ Best Practices

• Use Docker Hardened Images for production workloads.

• Keep the image updated regularly.

• Re-scan after every version upgrade.

• Combine Hardened Images with Multi-Stage Builds for maximum security.

Part 8 — Debug Docker Hardened Images with Docker Debug

Docker Hardened Images intentionally remove shells and debugging tools to reduce the attack surface. Instead of modifying the container, Docker provides Docker Debug, which lets you troubleshoot running containers without permanently changing them.

Step 27 — Verify Docker Debug

First, check whether Docker Debug is available.

docker debug --help

If Docker Debug is installed correctly, you'll see the available commands and options.

Part 9 — Run Local AI Models with Docker Model Runner

Docker Model Runner allows you to download and run AI models locally using Docker Desktop. The models run entirely on your machine, making it easy to experiment with AI without relying on external APIs.

Step 28 — Verify Docker Model Runner

First, check whether Docker Model Runner is available.

docker model --help

If Docker Model Runner is enabled, Docker will display the available model management commands.

Step 29 — List Available Models

Run:

docker model ls

This displays all AI models currently available on your system.

Step 30 — Pull Your First AI Model

Download a model from the Docker Model Registry.

Run:

docker model pull ai/smollm2

Docker will download the model and store it locally.

Step 31 — Verify the Downloaded Model

List the locally available models.

docker model ls

You should see the newly downloaded model.

Step 32 — Run the AI Model

Start an interactive session with the downloaded model.

docker model run ai/smollm2

The model will start locally and wait for your prompt.

Part 10 — Troubleshoot Docker Projects with Ask Gordon AI

Ask Gordon AI is Docker's built-in AI assistant that helps you understand Docker commands, explain errors, optimize Dockerfiles, and troubleshoot Docker projects directly from Docker Desktop.

Step 34 — Open Ask Gordon AI

Open Docker Desktop and navigate to the Ask Gordon section from the left sidebar.

Wait for the AI assistant to load.

or if you want to run on your terminal then you can run the below command :-

docker ai

Final Takeaways

Throughout this guide, you learned how to:

• Scan container images with Docker Scout.

• Analyze and prioritize vulnerabilities.

• Upgrade to recommended base images.

• Generate an SBOM.

• Reduce image size using Multi-Stage Builds.

• Optimize the build context with .dockerignore.

• Secure containers using Docker Hardened Images.

• Troubleshoot containers with Docker Debug.

• Run local AI models using Docker Model Runner.

• Improve Docker projects with Ask Gordon AI.

These practices help you build lighter, more secure, and production-ready Docker images while following modern DevSecOps workflows.

Conclusion

Building a Docker image is only the first step. A production-ready container should also be scanned, optimized, documented, and regularly maintained.

By combining Docker Scout, Multi-Stage Builds, Docker Hardened Images, SBOM generation, Docker Debug, Docker Model Runner, and Ask Gordon AI, you can create containers that are easier to maintain, more secure, and better prepared for real-world deployments.

Continue exploring new Docker features, keep your base images updated, and make security a regular part of your container development workflow.

👨‍💻 About the Author

Hi, I'm Apurv Gujjar, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.

I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.

📬 Connect With Me

📧 Email: gujjarapurv181@gmail.com

🌐 Portfolio: https://www.apurv-gujjar.co.in

🐙 GitHub: https://github.com/ApurvGujjar07

💼 LinkedIn: https://www.linkedin.com/in/apurv-gujjar

If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.