Intro: the CVE noise problem nobody budgeted for
The first time you open an ECR findings list for a Node app built on a full distro base, the shape of the problem is obvious. Twenty, forty, sometimes sixty findings, and most of them are attached to bash, dnf, tar, glibc-common, or some XML parser your application has never once called. Red Hat Hardened Images AWS ECR scanning support, announced on 25 August 2026, is aimed squarely at that list.
I have sat on both sides of this. As the person running the registry, I have spent an afternoon writing suppression justifications for CVEs in a package manager that only exists in the image because the base layer shipped it. As the person maintaining the app, I have received tickets asking me to remediate something I did not install, cannot remove without breaking the base, and do not use. Neither side is wrong, and neither side has budget for the work.
The change itself is small to describe. The AWS InspectorScan API and ECR Basic scanning now recognise Red Hat Hardened Images, which means the scanner correctly identifies what is actually in those minimal images instead of guessing or reporting oddly against an unfamiliar base. Red Hat’s announcement is here (opens in new tab) and it is a short read.
Who should care: teams on RHEL or UBI bases today, teams with a compliance auditor asking about container hardening, and anyone whose security backlog is mostly base-image noise. Who should not get excited: if you already run Chainguard or build on Wolfi, you have solved the same problem a different way and this is mostly a note that another vendor’s minimal images now scan cleanly in AWS-native tooling. The interesting part for you might be the FIPS variant, not the distroless story.
For a site owner analogy, picture a shared hosting box where every account gets PHP, a mail server, a compiler toolchain, and phpMyAdmin whether they asked or not. Every one of those is something to patch, and most customers use one of them. A distroless container base image is the same box with only PHP-FPM and your site’s files on it.
Background: what Red Hat Hardened Images actually are
Red Hat Hardened Images is a catalogue of container base images built through Red Hat’s own build pipeline, containing only the files an application needs to run. No documentation trees, no shell, no dnf, none of the general-purpose Linux furniture. Red Hat says nearly 60 core images and over 150 variants across the catalogue, which is enough coverage for most common runtimes but not enough that I would assume your specific stack is there without checking images.redhat.com first.
The catalogue splits into three variants, and the split exists because a genuinely minimal runtime image is hostile to building software:
- Default is the distroless production runtime. No shell, no package manager, small.
- Builder carries shells and package managers so you can compile and install build-time dependencies, then hand the finished binary to a Default image.
- FIPS enforces FIPS 140-2/140-3 validated cryptographic modules when the host cluster is FIPS-enabled. That last condition matters. A FIPS container image on a non-FIPS host does not give you a FIPS deployment, and I have watched that misunderstanding cost a team a week of audit back-and-forth.
The compliance framing is the other half of the pitch. Red Hat points at CIS, STIG, and OpenSCAP profile alignment, which in practice means fewer hand-written exceptions when someone runs a benchmark against your images. That is real value, though it is worth remembering that a hardened base does not make your Kubernetes manifests or IAM policies compliant. It removes one row from a very long spreadsheet.
On the AWS side, ECR Basic scanning has existed for years. It is AWS-native detection drawing on more than 50 data feeds, including vendor security advisories and the National Vulnerability Database, and it looks for known CVEs in operating system packages. The whole mechanism depends on correctly identifying which OS packages are present and where they came from. Feed a scanner an unfamiliar minimal base and you get results that are difficult to trust, either quiet in a way that feels wrong or noisy in a way nobody can action. Recognition of the base is the boring prerequisite that makes the findings usable, and that is what this announcement delivers.
What’s happening now with Red Hat Hardened Images AWS ECR scanning
Two AWS services are involved and they sit at different points in your pipeline.
ECR Basic scanning runs against images already in the registry. You configure it to scan on push or trigger it manually, findings show up in the ECR console, and scan completion events go to Amazon EventBridge. That EventBridge hook is the part most teams skip and then regret, because a findings page in the console is a page nobody opens on a Tuesday.
The InspectorScan API works earlier. You generate an SBOM with the Amazon Inspector SBOM Generator, inspector-sbomgen, pointing it at a container image, an archive, or a compiled binary, then submit that SBOM to the API and get back a vulnerability report scored with NVD and CVSS ratings. Nothing needs to be pushed to a registry first, which is exactly what you want in a build job.
Layered together, the pattern is straightforward. InspectorScan runs in CI as the gate before push. ECR Basic scanning is the standing check on what is already sitting in your repositories, catching the CVE that was published three weeks after your last build. Both are useful for different reasons, and if you only implement one, implement the registry side, because unpatched old images are a more common incident cause than a bad new build.
Now the boundary, because it gets glossed over in announcements. This is operating system package detection. It is not application dependency scanning. Your requirements.txt, your package.json, your go.mod, your vendored PHP libraries in a Composer install: none of that is covered here in the way OS packages are. If you move to a hardened base and your finding count drops to near zero, that number is telling you the base is clean. It is not telling you the application is clean. I have seen a clean ECR scan used as evidence in a security review for an app with a two-year-old Express dependency, and that is a worse outcome than a noisy scan.
Keep something like npm audit, pip-audit, Dependabot, or Trivy in filesystem mode running alongside this. The tools are complementary and the overlap is small.
What Red Hat Hardened Images AWS ECR scanning means in practice
Does this reduce my CVE count, or just report it differently?
Both, and the two reasons are worth separating. The genuine reduction comes from the image, not the scanner. If bash and dnf are not in the image, their CVEs cannot apply to you, and that is a real change in attack surface rather than a reporting trick. The reporting improvement comes from AWS correctly attributing what remains. You get fewer findings that need a human to write “not applicable, package not reachable” into a ticket. If your current triage is mostly that sentence, this is a meaningful reduction in labour.
Do I have to change my Dockerfile?
Probably yes, and the change is a multi-stage build. Compile in the Builder variant, copy the artefact into the Default runtime, done. The friction is everything you did not realise depended on a shell:
HEALTHCHECK CMD curl -f http://localhost:8080/healthstops working because there is nocurland no/bin/shto run the command through. Move health checks to the orchestrator, or to an HTTP probe in your task definition or pod spec.kubectl exec -it pod -- /bin/shgives youOCI runtime exec failed: exec: "/bin/sh": stat /bin/sh: no such file or directory. First time that lands mid-incident it is genuinely unpleasant.- Entrypoint shell scripts that read environment variables, wait for a database, or run migrations need to move into the application binary or a separate init container.
What does a zero-CVE container strategy actually mean here?
It means zero known CVEs at release time. Not permanently zero. A CVE published tomorrow against a library still in the image applies to the image you shipped today, and no amount of hardening changes that. If you are writing customer-facing SLA or security-page language, be careful. “We build on hardened base images with no known vulnerabilities at build time, and we rebuild on a defined cadence” is defensible. “Zero-CVE containers” as a standing claim is not, and someone will eventually check.
Can I gate my pipeline on this?
Technically, easily. In CodeBuild or GitHub Actions you run inspector-sbomgen, submit to InspectorScan, parse the response, and exit non-zero above some CVSS threshold. My hesitation is about hard failures on CVSS scores. CVSS describes a vulnerability in the abstract, not in your deployment, and a 9.8 in a code path your container never reaches will still block a deploy at three in the afternoon. I run the scan as a blocking step only for a narrow set of critical findings, and everything else opens a ticket. Teams that hard-fail on everything tend to end up with a widely-shared skip flag, which is worse than no gate.
What to expect next
The debugging cost is the tradeoff that will bite, and I want to be direct that I do not have this fully solved. Removing the shell from the runtime image changes incident response. If your team’s normal first move during an outage is to exec into the container and look around, that move is gone, and what replaces it is good log aggregation, decent metrics, and ephemeral debug containers. For a team already shipping structured logs to CloudWatch or Loki, the loss is small. For a small team that debugs by poking at running containers, I honestly do not know how well this holds up, and I would not tell that team to switch every service at once.
Second thing I am watching: whether findings parity holds across variants. Scanner metadata for hardened and minimal bases has historically lagged behind mainstream distro images, and the FIPS variant is where I would expect gaps to show up first, since the package set differs from the Default image in ways scanners do not always model well. If you run FIPS images, compare the InspectorScan output against the ECR console output for the same tag and see whether they agree. If they do not, that is worth a support case rather than a shrug.
There is also an open question on the registry side that the announcement does not address. If you use ECR replication across regions, or pull-through cache repositories fronting an upstream registry, scanning behaviour is not always identical to a directly-pushed image. I have not tested hardened images specifically in that setup, so treat it as something to verify in your own account rather than assume.
My expectation, and this is a prediction rather than a fact: within a year or two, hardened or minimal base images stop being an opt-in engineering preference and start appearing as a line item in procurement questionnaires and vendor security reviews. I already field questions from hosting customers about base image provenance that nobody asked me three years ago. Once a compliance form has a checkbox for it, the decision leaves engineering.
Try it on one image this week
Pick your least critical service. Not the payment path, not the auth service, something like an internal dashboard or a cron worker where an hour of breakage costs you nothing.
Swap its base to a Default variant from images.redhat.com, then before you push anything, run:
inspector-sbomgen generate --image myrepo/dashboard:hardened-test
Submit that SBOM to the InspectorScan API and write the finding count down. Do the same against your current base image and write that number down too, in the same place, with the date. Those two numbers are what you will point at when someone asks whether the migration was worth the effort, and reconstructing them later from memory is not possible.
While you are in the console, create an EventBridge rule on the ECR image scan completion event and route it to Slack or your ticket queue. Ten minutes of work, and it is the difference between findings being seen and findings sitting in a tab.
Then keep a plain list of what broke. Did the health check fail because curl is gone? Did the entrypoint script die? Did a native extension need a compiler at runtime, which means that service genuinely needs the Builder variant instead of Default? That list decides your migration order for everything else, and it is more useful than any general advice I can give you about your own stack.