{"id":2815,"date":"2025-11-14T17:11:43","date_gmt":"2025-11-14T17:11:43","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/11\/14\/making-the-most-of-your-docker-hardened-images-trial-part-1\/"},"modified":"2025-11-14T17:11:43","modified_gmt":"2025-11-14T17:11:43","slug":"making-the-most-of-your-docker-hardened-images-trial-part-1","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/11\/14\/making-the-most-of-your-docker-hardened-images-trial-part-1\/","title":{"rendered":"Making the Most of Your Docker Hardened Images Trial \u2013 Part 1"},"content":{"rendered":"<h2 class=\"wp-block-heading\">First steps: Run your first secure, production-ready image<\/h2>\n<p>Container base images form the foundation of your application security. When those foundations contain vulnerabilities, every service built on top inherits the same risk.\u00a0<\/p>\n<p><strong>Docker Hardened Images<\/strong> addresses this at the source. These are continuously-maintained, minimal base images designed for security: stripped of unnecessary packages, patched proactively, and built with supply chain attestation. Instead of maintaining your own hardened bases or accepting whatever vulnerabilities ship with official images, you get production-ready foundations with near-zero CVEs and compliance metadata baked in.<\/p>\n\n<h3 class=\"wp-block-heading\">What to Expect from Your 30-days Trial?<\/h3>\n<p>You\u2019ve got 30 days to evaluate whether Docker Hardened Images fits your environment. That\u2019s enough time to answer the crucial question: <em>Would this reduce our security debt without adding operational burden?<\/em><\/p>\n<p>It\u2019s important to note that while DHI provides production\u2011grade images, this trial isn\u2019t about rushing into production. Its primary purpose is educational: to let you experience the benefits of a hardened base image for supply\u2011chain security by testing it with the actual services in your stack and measuring the results.<\/p>\n<p>By the end of the trial, you should have <strong>concrete results<\/strong>:\u00a0<\/p>\n<ul class=\"wp-block-list\">\n<li>CVE counts before and after,\u00a0<\/li>\n<li>engineering effort required per image migration, and<\/li>\n<li>whether your team would actually use this.\u00a0<\/li>\n<\/ul>\n<p>Testing with real projects always outshines promises.<\/p>\n<p>The <a href=\"https:\/\/docs.docker.com\/dhi\/get-started\/\" rel=\"nofollow noopener\" target=\"_blank\">DHI quickstart guide<\/a> walks through the actions. This post covers what the docs don\u2019t: the confusion points you may hit, what metrics actually matter, and how to evaluate results easily.<\/p>\n\n<h3 class=\"wp-block-heading\">Step 1: Understanding the DHI Catalog\u00a0<\/h3>\n<p>To get started with your Free trial, you must be an organization owner or editor. This means you will get your own Repository where you can mirror images, but we\u2019ll get back to this later.<\/p>\n<p>If you are familiar with Docker Hub, the DHI catalog should already look familiar:<\/p>\n\n<div class=\"wp-block-ponyo-image\">\n            <img data-opt-id=1719970333  fetchpriority=\"high\" decoding=\"async\" width=\"1756\" height=\"1108\" src=\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/DHI-Trial-4-1.png\" class=\"attachment-full size-full\" alt=\"DHI Trial 4 1\" title=\"- DHI Trial 4 1\" \/>\n    <\/div>\n\n<p>The most obvious difference are the little lock icons indicating a Hardened Image. But what exactly does it mean?<\/p>\n<p>The core concept behind hardened images is that they present a <strong>minimal attack surface<\/strong>, which in practical terms means that only the strict minimum is included (as opposed to \u201cbattery-included\u201d distributions like Ubuntu or Debian).\u00a0<\/p>\n<p>Think of it like this: The hardened images maintain compatibility with the distro\u2019s core characteristics (libc, filesystem hierarchy, package names) while removing the convenience layers that increase attack surface (package managers, extra utilities, debugging tools).<\/p>\n<p>So the \u201cOS\u201d designation you can see below every DHI means this image is built on top of those\u00a0 distributions (uses the same base operating system), but with security hardening and package minimization applied.<\/p>\n<div class=\"wp-block-ponyo-image\">\n            <img data-opt-id=2026062074  fetchpriority=\"high\" decoding=\"async\" width=\"1242\" height=\"742\" src=\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/DHI-Trial-3.png\" class=\"attachment-full size-full\" alt=\"DHI Trial 3\" title=\"- DHI Trial 3\" \/>\n    <\/div>\n<p>Sometimes, you <em>need<\/em> these convenient Linux utilities, for development or testing purposes.\u00a0<\/p>\n<p>This is where <strong>variants<\/strong> come into play.<\/p>\n<div class=\"wp-block-ponyo-image\">\n            <img data-opt-id=1221943301  data-opt-src=\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/DHI-Trial-2.png\"  decoding=\"async\" width=\"1574\" height=\"908\" src=\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" class=\"attachment-full size-full\" alt=\"DHI Trial 2\" title=\"- DHI Trial 2\" \/>\n    <\/div>\n<p>The catalog shows multiple variants for each base image: standard versions, (dev) versions, (fips) versions.\u00a0<br \/>The variant choice matters for security posture. If you can run your application without a package manager in the final image (using multi-stage builds, for example), always choose the standard variant. Fewer tools in the container means fewer potential vulnerabilities.<\/p>\n<p>Here\u2019s what they mean:\u00a0<\/p>\n<p>Standard variants (e.g., node-base:24-debian13):<\/p>\n<ul class=\"wp-block-list\">\n<li>Minimal runtime images<\/li>\n<li>No package managers (apk, apt, yum removed)<\/li>\n<li>Production-ready<\/li>\n<li>Smallest attack surface<\/li>\n<\/ul>\n<p>Fips variants (e.g., node-base:24-debian13-fips):<br \/>FIPS variants come in both runtime and build-time variants. These variants use cryptographic modules that have been validated under FIPS 140, a U.S. government standard for secure cryptographic operations. They are required for highly-regulated environments<\/p>\n<p>Dev variants (e.g., node-base:24-debian13-dev):<\/p>\n<ul class=\"wp-block-list\">\n<li>Include package managers for installing additional dependencies<\/li>\n<li>Useful during development or when you need to add packages at build time<\/li>\n<li>Larger attack surface (but still hardened)<\/li>\n<li>Not recommended for production<\/li>\n<\/ul>\n<p>The catalog includes dozens of base images: language runtimes (Python, Node, Go), distros (Alpine, Ubuntu, Debian), specialized tools (nginx, Redis).\u00a0<br \/>Instead of trying to evaluate everything from the start, start narrow by picking <strong>one image<\/strong> (that you use frequently (Alpine, Python, Node are common starting points) for the first test.<br \/>What \u201cEntitlements\u201d and \u201cMirroring\u201d Actually Mean<\/p>\n<p>You can\u2019t just \u2018docker pull\u2019 directly from Docker\u2019s DHI catalog. Instead, you mirror images to your organization\u2019s namespace first. Here\u2019s the workflow:<\/p>\n<ol class=\"wp-block-list\">\n<li>Your trial grants your organization access to a certain number of DHIs through mirroring: these are called <strong>entitlements<\/strong>.<\/li>\n<li>As an organization owner, you first create a copy of the DHI image in your namespace (e.g., yourorg\/dhi-node), which means you are <strong>mirroring the image<\/strong> and will automatically receive new updates in your repository.<\/li>\n<li>Your team pulls from your org\u2019s namespace, not Docker\u2019s.<\/li>\n<\/ol>\n<p>Mirroring takes a few minutes and copies all available tags. Once complete, the image appears in your organization\u2019s repositories like any other image.<\/p>\n<p>Why this model? Two reasons:<\/p>\n<ul class=\"wp-block-list\">\n<li>Access control: Your org admins control which hardened images your team can use<\/li>\n<li>Availability: Mirrored images remain available even if your subscription changes<\/li>\n<\/ul>\n<p>The first time you encounter \u201cmirror this image to your repository,\u201d it feels like unnecessary friction. But once you realize it\u2019s a one-time setup per base image (not per tag), it makes sense. You mirror node-base once and get access to all current and future Node versions<\/p>\n<p>Now that you\u2019ve mirrored a hardened image, it\u2019s time to test it with an actual project. The goal is to discover friction points early, when stakes are low.<\/p>\n<div class=\"wp-block-ponyo-image\">\n            <img data-opt-id=1907299892  data-opt-src=\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/DHI-Trial-1.png\"  decoding=\"async\" width=\"1528\" height=\"1028\" src=\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" class=\"attachment-full size-full\" alt=\"DHI Trial 1\" title=\"- DHI Trial 1\" \/>\n    <\/div>\n\n<h3 class=\"wp-block-heading\">Step 2: Your First Real Migration Test<\/h3>\n<p>Choose a project that is:<\/p>\n<ul class=\"wp-block-list\">\n<li>Simple enough to debug quickly if something breaks (fewer moving parts)<\/li>\n<\/ul>\n<ul class=\"wp-block-list\">\n<li>Real enough to represent actual workloads<\/li>\n<li>Representative of your stack<\/li>\n<\/ul>\n<h4 class=\"wp-block-heading\">Drop-In Replacement<\/h4>\n<p>Open your Dockerfile and locate the FROM instruction. The migration is straightforward:<\/p>\n<p class=\"has-mono-font-family\">\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\n# Before\nFROM node:22-bookworm-slim\n# After\nFROM &lt;your-org-namespace&gt;\/dhi-node:22-debian13-fips\n<\/pre>\n<\/div>\n<\/p><p>Replace your organization\u2019s namespace and choose the appropriate tag. If you were using a generic tag like node:22, switch to a specific version tag from the hardened catalog (like 22-debian13-fips). Pinning to specific versions is a best practice anyway \u2013 hardened images just make it more explicit.<\/p>\n<p>For\u00a0 other language runtimes, the pattern is similar:<\/p>\n<p class=\"has-mono-font-family\"># Python example<br \/>FROM python:3.12-slim<br \/># becomes<br \/>FROM &lt;your-org-namespace&gt;\/dhi-python-base:3.12-bookworm<\/p>\n<p class=\"has-mono-font-family\"># Node example<br \/>FROM node:20-alpine<br \/># becomes<br \/>FROM &lt;your-org-namespace&gt;\/dhi-node-base:20.18-alpine3.20<\/p>\n<h4 class=\"wp-block-heading\">Build and Test<\/h4>\n<p>Build the image with your new base:<\/p>\n<p class=\"has-mono-font-family\">docker build . -t my-service-hardened<\/p>\n<p>Watch the build output: if your Dockerfile assumes certain utilities exist (like wget, curl, or package managers), <strong>the build may fail<\/strong>. This is expected. Hardened bases strip unnecessary tools to reduce attack surface. Here are some common build failures and fixes:<\/p>\n<p>Missing package manager (apt, yum):<\/p>\n<ul class=\"wp-block-list\">\n<li>If you\u2019re installing packages in your Dockerfile, you\u2019ll need to use the (dev) variant, and probably switch to a multi-stage build (install dependencies in a builder stage using a dev variant, then copy artifacts to the minimal runtime stage use a fips hardened base image variant)<\/li>\n<\/ul>\n<p>Missing utilities (wget, curl, bash):<\/p>\n<ul class=\"wp-block-list\">\n<li>Network tools are removed unless you\u2019re using a debug variant<\/li>\n<li>Solution: same as above, install what you need explicitly in a builder stage, or verify you actually need those tools at runtime<\/li>\n<\/ul>\n<p>Different default user:<\/p>\n<ul class=\"wp-block-list\">\n<li>Some hardened images run as non-root by default<\/li>\n<li>If your application expects to write to certain directories, you may need to adjust permissions or use USER directives appropriately<\/li>\n<\/ul>\n<p>For my Node.js test, the build succeeded without changes. The hardened Node base contained everything the runtime needed \u2013 npm dependencies installed normally, and the packages removed were system utilities my application never touched.<\/p>\n<h4 class=\"wp-block-heading\">Verify It Runs<\/h4>\n<p>Build success doesn\u2019t mean runtime success. Start the container and verify it behaves correctly:<\/p>\n<p class=\"has-mono-font-family\">docker run \u2013rm -p 3000:3000 my-service-hardened<\/p>\n<p>Test the service:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Does it start without errors?<\/li>\n<li>Do API endpoints respond correctly?<\/li>\n<li>Are logs written as expected?<\/li>\n<li>Can it connect to databases or external services?<\/li>\n<\/ul>\n<h3 class=\"wp-block-heading\">Step 3: Comparing What Changed<br \/><\/h3>\n<p>Before moving to measurement, build the original version alongside the hardened one:<\/p>\n<p class=\"has-mono-font-family\"># Switch to your main branch<br \/>git checkout main<br \/># Build original version<br \/>docker build . -t my-service-original<br \/># Switch back to your test branch with hardened base<br \/>git checkout dhi-test<br \/># Build hardened version<br \/>docker build . -t my-service-hardened<\/p>\n<p>Now you have two images to compare: one with the official base, one with the hardened base. Now comes the evaluation: what actually improved, and by how much?<\/p>\n\n<h4 class=\"wp-block-heading\">Docker Scout<\/h4>\n\n<p>Docker Scout compares images and reports on vulnerabilities, package differences, and size changes. If you haven\u2019t enrolled your organization with Scout yet, you\u2019ll need to do that first (it\u2019s free for the comparison features we\u2019re using).<\/p>\n<p>Run the comparison (here we are comparing Node base images) :<\/p>\n<p class=\"has-mono-font-family\">docker scout compare \u2013to &lt;your-org-namespace&gt;\/dhi-node:24.11-debian13-fips node:24-bookworm-slim<\/p>\n<p>Scout outputs a detailed breakdown. Here\u2019s what we found when comparing the official Node.js image to the hardened version.<\/p>\n<h4 class=\"wp-block-heading\">1. Vulnerability Reduction<\/h4>\n<p>The Scout output shows CVE counts by severity:<\/p>\n<p class=\"has-mono-font-family\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Official Node\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Hardened DHI<br \/>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a024-bookworm-slim \u00a0 \u00a0 \u00a0 24.11-debian13-fips<br \/>Critical\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0<br \/>High\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0<br \/>Medium\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 1\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0\u00a0 \u2190 eliminated<br \/>Low \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 24 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0\u00a0 \u2190 eliminated<br \/>Total \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 25 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0<\/p>\n<p>The hardened image achieved complete vulnerability elimination. While the official image already had zero Critical\/High CVEs (good baseline), it contained 1 Medium and 24 Low severity issues \u2013 all eliminated in the hardened version.<br \/>Medium and Low severity vulnerabilities matter for compliance frameworks. If you\u2019re pursuing SOC2, ISO 27001, or similar certifications (especially in regulated industries with strict security standards), demonstrating zero CVEs across all severity levels significantly simplifies audits.<\/p>\n<h4 class=\"wp-block-heading\">2. Package Reduction\u00a0<\/h4>\n<p>Scout shows a dramatic difference in package count:<\/p>\n<p class=\"has-mono-font-family\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Official Node\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Hardened DHI<br \/>Total packages\u00a0 \u00a0 \u00a0 \u00a0 321\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 32<br \/>Reduction \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u2014\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 289 packages (90%)<\/p>\n<p>The hardened image removed 289 packages including:<\/p>\n<ul class=\"wp-block-list\">\n<li>apt (package manager)<\/li>\n<li>gcc-12 (entire compiler toolchain)<\/li>\n<li>perl (scripting language)<\/li>\n<li>bash (replaced with minimal shell)<\/li>\n<li>dpkg-dev (Debian package tools)<\/li>\n<li>gnupg2, gzip, bzip2 (compression and crypto utilities)<\/li>\n<li>dozens of libraries and system utilities<\/li>\n<\/ul>\n<p>These are tools your Node.js application never uses at runtime. Removing them drastically reduces attack surface: 90% fewer packages means 90% fewer potential targets for exploitation.<br \/>This is important because even if packages have no CVEs today, they represent future risk. Every utility, library, or tool in your image could become a vulnerability tomorrow. The hardened base eliminates that entire category of risk.<\/p>\n<h4 class=\"wp-block-heading\">3. Size Difference<\/h4>\n<p>Scout reports image sizes:<\/p>\n<p class=\"has-mono-font-family\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Official Node\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Hardened DHI<br \/>Image size\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 82 MB\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 48 MB<br \/>Reduction \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u2014\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 34 MB (41.5%)<\/p>\n<p>The hardened image is 41.5% smaller \u2013 that\u2019s <strong>34 MB saved per image<\/strong>. For a single service, this might seem minor. But multiply across dozens or hundreds of microservices, and the benefits start to become obvious: faster pulls, lower storage costs, and reduced network transfer.<\/p>\n<h4 class=\"wp-block-heading\">4. Extracting and Reading the SBOM<br \/><\/h4>\n<p>One of the most valuable compliance features is the embedded SBOM (Software Bill of Materials). Unlike many images where you\u2019d need to generate the SBOM yourself, hardened images include it automatically.<\/p>\n<p>Extract the SBOM to see every package in the image:<\/p>\n<p class=\"has-mono-font-family\">docker scout sbom &lt;your-org-namespace&gt;\/dhi-node:24.11-debian13-fips \u2013format list<\/p>\n<p>This outputs a complete package inventory:<\/p>\n<p class=\"has-mono-font-family\">Name\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Version\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Type<br \/>base-files\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 13.8+deb13u1 \u00a0 \u00a0 deb<br \/>ca-certificates \u00a0 \u00a0 \u00a0 20250419 \u00a0 \u00a0 \u00a0 \u00a0 deb<br \/>glibc \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 2.41-12\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 deb<br \/>nodejs\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 24.11.0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 dhi<br \/>openssl \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 3.5.4\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 dhi<br \/>openssl-provider-fips 3.1.2\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 dhi<br \/>\u2026<\/p>\n<p>The Type column shows where packages came from:<\/p>\n<ul class=\"wp-block-list\">\n<li>deb: Debian system packages<\/li>\n<li>dhi: Docker Hardened Images custom packages (like FIPS-certified OpenSSL)<\/li>\n<li>docker: Docker-managed runtime components<\/li>\n<\/ul>\n<p>The SBOM includes name, version, license, and package URL (purl) for each component \u2013 everything needed for vulnerability tracking and compliance reporting.<br \/>You can can easily the SBOM in SPDX or CycloneDX format for ingestion by a vulnerability tracking tools:<\/p>\n<p class=\"has-mono-font-family\"># SPDX format (widely supported)<br \/>docker scout sbom &lt;your-org&gt;\/dhi-node:24.11-debian13-fips <br \/>\u00a0\u00a0\u2013format spdx <br \/>\u00a0\u00a0\u2013output node-sbom.json<br \/># CycloneDX format (OWASP standard)<br \/>docker scout sbom &lt;your-org&gt;\/dhi-node:24.11-debian13-fips <br \/>\u00a0\u00a0\u2013format cyclonedx <br \/>\u00a0\u00a0\u2013output node-sbom-cyclonedx.json<\/p>\n<p>Beyond the SBOM, hardened images include 17 different attestations covering SLSA provenance, FIPS compliance, STIG scans, vulnerability scans, and more. We\u2019ll explore how to verify and use these attestations in Part 2 of this blog series.<\/p>\n<h3 class=\"wp-block-heading\">Trust, But Verify<\/h3>\n<p>You\u2019ve now:<br \/><img data-opt-id=2123961905  data-opt-src=\"https:\/\/s.w.org\/images\/core\/emoji\/15.0.3\/72x72\/2705.png\"  decoding=\"async\" src=\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" alt=\"\u2705\" class=\"wp-smiley\" \/> Eliminated 100% of vulnerabilities (25 CVEs \u2192 0)<br \/><img data-opt-id=2123961905  data-opt-src=\"https:\/\/s.w.org\/images\/core\/emoji\/15.0.3\/72x72\/2705.png\"  decoding=\"async\" src=\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" alt=\"\u2705\" class=\"wp-smiley\" \/> Reduced attack surface by 90% (321 packages \u2192 32)<br \/><img data-opt-id=2123961905  data-opt-src=\"https:\/\/s.w.org\/images\/core\/emoji\/15.0.3\/72x72\/2705.png\"  decoding=\"async\" src=\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" alt=\"\u2705\" class=\"wp-smiley\" \/> Shrunk image size by 41.5% (82 MB \u2192 48 MB)<br \/><img data-opt-id=2123961905  data-opt-src=\"https:\/\/s.w.org\/images\/core\/emoji\/15.0.3\/72x72\/2705.png\"  decoding=\"async\" src=\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" alt=\"\u2705\" class=\"wp-smiley\" \/> Extracted the SBOM for compliance tracking<\/p>\n<p>The results look good on paper, but verification builds confidence for production. But how do you <em>verify<\/em> these security claims independently? In Part 2, we\u2019ll explore:<\/p>\n<ul class=\"wp-block-list\">\n<li>Cryptographic signature verification on all attestations<\/li>\n<li>Build provenance traced to public GitHub source repositories<\/li>\n<li>Deep-dive into FIPS, STIG, and CIS compliance evidence<\/li>\n<li>SBOM-driven vulnerability analysis with exploitability context<\/li>\n<\/ul>\n<p>View related documentation:<\/p>\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/docs.docker.com\/dhi\/get-started\/\" rel=\"nofollow noopener\" target=\"_blank\">Docker Hardened Images: Get Started<\/a><\/li>\n<li><a href=\"https:\/\/hub.docker.com\/hardened-images\/catalog\" rel=\"nofollow noopener\" target=\"_blank\">Docker Hardened Images catalog<\/a><\/li>\n<li><a href=\"https:\/\/docs.docker.com\/scout\/quickstart\/\" rel=\"nofollow noopener\" target=\"_blank\">Docker Scout Quickstart<\/a><\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>First steps: Run your first secure, production-ready image Container base images form the foundation of your application security. When those [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2816,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[4],"tags":[],"class_list":["post-2815","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-docker"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/2815","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=2815"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/2815\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/2816"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=2815"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=2815"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=2815"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}