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.
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:
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:
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.
| Image |
Expected Result |
| Standard Build |
Larger image |
| Multi-Stage Build |
Smaller image |
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.
| Feature |
Standard Image |
Docker Hardened Image |
| Vulnerabilities |
Higher |
Lower |
| Installed Packages |
More |
Minimal |
| Attack Surface |
Larger |
Smaller |
| Production Ready |
Standard |
Security Optimized |
✅ 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.
