Are Free Hardened Container Images Good Enough for Production?

For many teams, yes: a free hardened image is a better base than a full distribution image, and for that layer it is often enough. It is not the end of the job. The low CVE count holds only if you rebuild often, it covers only the bottom layer, and free tiers rarely include a fix SLA or support.

So the useful question is not "free or paid" but "what must my base image strategy guarantee, and who is on the hook for each guarantee?" This post works through it criterion by criterion and ends with a decision table.

Key takeaways

• Hardened means a set of properties, not a label. Minimal packages, no shell or package manager at runtime, a non root user, signatures, an SBOM and build provenance. Check each one; do not take the word on trust.
• A CVE count is a snapshot. An image that scans clean today accumulates findings as new advisories land. What matters is rebuild cadence, how quickly fixed images are published, and whether you actually pull and redeploy them.
• The base layer is usually the smaller problem. Most findings in a production image tend to come from the language packages and binaries you add on top. A hardened base does nothing for those.
• Free tiers trade guarantees for price. Expect the images and their metadata. Do not expect a contractual fix SLA, FIPS validated variants, extended support past upstream end of life, customisation or someone to call.
• SLSA Build Level 3 proves how an image was built, not what is inside it. It is strong evidence against tampering during the build. It says nothing about whether the packages in the image are free of vulnerabilities.
• Free is enough when you can rebuild and redeploy weekly or faster, you have no contractual remediation deadline, and no regulator or customer requires FIPS, specific certifications or a supplier you can hold to account.

Why everyone is asking this now

Hardened images used to be a paid niche. In December 2025, a major container platform released its catalogue of more than 1,000 hardened images, built on Debian and Alpine, free under the Apache 2.0 license, according to its announcement. It kept a paid enterprise tier on top, which it says adds SLA backed remediation for critical CVEs, FIPS and STIG oriented variants, customisation and an extended lifecycle add on. Since then, vendors have been bundling hardened images into other products and partnering with each other on catalogues, so a team that never paid for hardened images now has several free or bundled options in front of it.

Teams now ask whether free images remove the need for their own base image work, what "drop in" means in practice, and what a paid tier would buy. The answers depend less on the catalogue and more on the criteria below. If you want the background on why smaller images help at all, our earlier posts on minimal base images for security and the minimal base image myth cover the attack surface argument in depth.

What does "hardened" actually mean for a container image?

There is no standard definition of a hardened container image. Different catalogues use the word for different bundles of properties. When you evaluate one, break it into parts you can verify yourself.

Two of these deserve more attention than they usually get.

VEX is a claim, not a fact. The OpenVEX specification lets a publisher mark a CVE as "not_affected" with a justification such as "vulnerable_code_not_present" or "vulnerable_code_not_in_execute_path", and scanners can then suppress the alert. That is useful, and it is also the publisher marking its own homework. Prefer catalogues that publish VEX alongside the evidence, and spot check a few statements against the upstream advisory.

Secure defaults matter more than the package count. A 20 package image run as root with a writable root filesystem is not safer in practice than a slightly bigger one run as non root, read only and with dropped capabilities. Hardening the image and hardening how you run it are separate jobs. NIST SP 800-190, the Application Container Security Guide, treats image risk and runtime configuration as distinct areas for exactly this reason.

Does a near zero CVE count at pull time stay near zero?

No. A CVE count is a measurement taken at one moment against one vulnerability database by one scanner. Three things move it after you pull.

New advisories land against packages already in the image. The image does not change, but what is known about its contents does. An image that scanned clean on Monday can carry a high severity finding on Thursday.

The publisher rebuilds, but you may not. Hardened image catalogues typically rebuild when an upstream package they ship gets a fix. That only helps you if your build pulls the new image and your deploy ships it. If you pin a tag and your build cache keeps the old layers, or you pin a digest and never update it, you run the old image indefinitely while the catalogue's public dashboard shows a clean number. Our post on base image tags versus digests goes through the trade off in detail. The short version: pin by digest for reproducibility, and automate digest updates so pinning does not become freezing.

Scanners disagree. Distributions such as Debian backport security fixes into the version they already ship rather than moving to a new upstream release. The Debian security FAQ explains that this keeps API and ABI stable, and that a package can therefore keep an old looking version number while being fixed. A scanner that matches only on upstream version numbers will report it as vulnerable. Debian also says it does not use CVSS when triaging, and it routes scanner complaints to the scanner vendor. The same image can therefore show different counts in different tools, and a vendor's headline "zero CVEs" may be measured with its own scanner and its own VEX data.

Who rebuilds, and how fast?

Ask any image provider, free or paid, four questions.

1. What triggers a rebuild? A fixed upstream package, a scheduled interval, or both?
2. How long from upstream fix to published image? Is that a target, a measured average, or a contractual commitment?
3. Which severities does the commitment cover? A commitment for critical CVEs only leaves high severity findings on a best effort basis.
4. What happens when upstream has no fix? Does the provider patch it, mark it with VEX, or wait?

On your side, ask the mirror question: how long from a new image being published to it running in production? For most teams the bottleneck is their own rebuild and redeploy loop, not the catalogue. Our guide on what to do when an image vulnerability has no fix covers the waiting case.

What breaks when you move from a full distribution image?

"Drop in" usually means "same language runtime version and same default entrypoint". It rarely means "every assumption your build and operations make still holds". These are the breakages teams hit most often.

No shell in the runtime image

Anything that relies on a shell stops working: shell form entrypoints, startup scripts that template a config file, health checks written as shell commands, and the habit of opening a shell in a running container to look around. Use exec form entrypoints, move templating into the application or an init container, and write health checks as a small binary or an HTTP endpoint.

For debugging, Kubernetes ephemeral containers are the standard answer. The Kubernetes documentation describes them as temporary containers added to a running Pod for troubleshooting, and notes that because minimal images have no shell or debugging utilities, troubleshooting them with exec alone is hard. Ephemeral containers became stable in Kubernetes 1.25. You attach a debug image that has the tools, optionally sharing the process namespace of the target container, and remove the need to ship those tools in production.

No package manager

If your build file installs a few extra system libraries on top of the base image, that step fails when the runtime image has no package manager. The fix is a multi stage build: install and compile in a build stage based on the provider's development variant, which usually includes a shell and package manager, then copy only the artefacts into the minimal runtime stage. Most catalogues publish paired development and runtime variants for this reason.

Missing libraries and data files

Native extensions in Python, Node.js and Ruby often link against system libraries that a full distribution image happened to include. In a minimal image, the import fails at runtime rather than at build time. Common gaps are image processing libraries, database client libraries, CA certificate bundles in a non default location, time zone data and locale data. Your test suite should run against the final runtime image, not the build stage, or these failures reach production.

glibc versus musl

Some hardened catalogues offer both a glibc based line, typically built on Debian, and a musl based line, typically built on Alpine. The musl project documents its functional differences from glibc, and several of them surface as production bugs rather than build errors.

• DNS resolution. musl queries all configured nameservers in parallel and takes the first answer, supports at most three nameservers, and only added DNS over TCP in version 1.2.4. Applications that depend on large DNS responses or on specific search domain behaviour can behave differently.
• Thread stack size. musl's default thread stack is 128 KB, while glibc derives its default from the stack resource limit, usually several megabytes. Deeply recursive code or runtimes that assume large stacks can crash.
• Locale and iconv. Default locale and character conversion behaviour differ, which can show up in text processing.
• dlclose. In musl, dlclose does nothing, so libraries stay loaded until exit.
• Prebuilt binaries. Wheels, Node.js native modules and vendor binaries built for glibc will not run on musl without a musl specific build.

None of this makes musl worse. It makes switching libc a real migration that needs testing, not a tag change. If your current images are Debian or another glibc distribution, a glibc based hardened line is usually the lower risk move.

Users, permissions and ports

A non root default user cannot bind ports below 1024 without extra capabilities or write to root owned directories. Set file ownership when copying, listen on a high port, and map the service port in your orchestrator.

What does a free tier include versus paid?

Pricing and packaging change, so compare by criteria rather than by brochure. The table below describes what is typical in the market as of October 2026. Check the specific terms of any provider you consider.

The license line is worth reading

Apache 2.0 is permissive: you can use, modify and redistribute, provided you keep notices and the license text. Section 7 of the license states that the work is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, and section 8 limits contributors' liability. That is normal for open source, and it is the honest description of a free hardened image: no one owes you a fix by a date. Remember too that the license on the image build files and metadata does not replace the licenses of the packages inside. A minimal image still contains GPL, LGPL and other licensed components, and your license review still applies.

FIPS is a module property, not an image property

If you sell to US federal agencies, or to regulated customers who mirror federal requirements, you may need FIPS 140-3 validated cryptography. NIST's Cryptographic Module Validation Program validates cryptographic modules, and validated modules sit on the active list for five years. A "FIPS image" is therefore an image that ships and is configured to use a validated module. Ask which module, which certificate, and whether the module version in the image is the validated one. This is one of the most common reasons teams move from a free tier to a paid one.

Extended lifecycle support

When a runtime or distribution release reaches end of life, free images usually stop being rebuilt for it. Paid extended support is effectively a backporting service: worth it as time bought for a migration, not as a permanent home.

Your application layer: does a hardened base help with the libraries you add on top?

Barely. This is the point most teams miss when a catalogue's dashboard shows a clean number.

A typical service image has three layers of content: base operating system packages, the language runtime, and the application with its dependencies. Hardened catalogues address the first two. The third is everything your package manager installs (node_modules, site-packages, JARs, Go modules) plus binaries you download during the build. In most real images it carries more packages than the base, changes more often, and is entirely yours.

A clean base therefore makes your scan results easier to read, because what remains is mostly yours, but it does not reduce the work of fixing what remains. Three practices close the gap.

1. Scan the final image, not just the base. The image you deploy is the unit that matters. Scan it in CI and again on a schedule, because new advisories arrive after the build.
2. Prioritise by reachability. Not every vulnerable function in a dependency is called by your code. Reachability analysis tells you which findings sit on code paths your application actually uses, which is where to start.
3. Treat dependency upgrades like base image updates. Automate them, test them against the final runtime image, and ship them on a cadence. A hardened base with a two year old application dependency tree is not a hardened image.

What does SLSA Level 3 on an image prove, and what does it not?

SLSA (Supply chain Levels for Software Artifacts) defines build levels. The current specification is version 1.2. Its Build track describes three levels.

• Build L1: provenance exists and describes the build platform, process and top level inputs. The specification says L1 provenance is trivial to bypass or forge.
• Build L2: builds run on a hosted platform that signs the provenance, which protects against tampering after the build.
• Build L3: the build platform is hardened so that runs cannot influence each other, even within the same project, and the provenance signing secret is kept away from user defined build steps. The specification says this prevents tampering during the build, including by insiders, compromised credentials or other tenants.

Verified L3 provenance tells you that this exact digest was produced by a named build platform from a named source and revision, in isolation from other jobs. That defeats a whole class of attacks on build servers and release credentials.

What it does not tell you:

• Whether the contents are free of vulnerabilities. Provenance describes the process, not the quality of the inputs.
• Whether the source was reviewed. The Build track focuses on the build. Source integrity is a separate SLSA track.
• Whether every package inside was itself built at L3. An image built at L3 can contain distribution packages built elsewhere. Some providers now say their L3 pipeline also covers the system packages they ship; others build only the final image at L3. Ask which.
• Whether the provenance applies to your image. Once you add layers in your own build, the result is a new artefact. The provider's provenance covers the base digest only. Your final image needs its own provenance from your own build platform.

For a deeper treatment, see our practical guide to implementing SLSA Level 3 and what SLSA Level 3 takes in practice.

Platform constraints that limit your choice

Sometimes the choice is made for you, or at least narrowed, by rules outside your team.

Federal cloud authorisations. FedRAMP's container scanning requirements say that non hardened or general purpose images may not be used within the authorisation boundary, that only containers from images scanned within a 30 day window can be deployed to production, that the registry must be monitored per unique image, and that each running container must be tied back to its source image. A free hardened base can satisfy the "hardened image" part, but you still own the 30 day scanning window, the registry monitoring and the inventory. FedRAMP marks its older playbook page as legacy while it moves to consolidated rules for 2026, so check the current rules before relying on any single document.

FIPS and other cryptographic requirements. As covered above, these push many regulated teams toward paid variants or toward building their own on a validated module.

Certified base requirements. Some platforms and marketplaces require that images listed or supported on them derive from a specific certified base, or pass the platform's own certification. Some enterprise customers write approved base images into contracts. If that applies to you, the hardened catalogue has to be on the approved list, or you build on the required base and harden it yourself.

Payment card environments. PCI DSS 4.0 requires secure configuration standards and timely patching for system components in scope. Hardened images help with both, as our post on PCI DSS 4.0 and hardened containers explains, but the assessor will still ask how you keep images current.

Air gapped and sovereign environments. If production cannot reach a public registry, you need a mirror, a way to move new images across the gap on a schedule, and a way to verify signatures offline. Free catalogues are usually consumable this way, but the operational work is yours.

Architecture coverage. Check that every image you need is published for every CPU architecture you run, typically amd64 and arm64, or you end up with two base image strategies.

Build your own, adopt free, or pay: a decision table

When is a free hardened image genuinely enough?

It is enough when all of these are true. You pin the base by digest and have automation that proposes digest updates. Your pipeline rebuilds and redeploys at least weekly, and faster for critical findings. You scan the final image, including your application dependencies, on every build and on a schedule. You have no customer or regulatory requirement for a supplier fix SLA, FIPS validated modules, a certified base or extended lifecycle support. And you are comfortable that when something breaks, your own engineers will fix it. Many teams meet all of these, and for them paying for hardened base images would buy little.

When does building your own still make sense?

When the catalogue does not cover your stack, or your organisation must own the whole chain for audit or sovereignty reasons. You then sign up for everything a provider does: tracking advisories, rebuilding, signing, generating SBOMs and provenance, and publishing on a cadence.

Step by step: adopting a hardened base the safe way

This walkthrough assumes a Python service, a Kubernetes deployment and GitHub Actions for CI. The same steps apply to any language and platform. Replace the example registry and identities with the ones your provider documents.

Step 1: Resolve the tag to a digest and pin it

Tags move. Digests do not. Resolve the tag you want to an immutable digest without pulling the image.

BASE=registry.example.com/hardened/python:3.12
DIGEST=$(crane digest "$BASE")
echo "${BASE}@${DIGEST}"

Step 2: Verify the signature against the publisher's identity

With keyless signing, you check that the certificate identity and the OIDC issuer match what the publisher documents. Never accept "any valid signature".

cosign verify "${BASE}@${DIGEST}" \
  --certificate-identity "https://github.com/example-org/images/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

If the provider signs with a published key instead, verify with that key.

cosign verify --key publisher.pub "${BASE}@${DIGEST}"

Step 3: Verify the provenance and read it

The attestation type selects which predicate to check. Use the SLSA v1 provenance type and pipe the payload through jq to read the builder and source.

cosign verify-attestation "${BASE}@${DIGEST}" \
  --type slsaprovenance1 \
  --certificate-identity "https://github.com/example-org/images/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  | jq -r '.payload' | base64 -d | jq '.predicate.runDetails.builder, .predicate.buildDefinition.resolvedDependencies'

Check that the builder is the one the provider claims, and that the source repository and revision make sense.

Step 4: Pull the SBOM attestation

Most providers attach an SBOM as an attestation. Pull it the same way, choosing the SPDX or CycloneDX type the provider uses, and keep it with your build records.

cosign verify-attestation "${BASE}@${DIGEST}" \
  --type spdxjson \
  --certificate-identity "https://github.com/example-org/images/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  | jq -r '.payload' | base64 -d | jq '.predicate' > base-sbom.spdx.json

Step 5: Use a multi stage build and record the base

Install and compile in the development variant, copy into the runtime variant, and record the immediate base using the standard OCI annotation names so later tools can trace it.

# Containerfile
ARG BASE_DEV=registry.example.com/hardened/python:3.12-dev@sha256:REPLACE_DEV_DIGEST
ARG BASE_RUN=registry.example.com/hardened/python:3.12@sha256:REPLACE_RUN_DIGEST

FROM ${BASE_DEV} AS build
WORKDIR /app
COPY requirements.txt .
RUN python -m venv /app/venv && /app/venv/bin/pip install --no-cache-dir --require-hashes -r requirements.txt
COPY src/ ./src/

FROM ${BASE_RUN}
LABEL org.opencontainers.image.base.name="registry.example.com/hardened/python:3.12"
LABEL org.opencontainers.image.source="https://github.com/example-org/payments-api"
WORKDIR /app
COPY --from=build --chown=65532:65532 /app /app
USER 65532
EXPOSE 8080
ENTRYPOINT ["/app/venv/bin/python", "-m", "src.server"]

Note the exec form entrypoint, the explicit non root user, the high port and the hash checked install. The OCI image specification defines org.opencontainers.image.base.name and org.opencontainers.image.base.digest for exactly this purpose; set the digest annotation from your build tool so it matches the resolved base.

Step 6: Scan the final image, not the base

Scan the image you are about to deploy, including the application layer. With the Safeguard CLI:

safeguard scan --image registry.example.com/payments-api:1.8.0
ls ./output

Results are written as JSON under ./output, so your pipeline can parse them or archive them as build evidence. Compare the findings against the base image's SBOM: anything not in the base came from your build.

Step 7: Rebuild on a schedule and on base changes

A hardened base only stays fresh if you rebuild. A scheduled workflow catches new base digests and new advisories even when nobody is changing the code.

# .github/workflows/image.yml
name: image
on:
  push:
    branches: [main]
  schedule:
    - cron: "17 3 * * 1"   # every Monday 03:17 UTC
  workflow_dispatch:

permissions:
  contents: read
  id-token: write
  packages: write

jobs:
  build-scan:
    runs-on: [self-hosted, linux]
    steps:
      - uses: actions/checkout@v4

      - name: Install cosign and crane
        run: ./scripts/install-tools.sh

      - name: Verify base image signature
        run: |
          cosign verify "$BASE_RUN" \
            --certificate-identity "$PUBLISHER_IDENTITY" \
            --certificate-oidc-issuer "$PUBLISHER_ISSUER"
        env:
          BASE_RUN: ${{ vars.BASE_RUN }}
          PUBLISHER_IDENTITY: ${{ vars.PUBLISHER_IDENTITY }}
          PUBLISHER_ISSUER: ${{ vars.PUBLISHER_ISSUER }}

      - name: Build image
        run: ./scripts/build-image.sh

      - name: Fail on known exploited vulnerabilities
        uses: safeguard-sh/gold-scan-action@v1
        with:
          fail-on: kev

      - name: Sign the final image
        run: cosign sign --yes "$IMAGE_DIGEST_REF"

Pair this with an automated dependency update tool configured to propose new base digests, so every digest change arrives as a reviewable pull request.

Step 8: Plan your debugging path before you need it

Agree on a debug image and practise the command before an incident, not during one.

kubectl debug -it payments-api-7c9d8 \
  --image=registry.example.com/tools/debug:1.0 \
  --target=payments-api

The target option shares the process namespace of the named container, so you can inspect its processes without shipping a shell in production. If you cannot add an ephemeral container to the live Pod, the copy option creates a separate debugging copy of the Pod instead.

Common mistakes

1. Equating "zero CVEs at pull" with "secure". The number decays from the day you pull. Track how old your deployed base digests are, not just how clean they were.
2. Pinning a digest and never updating it. Reproducibility without automation becomes a frozen image. Every pinned digest needs a mechanism that proposes updates.
3. Only scanning the base. The application layer usually holds most of the findings. Scan the final image.
4. Trusting any valid signature. A signature proves who signed, and only if you check the identity. Verify against the publisher's documented identity and issuer.
5. Assuming the provider's provenance covers your image. It covers the base digest. Your build produces a new artefact that needs its own provenance.
6. Switching libc without testing. Moving from glibc to musl changes DNS, threading and binary compatibility. Test against the real runtime image under realistic load.
7. Shipping debug tools "just in case". Adding a shell back into the runtime image undoes the point of the change. Use ephemeral debug containers instead.
8. Treating a free tier as a supplier. There is no one to escalate to. If a contract or regulator needs an accountable supplier, a free tier does not provide one.
9. Running a hardened image insecurely. Root user overrides, writable root filesystems, privileged mode and broad capabilities can erase most of the benefit. Harden the runtime configuration too.

Where Safeguard fits in an image strategy

A hardened base fixes the bottom layer. Safeguard is aimed at the whole image and everything around it.

• Whole image scanning. The Safeguard CLI scans container images, repositories and SBOM files, and the platform connects to container registries, including OCI registries, to scan images continuously. Findings cover the base packages and the application dependencies you add on top.
• Reachability first. Reachability analysis ranks the vulnerable code paths your application actually calls, so the application layer findings you fix first are the ones that matter.
• Fix pull requests, not tickets. Griffin autonomous remediation opens tested, policy gated pull requests that move vulnerable dependencies to safe versions. It ships switched off, with every category set to Manual, so you choose what runs on its own.
• Policies and gates. Platform policies and gates can stop an image with known exploited vulnerabilities, or an unapproved base, from moving forward.
• Inventory. The platform shows which projects contain a given component and version, which is what you need when a new advisory lands.

Safeguard does not change your cluster's runtime configuration or replace your orchestrator's admission controls. Gold Registry, covered below, adds hardened packages for the application layer a base image never touches.

Fix it without waiting for upstream

A hardened base image narrows the gap for the operating system layer. The gaps below are the ones that remain for everything else you build and ship, and sometimes for the base itself.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

Are free hardened container images safe to use in production?

Yes, provided you treat them as a starting point. They are usually a safer base than a full distribution image. Pin them by digest, verify the signature, rebuild and redeploy regularly, and scan the final image including your own dependencies.

Do hardened images have zero vulnerabilities?

Not permanently. A provider may publish an image with zero known CVEs according to its own scanner and VEX data, but new advisories arrive every day. Different scanners can also report different counts for the same image, especially where distributions backport fixes without changing version numbers.

How often should I rebuild images built on a hardened base?

At least weekly on a schedule, plus whenever the base digest changes or a critical advisory affects something in your image. The provider's rebuild only helps if your pipeline pulls it and your deployment ships it.

Can I use a hardened image for FedRAMP?

It can help with the requirement that images be hardened rather than general purpose. You still have to scan within the required window, monitor the registry, keep an inventory that ties containers to images, and meet any FIPS requirements. Check the current FedRAMP rules for the exact obligations.

Does SLSA Level 3 mean the image is secure?

No. SLSA Build Level 3 means the image was built on a hardened, isolated build platform with signed provenance, which protects against tampering during the build. It says nothing about vulnerabilities in the packages or code inside the image.

Will switching to an Alpine based hardened image break my app?

It might. Alpine uses musl rather than glibc, which changes DNS resolver behaviour, default thread stack size and binary compatibility. Prebuilt native modules built for glibc will not load. Test under realistic load before switching.

Do I still need a vulnerability scanner if I use hardened images?

Yes. The scanner's job shifts from the base layer to the application layer and to watching for new advisories against what you already run. The final image is your artefact, and only scanning it tells you what you actually ship.

Is it worth paying for hardened images?

It is worth paying when you need something the free tier does not give you: a contractual fix SLA, FIPS validated variants, extended support for end of life runtimes, custom builds or a supplier you can hold accountable. If you need none of those, the free tier plus a disciplined rebuild pipeline is often enough.

See how Safeguard would help

None of these demos shows a base image migration end to end. Each shows a piece of the workflow this post recommends for the layers a hardened base does not cover.

The first demo is a real CLI session. Asked to fix a lodash CVE, the Safeguard CLI reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. That is the same loop you need for the application dependencies sitting on top of a hardened base, and the session also shows the scan command.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. For image work, the same setup lets you scan the final built image locally before it reaches a registry.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, a platform engineer can ask an assistant which projects contain a given component and version, which is the first question after a new advisory lands against something in your base or your libraries.

Click through it at your own pace, or open it full screen.

To try it on your own images, download Safeguard or read the CLI documentation. For background on why image supply chains keep making the news, see our roundup of container image supply chain incidents in 2026.

Quick check

Sources

• SLSA v1.2: Build track basics
• SLSA v1.0: Security levels (retired version, for comparison)
• NIST SP 800-190: Application Container Security Guide
• NIST: Cryptographic Module Validation Program
• FedRAMP: Vulnerability scanning, including container unique requirements (legacy playbook)
• CISA: Software Bill of Materials
• Kubernetes: Ephemeral containers
• Kubernetes: Debug running Pods
• musl libc: Functional differences from glibc
• Debian: Security team FAQ
• OpenVEX specification
• OCI image specification: Annotations
• Sigstore: Verifying signatures with cosign
• Sigstore: Verifying attestations with cosign
• Sigstore cosign: verify-attestation command reference
• SLSA framework: slsa-verifier
• Apache License, Version 2.0
• CycloneDX: SBOM capabilities

Last reviewed: 23 October 2026. Hardened image catalogues, pricing tiers and federal rules change often; check each provider's current terms and the linked standards before deciding.