Docker Hardened Images

Overview

Docker Hardened Images are security-focused, curated images designed to reduce vulnerabilities and minimize attack surface. Mend Container helps you make better decisions about vulnerabilities in Docker Hardened Images (DHI) by combining:

• Docker’s own statements (e.g., VEX: “Not Affected”)

• Mend.io’s analysis (e.g., “Reachable”)

Prerequisites

DHI detection, alongside their VEX data, is automatic and does not require a designated integration.

DHI in the Mend AppSec Platform UI

1. Go to Security → Containers → Packages

2. Look for the Docker badge next to a package in the Package Name column.

You can:

• Filter packages by DHI using the Package Type filter.

• Sort packages as usual; DHI behaves like any other package type.

Note: The Docker badge labels the package that serves as a synthetic representation of the hardened image.

Example:

• When you scan the hardened image http://dhi.io/nginx:latest, you will see dhi/nginx in the package inventory, carrying a Docker badge.

• The other packages in the inventory also originate from the http://dhi.io/nginx:latest hardened image and can therefore have DHI VEX risk factors.

DHI VEX Risk Factors

Mend Container retrieves VEX statements from Docker and attaches them to detected packages as risk factors.

There are four VEX statuses:

• Affected

• Not Affected

• Fixed

• Under Investigation

Use the Risk Factors column to filter packages by VEX statuses.

Managing Risk in Docker Hardened Images

Risk information is available at the package or finding level. Docker VEX information is available at the finding level.

• Open a finding associated with the package in question:

• The finding’s Risk tab will contain the Docker VEX statement and reason (if applicable) as well as additional risk factors assigned by Mend.io, e.g., Reachable.

How to Resolve Conflicting Risk Factors

You may see different risk factors for the same CVE on a Docker image, for example:

• Mend.io: Reachable

• Docker VEX: Not Affected

This is expected:

• Reachable → the vulnerable code is used / reachable in your environment.

• Docker VEX: Not Affected → Docker says the hardened image is not vulnerable to that CVE.

Both are valid but answer different questions. There is no single “right” risk factor.
What you do with them is a policy decision for your organization.

Example Policy Patterns

Use these examples to define your own rule:

1. Vendor‑first (trust Docker more)

   • If Docker VEX: Not Affected = true, usually treat the finding as low priority, even if Mend.io shows Reachable.

2. Environment‑first (trust Mend more)

   • If Reachable, treat the finding as actionable, even if Docker VEX says Not Affected.

3. Balanced (common compromise)

   • High priority: Reachable AND Docker “Affected”

   • Medium: Reachable AND Docker “Not Affected” (review justification)

   • Low: Unreachable AND Docker “Not Affected”

Mend Container’s job is to surface both the hardened‑image status (DHI + Docker VEX) and your actual usage (Reachable).
Your job is to decide how your internal policy weighs these signals.