Your developers can move their builds to trusted, signed base images by changing one line in each Dockerfile: the FROM instruction. The platform team handles the rest. It sources curated images, adds your organization's standard layers, and publishes the results to an internal registry that becomes the only approved source. This model gives you control over container image governance while keeping security checks inside the pipelines developers already use. This article covers why image sprawl happens, how a centralized intake model works, what changes for developers, and where to find the full implementation guide.

Why container image sprawl starts with public registries

When each team sources its own base images, the organization ends up with many versions of the same runtime. One team builds on python:3.14 pulled from Docker Hub last month, another uses a slim variant pulled last week, and a third follows a vendor's recommendation. Each choice made sense locally. Together, they leave platform teams with an image inventory nobody fully owns.

The costs show up when something goes wrong. A new CVE lands in a common library, and the platform team has to find every image variant that includes it before anyone can patch. Provenance is unclear, since a tag on a public registry says little about who built the image or whether it changed after publication. Security posture differs from team to team, depending on who last updated what.

Public upstream tags carry a second risk. Pulling the newest release means taking new code into your builds on the day it ships, before anyone has had time to evaluate it.

Why late security gates slow developers down

Security teams often respond to sprawl by adding checks late in the delivery process, such as a vulnerability scan that runs before deployment. The scan finds real issues, but it finds them after the developer has moved on to other work. A failed gate at that point means rework, a delayed release, and pressure to request an exception.

Repeated late failures teach teams to treat security as an obstacle. Developers look for workarounds, security teams add more gates, and releases slow down for everyone.

The fix is to move the control earlier. When the approved base image is the only one available, and the pipeline checks for it on the first line of the Dockerfile, base image problems get caught before the image is built.

How a centralized image intake model works

In this model, a Platform Operations or Platform Security team owns image intake. They run a certified secure image pipeline that controls how images are selected, verified, customized, and published. The process has five steps:

1. Source curated images. The team pulls base images from the RapidFort curated image repository instead of public registries. The catalog covers runtimes such as Python, Node.js, and Java, Linux distributions such as Ubuntu, Red Hat UBI, and Alpine, and third-party images such as databases and load balancers. These images ship with zero or near-zero CVEs, are pre-scanned for malware and tampering, and are cooled-down images, so newly published upstream code doesn't reach your builds unvetted.
2. Verify on ingestion. The pipeline checks each image's signature with a tool such as Cosign.
3. Add organization-standard layers. For base images, the team adds internal CA certificates, organization labels, a non-privileged user, and other required settings.
4. Build, sign, and attest. The pipeline builds the derived image, scans it, signs it on behalf of your organization, and generates attestations that record how it was built.
5. Publish to the internal registry. The signed images become the only approved base images available to development teams.

Third-party images that teams run without modification, such as a database or vendor image, skip the rebuild. The platform team validates and approves them, then publishes them to the same internal registry.

What changes for your developers

For developers, the change is small. They point the FROM instruction at the internal registry and keep writing application code the way they do today:

# Before: public registry
FROM python:3.14

# After: approved internal registry
FROM registry.internal.acme.com/rapidfort/python:3.14

The CI pipeline handles the security steps. A Dockerfile linter such as Hadolint rejects any FROM instruction that references an unapproved registry. The pipeline then scans the image to generate a software bill of materials (SBOM) and find known vulnerabilities, attests how the image was built, and signs it before pushing it to the registry.

Feedback arrives in the developer's own pipeline at build time, as a specific error on a specific line. That's a faster loop than a rejected deployment days later. Because the base image arrives with near-zero CVEs, developers also spend less time triaging vulnerabilities they didn't introduce.

A Kubernetes admission controller acts as the final check at deployment, blocking any image that didn't come through this process. The whitepaper covers that runtime layer in detail.

What platform and engineering leaders gain

Platform teams get one place to manage base images. When a curated image receives an update, the platform team rebuilds and republishes it once, and development teams pick it up on their next build. Because every approved image carries an SBOM, finding which images include an affected library means searching one known set of records.

Engineering leaders get a security model that fits the existing delivery process. Developers work from approved images by default, and the checks run in pipelines they already use. Security teams can set vulnerability objectives and track them against a single, known set of base images.

The signatures and attestations produced at intake and build time also create an audit record. You can show where each image came from and how it was built without assembling that evidence by hand. For more on how curated images fit this model, see RapidFort Curated Images. And for more information about our curated libraries, see RapidFort Curated Libraries solution brief.