Your Container Images Are the Softest Part of Your ATO

Ask any ISSM where accreditation timelines go sideways and you'll hear the same story. The architecture was solid. The boundary was clean. The controls were mapped. Then the scan results came back on the container images and everything stopped.

This happens on almost every program. It's worth understanding why, because the fix is not what most teams think it is.

The math nobody runs until it's too late

A typical application stack in a DoD environment runs 30 to 80 container images. Base images, sidecars, init containers, the databases and message queues and proxies that make everything work.

Pull a standard base image from a public registry and scan it. You'll find somewhere between 40 and 400 findings, depending on the image and the scanner. Most are in packages your application never touches. Doesn't matter. They're in the scan report, and the scan report is what the accreditor reads.

Now multiply. Fifty images, averaging 100 findings each. That's 5,000 line items. Every one needs a disposition: patch it, mitigate it, or justify it in a POA&M. Even at ten minutes per finding, which is optimistic, you're looking at 800 hours of work before anyone writes a line of mission code.

That's not a security process. That's a paperwork factory. And it resets every time you rebuild.

Why patching doesn't get you out

The instinct is to patch your way clean. Update the packages, rebuild, rescan. It works for a week.

The problem is that public base images carry hundreds of packages you don't need. Every package is a future CVE. You can patch today's findings, but the surface area guarantees a fresh batch next month. Teams end up on a treadmill: scan, patch, rebuild, rescan, repeat. The findings count never gets to zero because the inputs were never built for zero.

Meanwhile the program schedule doesn't care. The ATO package is due. The fielding date is set. So teams do what teams do under pressure. They write POA&Ms. Lots of them. And now the program carries a stack of accepted risk that somebody has to re-justify at every review.

The input problem

Here's the reframe: CVE findings in your images are not a patching problem. They're an input problem.

If the images entering your environment are built minimal, built from verified sources, and maintained to stay near zero findings, the whole downstream chain changes. The scan report shrinks from thousands of lines to a handful. The POA&M stack shrinks with it. The accreditor's review gets shorter because there's less to review. Rebuilds stop generating fresh findings because there's less in the image to go stale.

You can't get there by patching public images harder. You get there by changing what comes in the door.

What that looks like in practice

A hardened registry does three jobs that a public registry plus a scanner does not.

First, it serves images built minimal from the start. No package managers, no shells, no utilities that exist only to show up in scan reports. What's not in the image can't be a finding.

Second, it gives you provenance. Every image traces to a known source with a real SBOM. When the accreditor asks where a binary came from, you have an answer that isn't "Docker Hub, probably."

Third, it lives where your workloads live. Self-hosted, inside your boundary, on the disconnected network if that's where you operate. Hardened images you can't reach from your environment are hardened images you don't have.

That last one matters more in defense than anywhere else, and it's a topic big enough that we'll give it its own post.

What changes for the ATO

None of this makes accreditation automatic. Your architecture still has to be right. Your controls still have to be real.

What it does is take the single biggest volume driver out of the package. The image findings that used to consume 800 hours and a three-inch POA&M binder become a short appendix. The conversation with your accreditor shifts from "explain these 5,000 findings" to "here's our provenance and here's our process." That's a conversation you can win on schedule.

We built Ghost because we kept watching good programs lose months to this exact problem. Ghost is a hardened container registry built for DoD environments: minimal near-zero-CVE images, full provenance, self-hosted where you need it, including places with no outside connectivity.

If your last scan report was longer than your design doc, the images are the problem. Fix the inputs and the rest of the ATO gets a lot lighter.

More on the triage math, air-gapped delivery, and what a POA&M actually costs you in the coming weeks.