dhi: add vex walkthrough

[craig-osterhout]

Description

Added VEX walkthrough guide for Docker Hardened Images

The existing DHI documentation covers VEX concepts and scanner integration, but as separate reference topics. Users who want to understand VEX in practice have to piece together the workflow themselves.
This guide shows the full workflow end-to-end against a real image (dhi.io/python:3.13): scan without VEX to get the raw CVE baseline, fetch the attestation, scan again with VEX applied, then inspect every suppression and the reasoning behind it. Each step shows actual command output so readers can compare what they see against a known reference.
The guide covers:

• Before/after scans with Trivy and Grype to make the VEX effect concrete
• Docker Scout's automatic VEX integration as a contrast
• Trivy's --show-suppressed flag to surface per-CVE justification codes
• jq queries against the raw VEX file to read Docker's human-readable reasoning and filter by status (not_affected, under_investigation, affected)

The goal is to give readers a working mental model of what VEX does and how to audit it — something a walkthrough can do that reference docs can't.

https://deploy-preview-24992--docsdocker.netlify.app/guides/dhi-vex-walkthrough/

Related issues or tickets

ENGDOCS-3239

Reviews

• Editorial review

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	b971915
🔍 Latest deploy log	https://app.netlify.com/projects/docsdocker/deploys/6a066680fb08bd00085283f1
😎 Deploy Preview	https://deploy-preview-24992--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[craig-osterhout]

/review

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

Note: The automated verifier returned an empty response for this review. The findings below are from the drafter and have been manually verified against the diff by the coordinator agent.

Summary: The new VEX walkthrough guide is well-structured and covers the workflow end-to-end. Four medium-severity style and content issues were found in the added lines.

[craig-osterhout]

Internal feedback:

Any reason why you're passing --platform linux/amd64 while pulling the python 3.13? I tested this on a clean macOS setup (Apple Silicon, Docker Desktop) and found one blocker plus a few smaller items.

On arm64 Macs (the entire Apple Silicon line, which is most Mac users now), this forces a cross-platform pull. The image lands fine, but the Trivy container example that follows then fails:

FATAL Fatal error  run error: image scan error: scan error: scan failed:
failed analysis: unable to get the image's config file: unable to populate:
unable to open: unable to export the image: Error response from daemon:
unable to create manifests file: NotFound: content digest
sha256:76f1d9a391e838970bff7ddf3b742cb216392b65bb1ecf6d45c9b89ee26de65c: not found

Trivy's daemon-socket export path can't resolve the cross-arch manifest digest. Dropping the --platform flag and re-pulling native arm64 makes the same Trivy container command work first try, with output that matches the guide's example byte-for-byte

[dvdksn]

I just realized I never posted this comment? Sorry, I had an unsubmitted review!

[docker-agent]

Assessment: 🟢 APPROVE

This PR adds a clear, well-structured VEX walkthrough guide for Docker Hardened Images. Required front matter fields are present, no vendored content is touched, commands and flags appear accurate, and the step-by-step structure follows the tutorial format correctly. Two minor style violations from the Docker docs word list were found in the new guide.

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

This PR adds a thorough and well-structured VEX walkthrough guide for Docker Hardened Images. The content is technically accurate and the before/after scan examples are clear and useful. Two style guide issues to address before merging.

[docker-agent]

[MEDIUM] RCE risk disclosure uses [!NOTE] callout instead of [!WARNING]

The callout advises Windows users to expose the Docker daemon on TCP without TLS, and explicitly states: "Exposing the daemon on TCP without TLS makes your system vulnerable to remote code execution attacks."

Per the Docker style guide, [!NOTE] is for "information that may not apply to all readers", while [!WARNING] is for "actions that may cause damage or data loss" and [!CAUTION] is for "serious risks". An RCE vulnerability is a serious risk — using [!NOTE] significantly understates the danger and may cause users to overlook the severity.

Suggested fix: Change > [!NOTE] to > [!WARNING] (or > [!CAUTION]).

[docker-agent]

[MEDIUM] "What's next" uses marketing-style "Topic: Description" bullet format

The bullet items use the format Topic: Description (e.g., Scan with other tools: Learn how..., VEX status reference: For status definitions...). The Docker style guide explicitly discourages this pattern as marketing-style copy and recommends simple, action-oriented descriptive bullets instead.

Suggested alternative — rewrite as direct action bullets, for example:

• Learn how to apply DHI VEX statements with [Trivy (VEX Hub) and Grype](/manuals/dhi/how-to/scan.md).
• If you build on top of a DHI, [create an exception using VEX](/manuals/scout/how-tos/create-exceptions-vex.md) to suppress CVEs in packages you add.