{"id":3300,"date":"2026-01-24T21:15:52","date_gmt":"2026-01-24T21:15:52","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/01\/24\/making-the-most-of-your-docker-hardened-images-enterprise-trial-part-2\/"},"modified":"2026-01-24T21:15:52","modified_gmt":"2026-01-24T21:15:52","slug":"making-the-most-of-your-docker-hardened-images-enterprise-trial-part-2","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/01\/24\/making-the-most-of-your-docker-hardened-images-enterprise-trial-part-2\/","title":{"rendered":"Making the Most of Your Docker Hardened Images Enterprise Trial \u2013 Part 2"},"content":{"rendered":"<h2 class=\"wp-block-heading\">Verifying Security and Compliance of Docker Hardened Images<\/h2>\n<p>In <a href=\"https:\/\/www.docker.com\/blog\/making-the-most-of-your-docker-hardened-images-trial-part-1\/\">Part 1<\/a> of this series, we migrated a Node.js service to Docker Hardened Images (DHI) and measured impressive results: 100% vulnerability elimination, 90% package reduction, and 41.5% size decrease. We extracted the SBOM and saw compliance labels for FIPS, STIG, and CIS.<\/p>\n<p>The numbers look compelling. But how do you <em>verify<\/em> these claims independently?<\/p>\n<p>Security tools earn trust through verification, not promises. When evaluating a security product for production, you need cryptographic proof. This is especially true for images that form the foundation of every container you deploy.This post walks through the verification process: signature validation, provenance analysis, compliance evidence examination, and SBOM analysis. We\u2019ll focus on practical verification you can run during your trial, with links to the <a href=\"https:\/\/docs.docker.com\/dhi\/\" rel=\"nofollow noopener\" target=\"_blank\">official DHI documentation<\/a> for deeper technical details. By the end, you\u2019ll have independently confirmed DHI\u2019s security posture and built confidence for a production scenario.<\/p>\n\n<h2 class=\"wp-block-heading\">Understanding Security Attestations available with Docker Hardened Images<\/h2>\n<p>Before diving into verification, you need to understand what you\u2019re verifying.<\/p>\n<p>Docker Hardened Images include <strong>attestations<\/strong>: cryptographically-signed metadata about the image\u2019s build process, contents, and compliance posture. These are signed statements that can be independently verified.<\/p>\n<div class=\"wp-block-ponyo-table style__default\">\n<table class=\"responsive-table\">\n<tbody class=\"wp-block-ponyo-table-body\">\n<tr class=\"wp-block-ponyo-table-row\">\n<td class=\"wp-block-ponyo-cell\">\n<p><span>Important<\/span><span>: If you\u2019ve pulled the image locally, you need to use the <\/span><span>registry:\/\/<\/span><span> prefix when working with attestations. This tells Docker Scout to look for attestations in the registry, not just the local image cache.<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>List all attestations for your hardened image:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\ndocker scout attestation list registry:\/\/&amp;lt;your-org-namespace&amp;gt;\/dhi-node:24.11-debian13-fips\n<\/pre>\n<\/div>\n<p>This shows 16 different attestation types:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\nhttps:\/\/slsa.dev\/provenance\/v0.2            SLSA provenance\nhttps:\/\/docker.com\/dhi\/fips\/v0.1            FIPS compliance\nhttps:\/\/docker.com\/dhi\/stig\/v0.1            STIG scan\nhttps:\/\/cyclonedx.org\/bom\/v1.6              CycloneDX SBOM\nhttps:\/\/spdx.dev\/Document                   SPDX SBOM\nhttps:\/\/scout.docker.com\/vulnerabilities    Scout vulnerabilities\nhttps:\/\/scout.docker.com\/secrets\/v0.1       Scout secret scan\nhttps:\/\/scout.docker.com\/virus\/v0.1         Scout virus\/malware\nhttps:\/\/scout.docker.com\/tests\/v0.1         Scout test report\nhttps:\/\/openvex.dev\/ns\/v0.2.0               OpenVEX\n...\n\n<\/pre>\n<\/div>\n<p>Each attestation is a JSON document describing a specific aspect of the image. The most critical attestations for verification:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>SLSA provenance<\/strong>: Build source, builder identity, and build process details<\/li>\n<li><strong>SBOM<\/strong>: Complete software bill of materials<\/li>\n<li><strong>FIPS compliance<\/strong>: Evidence of FIPS 140-3 certified cryptographic modules<\/li>\n<li><strong>STIG scan<\/strong>: Security Technical Implementation Guide compliance results<\/li>\n<li><strong>Vulnerability scan<\/strong>: CVE assessment<\/li>\n<li><strong>VEX report: <\/strong>CVE<strong> <\/strong>exploitability<\/li>\n<\/ul>\n<p>These attestations follow the <a href=\"https:\/\/in-toto.io\/\" rel=\"nofollow noopener\" target=\"_blank\">in-toto<\/a> specification, an open framework for supply chain security. Each attestation includes:<\/p>\n<ul class=\"wp-block-list\">\n<li>Subject: What the attestation describes (the container image)<\/li>\n<li>Predicate: The actual claims (FIPS certified, STIG compliant, etc.)<\/li>\n<li>Signature: Cryptographic signature from the builder<\/li>\n<\/ul>\n<p>Let\u2019s see how you can verify the signatures yourself.<\/p>\n<h2 class=\"wp-block-heading\">Verifying Attestations with Docker Scout<\/h2>\n<p>The attestations we\u2019re about to examine are cryptographically signed by Docker\u2019s build infrastructure. Docker Scout provides a simple, integrated approach that handles DHI attestations natively and without the hassle of managing public keys or certificate chains.To validate an attestation, simply append the \u2013verify flag, which provides explicit validation feedback. This process relies on cryptographic hashing: the digest is a hash of the attestation content, so even a single character change completely alters the hash. Moreover, the attestation\u2019s signature is cryptographically bound to the specific image digest it describes, guaranteeing that the metadata you\u2019re verifying corresponds exactly to the image you have and preventing substitution attacks.<\/p>\n<h3 class=\"wp-block-heading\">Retrieving an Attestation<\/h3>\n<p>To extract a specific attestation (like SLSA provenance), use the attestation get command with the full predicate type URI:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\ndocker scout attestation get registry:\/\/&amp;lt;your-org-namespace&amp;gt;\/dhi-node:24.11-debian13-fips \n  --predicate-type https:\/\/slsa.dev\/provenance\/v0.2 \n  --output provenance.json\n\n<\/pre>\n<\/div>\n<p>Success looks like this:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\n\u2713 SBOM obtained from attestation, 32 packages found\n\u2713 Provenance obtained from attestation\n\u2713 Report written to provenance.json\n\n<\/pre>\n<\/div>\n<p>The checkmarks confirm Docker Scout successfully retrieved and verified the attestation. Behind the scenes, Scout validated:<\/p>\n<ul class=\"wp-block-list\">\n<li>The attestation signature matches Docker\u2019s signing key<\/li>\n<li>The signature hasn\u2019t expired<\/li>\n<li>The attestation applies to this specific image digest<\/li>\n<li>The attestation hasn\u2019t been tampered with<\/li>\n<\/ul>\n<p>If signature verification fails, Scout returns an error and won\u2019t output the attestation file.To learn more about available predicate types, check out the <a href=\"https:\/\/docs.docker.com\/dhi\/how-to\/verify\/\" rel=\"nofollow noopener\" target=\"_blank\">DHI verification documentation<\/a>.<\/p>\n<h3 class=\"wp-block-heading\">Validating SLSA Provenance<\/h3>\n<p>Signatures prove attestations are authentic. Provenance shows <em>where the image came from<\/em>.<\/p>\n<p><a href=\"https:\/\/docs.docker.com\/dhi\/core-concepts\/slsa\/\" rel=\"nofollow noopener\" target=\"_blank\">SLSA (Supply-chain Levels for Software Artifacts)<\/a> is a security framework developed by Google, the Linux Foundation, and other industry partners. It defines levels of supply chain security maturity, from SLSA 0 (no guarantees) to SLSA 4 (highest assurance).<\/p>\n<p>Docker Hardened Images target SLSA 3, which requires:<\/p>\n<ul class=\"wp-block-list\">\n<li>Build process fully scripted\/automated<\/li>\n<li>All build steps defined in version control<\/li>\n<li>Provenance generated automatically by build service<\/li>\n<li>Provenance includes source, builder, and build parameters<\/li>\n<\/ul>\n<p>Using our previously extracted SLSA provenance.json, we can check the source repository and commit hash:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\njq '.predicate.invocation.environment.github_repository' provenance.json\n<\/pre>\n<\/div>\n<p>Output:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\n\"docker-hardened-images\/definitions\"\njq '.predicate.invocation.environment.github_sha1' provenance.json\n\n<\/pre>\n<\/div>\n<p>Output:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\n\"698b367344efb3a7d443508782de331a84216ae4\"\n<\/pre>\n<\/div>\n<p>Similarly, you can see exactly what <em>GitHub Actions workflow<\/em> produced this image.<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\njq '.predicate.builder.id' provenance.json\n\n<\/pre>\n<\/div>\n<p>Output:<\/p>\n<p>\u201chttps:\/\/github.com\/docker-hardened-images\/definitions\/actions\/runs\/18930640220\/attempts\/1\u201d<\/p>\n<h2 class=\"wp-block-heading\">For DHI Enterprise Users: Verifying High-Assurance Claims<\/h2>\n<p>While the free hardened images are built with security best practices, DHI Enterprise images carry the specific certifications required for FedRAMP, HIPAA, and financial audits. Here is how to verify those high-assurance claims.<\/p>\n<h3 class=\"wp-block-heading\">FIPS 140-3 Validation<\/h3>\n<p>FIPS (Federal Information Processing Standard) 140-3 is a U.S. government standard for cryptographic modules. Think of it as a certification that proves the cryptography in your software has been tested and validated by independent labs against federal requirements.<\/p>\n<p>If you\u2019re building software for government agencies, financial institutions, or healthcare providers, FIPS compliance is often mandatory: without it, your software can\u2019t be used in those environments!<\/p>\n<p>Check if the image includes FIPS-certified cryptography:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\ndocker scout attestation get registry:\/\/&amp;lt;your-org-namespace&amp;gt;\/dhi-node:24.11-debian13-fips \n  --predicate-type https:\/\/docker.com\/dhi\/fips\/v0.1 \n  --output fips-attestation.json\n\n<\/pre>\n<\/div>\n<p>Output:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\n{\n  \"certification\": \"CMVP #4985\",\n  \"certificationUrl\": \"https:\/\/csrc.nist.gov\/projects\/cryptographic-module-validation-program\/certificate\/4985\",\n  \"name\": \"OpenSSL FIPS Provider\",\n  \"package\": \"pkg:dhi\/openssl-provider-fips@3.1.2\",\n  \"standard\": \"FIPS 140-3\",\n  \"status\": \"active\",\n  \"sunsetDate\": \"2030-03-10\",\n  \"version\": \"3.1.2\"\n}\n\n<\/pre>\n<\/div>\n<p>The certificate number (4985) is the key piece. This references a specific FIPS validation in the official <a href=\"https:\/\/csrc.nist.gov\/projects\/cryptographic-module-validation-program\/validated-modules\/search\" rel=\"nofollow noopener\" target=\"_blank\">NIST CMVP database<\/a>.<\/p>\n<h3 class=\"wp-block-heading\">STIG Compliance<\/h3>\n<p>STIG (Security Technical Implementation Guide) is the Department of Defense\u2019s (DoD) checklist for securing systems. It\u2019s a comprehensive security configuration standard needed for deploying software for defense or government work.<br \/>DHI images undergo STIG scanning before release. Docker uses a custom STIG based on the DoD\u2019s General Operating System Security Requirements Guide. Each scan checks dozens of security controls and reports findings. You can extract and review STIG scan results:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\ndocker scout attestation get registry:\/\/&amp;lt;your-org-namespace&amp;gt;\/dhi-node:24.11-debian13-fips \n  --predicate-type https:\/\/docker.com\/dhi\/stig\/v0.1 \n  --output stig-attestation.json\n\n<\/pre>\n<\/div>\n<p>Check the STIG scan summary:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\njq '.predicate[0].summary' stig-attestation.json\n<\/pre>\n<\/div>\n<p>Output:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\n{\n  \"failedChecks\": 0,\n  \"passedChecks\": 91,\n  \"notApplicableChecks\": 107,\n  \"totalChecks\": 198,\n  \"defaultScore\": 100,\n  \"flatScore\": 91\n}\n\n<\/pre>\n<\/div>\n<p>This shows DHI passed all 91 applicable STIG controls with zero failed checks and a 100% score. The 107 \u201cnotApplicableChecks\u201d typically refer to controls that are irrelevant to the specific minimal container environment or its configuration. For a complete list of STIG controls and DHI compliance details, including how to extract and view the full STIG scan report, see the <a href=\"https:\/\/docs.docker.com\/dhi\/core-concepts\/stig\/\" rel=\"nofollow noopener\" target=\"_blank\">DHI STIG documentation<\/a>.<\/p>\n<h3 class=\"wp-block-heading\">CIS Benchmark Hardening<\/h3>\n<p><a href=\"https:\/\/docs.docker.com\/dhi\/core-concepts\/cis\/\" rel=\"nofollow noopener\" target=\"_blank\">CIS (Center for Internet Security) Benchmarks<\/a> are security configuration standards created by security professionals across industries. Much like STIGs, they represent consensus best practices, but unlike government-mandated frameworks (FIPS, STIG), CIS benchmarks are community-developed.<\/p>\n<p>CIS compliance isn\u2019t legally required, but it demonstrates you\u2019re following industry-standard security practices\u2014valuable for customer trust and audit preparation.<\/p>\n<p>You can verify CIS compliance through image labels:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\ndocker inspect &amp;lt;your-org-namespace&amp;gt;\/dhi-node:24.11-debian13-fips | \n  jq '.[0].Config.Labels[\"com.docker.dhi.compliance\"]'\n\n<\/pre>\n<\/div>\n<p>Output: \u201cfips,stig,cis\u201d<\/p>\n<p>The CIS label indicates that an image is hardened according to the <a href=\"https:\/\/www.cisecurity.org\/benchmark\/docker\" rel=\"nofollow noopener\" target=\"_blank\">CIS Docker Benchmark<\/a>.<\/p>\n<h2 class=\"wp-block-heading\">What exactly is a SBOM used for?<\/h2>\n<p>Compliance frameworks tell you what standards you meet. The SBOM tells you what\u2019s actually in your container\u2014and that\u2019s where the real security work begins.<\/p>\n<h3 class=\"wp-block-heading\">Identifying Transitive Dependencies<\/h3>\n<p>When you add a package to your project, you see the direct dependency. What you don\u2019t see: that package\u2019s dependencies, and <em>their<\/em> dependencies, and so on. This is the transitive dependency problem.<\/p>\n<p>A vulnerability in a transitive dependency you\u2019ve never heard of can compromise your entire application. Real example: the Log4Shell vulnerability affected millions of applications because Log4j was a transitive dependency buried several levels deep in dependency chains.<\/p>\n<p>Most vulnerabilities hide in transitive dependencies because:<\/p>\n<ol class=\"wp-block-list\">\n<li>Developers don\u2019t know they exist<\/li>\n<li>They\u2019re not updated when the direct dependency updates<\/li>\n<li>Scanning tools miss them without an SBOM<\/li>\n<\/ol>\n<p>Minimal images reduce this risk dramatically. Fewer packages = fewer transitive dependencies = smaller attack surface.<\/p>\n<p>Compare dependency counts:<\/p>\n<ul class=\"wp-block-list\">\n<li>Official Node.js image: 321 packages, ~1,500 dependency relationships<\/li>\n<li>DHI Node.js image: 32 packages, ~150 dependency relationships<\/li>\n<\/ul>\n<p>90% reduction in packages means 90% reduction in transitive dependency risk.<\/p>\n<h3 class=\"wp-block-heading\">Scanning for Known (Exploitable) Vulnerabilities<\/h3>\n<p>With the SBOM extracted, scan for known vulnerabilities:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\ndocker scout cves registry:\/\/&amp;lt;your-org-namespace&amp;gt;\/dhi-node:24.11-debian13-fips\n<\/pre>\n<\/div>\n<p>Output:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\nTarget: &amp;lt;your-org-namespace&amp;gt;\/dhi-node:24.11-debian13-fips\n\n  0C     0H     0M     8L\n\n8 vulnerabilities found in 2 packages\n  CRITICAL  0\n  HIGH      0\n  MEDIUM    0\n  LOW       8\n\n<\/pre>\n<\/div>\n<p>Zero critical, high, or medium severity vulnerabilities. Docker Scout cross-references the SBOM against multiple vulnerability databases (NVD, GitHub Security Advisories, etc.).This is the payoff of minimal images: fewer packages means fewer potential vulnerabilities. The official Node.js image had 25 CVEs across CRITICAL, HIGH, and MEDIUM severities. The hardened version has zero actionable vulnerabilities\u2014not because vulnerabilities were patched, but because vulnerable packages were removed entirely.<\/p>\n<h3 class=\"wp-block-heading\">Understanding Exploitability with VEX<\/h3>\n<p>Not all CVEs are relevant to your deployment. A vulnerability in a library function your application never calls, or a flaw in a service that isn\u2019t running, doesn\u2019t pose real risk.\u00a0Docker Hardened Images include signed VEX attestations that identify which reported CVEs are not actually exploitable in the image\u2019s runtime context. This helps you distinguish between CVEs that exist in a package (reported), and CVEs that can <em>actually be exploited<\/em> given how the package is used in this specific image (exploitable). <strong>In other words, VEX reduces false positives.<\/strong><\/p>\n<div class=\"wp-block-ponyo-table style__default\">\n<table class=\"responsive-table\">\n<tbody class=\"wp-block-ponyo-table-body\">\n<tr class=\"wp-block-ponyo-table-row\">\n<td class=\"wp-block-ponyo-cell\">\n<p><span>Docker Scout applies VEX statements automatically when scanning DHI images: when you run <\/span><span>docker scout cves<\/span><span>, Scout uses VEX attestations to suppress vulnerabilities marked as non-exploitable.<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>You can see which CVEs have been evaluated with this command:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\ndocker scout attestation get registry:\/\/&amp;lt;your-org-namespace&amp;gt;\/dhi-node:24.11-debian13-fips \n  --predicate-type https:\/\/openvex.dev\/ns\/v0.2.0 \n  --output vex.json\n\n<\/pre>\n<\/div>\n<h3 class=\"wp-block-heading\">License Compliance Analysis<\/h3>\n<p>When you use open source software, you\u2019re bound by license terms. Some licenses (MIT, Apache) are permissive and you can use them freely, even in commercial products. Others (GPL, AGPL) are copyleft: they require you to release your source code if you distribute software using them.<\/p>\n<p>SBOMs make license compliance visible. Without an SBOM, you\u2019re blind to what licenses your containers include.<\/p>\n<p>Export the SBOM in SPDX format:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\ndocker scout sbom registry:\/\/&amp;lt;your-org-namespace&amp;gt;\/dhi-node:24.11-debian13-fips \n  --format spdx \n  --output node-sbom-spdx.json\n\n<\/pre>\n<\/div>\n<p>Analyze license distribution:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\njq '.packages[].licenseConcluded' node-sbom-spdx.json | \n  sort | uniq -c | sort -rn\n\n<\/pre>\n<\/div>\n<p>Output:<\/p>\n<div class=\"wp-block-syntaxhighlighter-code \">\n<pre class=\"brush: plain; title: ; notranslate\">\n15 \"MIT\"\n8 \"Apache-2.0\"\n5 \"GPL-2.0-or-later\"\n2 \"BSD-3-Clause\"\n1 \"OpenSSL\"\n1 \"NOASSERTION\"\n\n<\/pre>\n<\/div>\n<p>In this example:<\/p>\n<ul class=\"wp-block-list\">\n<li>\u2705 MIT and Apache-2.0 are permissive (safe for commercial use)<\/li>\n<li>\u26a0\ufe0f GPL-2.0-or-later requires review (is this a runtime dependency or build tool?)<\/li>\n<li>\u26a0\ufe0f NOASSERTION needs investigation<\/li>\n<\/ul>\n<h2 class=\"wp-block-heading\">Conclusion: What You\u2019ve Proven<\/h2>\n<p>You\u2019ve independently verified critical security claims Docker makes about Hardened Images:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>Authenticity<\/strong>: Cryptographic signatures prove images are genuine and unmodified<\/li>\n<li><strong>Provenance<\/strong>: SLSA attestations trace builds to specific source commits in public repositories<br \/><strong>Compliance<\/strong>: FIPS certificate, STIG controls passed, and CIS benchmarks met<\/li>\n<li><strong>Security posture<\/strong><\/li>\n<\/ul>\n<p>Every claim you verified (except CIS) has a corresponding attestation you can check yourself, audit, and validate in your CI\/CD pipeline.<\/p>\n<p>You can customize a Docker Hardened Image (DHI) to suit your specific needs using the Docker Hub UI. This allows you to select a base image, add packages, add OCI artifacts (such as custom certificates or additional tools), and configure settings. In addition, the build pipeline ensures that your customized image is built securely and includes attestations.<\/p>\n<p>In Part 3, we\u2019ll cover how to customize Docker Hardened Images to suit your specific needs, while keeping all the benefits we just explored.<\/p>\n<p>You\u2019ve confirmed DHI delivers on security promises. Next, we\u2019ll make it operational.<\/p>\n\n<p>If you missed reading part 1, where we discussed how you can get to 100% vulnerability elimination and 90% package reduction, read the <a href=\"https:\/\/www.docker.com\/blog\/making-the-most-of-your-docker-hardened-images-trial-part-1\/\">blog here<\/a>. <\/p>","protected":false},"excerpt":{"rendered":"<p>Verifying Security and Compliance of Docker Hardened Images In Part 1 of this series, we migrated a Node.js service to [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":94,"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-3300","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\/3300","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=3300"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/3300\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/94"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=3300"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=3300"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=3300"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}