In the previous post, we explored how Docker Scout helps identify vulnerabilities at the image level using CVE data. But vulnerability scanning is just one layer of container security.
Note: This blog is the 3rd part of our series on Docker Scout. To navigate directly to a specific section, please refer to the links below:
1st part link: Docker-Scout
2nd part link: Enablement and analysis of Docker Scout
4th part link: Docker scout Dashboard Navigation & Key Integrations
To build a truly resilient software supply chain, you need policy enforcement — and that’s exactly what Docker Scout’s policy evaluation enables.
What is Policy Evaluation?
Docker Scout supports policy evaluation, a high-level mechanism to detect and fix non-compliant images. Policies are a customizable set of rules that reflect your organization’s security and operational standards.
Policy rules are specific to each organization, you must specify which organization’s policy you’re evaluating.
Use the docker scout config command to configure your Docker organization.
Now you can run the quick view command to get an overview of the compliance status for the image you just built. The image is evaluated against the default policy configurations.
you can see the output like below,
1.Exclamation marks(!) in the status column indicate a violated policy
2.Question marks(?) indicate that there isn’t enough metadata to complete the evaluation.
3.A check mark(v) indicates compliance.
Improving Compliance: The docker scout quick view command gives a summary of Vulnerabilities , policy compliance, best practices.
You noticed two main issues in above image:
- “No data” for some policies — because your image lacks SBOM and provenance attestations.
- “Some failed checks” — like running the container as the root user.
Issue1: Running containers as the root user is a security risk because if an attacker breaks out of the container, they may gain elevated privileges on the host.
To resolve this , Modify the Dockerfile to use a non-root user.
add the following in docker file: USER appuser
Note: Make sure you’ve created appuser earlier in the Dockerfile with RUN useradd -m appuser.
Issue2: Missing SBOM and Provenance
- SBOM (Software Bill of Materials): A list of all components (libraries, dependencies) used to build the image.
- Provenance: Metadata that tells how the image was built
These are essential for compliance and traceability.
Note: The default Docker image store (classic) doesn’t support these advanced features like attestations (which include SBOM and provenance).
Enabling the correct image store
Docker Desktop now has two image stores:
- 1. Classic (legacy, doesn’t support attestations)
- 2. containerd-based (supports SBOM and provenance)
Enable containerd image store:
- 1. Open Docker Desktop
- 2. Go to Settings → General
- 3. Enable Use containerd for pulling and storing images
- 4. Click Apply & Restart
Keep in mind that , Switching to containerd might make previously built images temporarily disappear (they’re still there but in the other image store).
Now Rebuild the image with attestations
Once containerd is enabled, rebuild your image with provenance and SBOM.docker build --provenance=true --sbom=true --push -t <ORG_NAME>/scout-demo:v4 .
Conclusion: Evaluate Policy Compliance & Improve Image Hygien
Building on vulnerability scanning, this part focused on enforcing policy compliance, generating SBOMs and provenance, and improving security posture by fixing issues like running containers as root. You’ve also seen how to enable the containerd image store to support modern security features.
This post follows our [vulnerability scanning walkthrough](<<previous part link>>). If you haven’t enabled scanning yet, start there first.
Want to visualize and manage your image compliance in a dashboard?
Read the final post in the series: Docker scout Dashboard Navigation & Key Integrations