Shift-Left Container Security

For most teams, shift-left container security has meant moving the scanner into CI, which gets CVE findings to developers sooner and leaves the backlog the same size. Shift-left elimination moves the fix earlier instead, and with RapidFort it eliminates up to 99.9% of CVEs and up to 90% of the software attack surface before an image is deployed. The method has two parts: change where components come from, then delete what the application never uses. This article explains why application-layer fixes can't reach inherited CVEs and walks through a three-stage pipeline that eliminates them, including how to keep images clean after day one.

Earlier findings still need an engineer to track the upstream patch, rebuild the image, and redeploy. That work now reaches developers at the moment they are trying to ship.

Why application-layer fixes can't reach inherited CVEs

A typical containerized service is mostly code your team did not write. Roughly 85% of the software stack is open source , spread across three layers: operating system packages in the base image, frameworks and runtimes, and the application's own dependencies. Your team's business logic is the remaining slice.

That ratio decides where vulnerabilities live. A container image bundles hundreds of OS packages, runtimes, and libraries, and the service never calls many of them. Third-party SDKs for cloud services, AI frameworks, and data integration bring dependency trees of their own. When a scanner reports a CVE in one of these components, there is usually nothing to change in your application code, because the vulnerable file came from upstream and is baked into the image.

Teams usually respond in one of two ways. The first is to own the fixes: assign engineers to track upstream patches, rebuild images, and work the backlog. That holds at small scale. As disclosures grow, so do the tickets and the team needed to work them. The second is to change the inputs so fewer vulnerabilities enter the pipeline, which is the basis of shift-left elimination.

Shift-left detection vs. shift-left elimination

The two approaches scale in opposite directions. Detection effort grows with the number of disclosed CVEs, which keeps rising. Elimination effort grows with the number of components the service needs, a smaller number that changes far less often.

In pipeline terms, the three stages below run between intake and deployment: profile the image, replace its sources, and optimize it before it is pushed to production.

Stage 1: profile what actually runs

Elimination starts with an accurate picture of the image, which takes two inventories.

The first is a Software Bill of Materials (SBOM), which lists every package installed in the image. RapidFort Analyzer generates the SBOM, exports it in SPDX or CycloneDX, and confirms whether each CVE applies to the image instead of reporting every CVE that upstream advisories associate with an installed package. This is also the stage to scan for malware and exposed secrets.

The second is a Runtime Bill of Materials (RBOM®), which records what the workload executes. RapidFort Profiler generates the RBOM® with less than 1% overhead and no application changes. The gap between the RBOM® and the SBOM is the code you can delete.

A general-purpose base image often ships a shell, a package manager, and dozens of libraries the service never calls. Each unused component adds findings someone has to triage and gives an attacker tools to use after gaining a foothold. The comparison also separates real risk from noise: a CVE in a package that never loads carries different risk from a CVE in a library on the request path, even when both have the same CVSS score.

Stage 2: replace base images and libraries with curated sources

Once you know what the service depends on, the fastest CVE elimination comes from swapping the inputs.

For base images, that means moving from a stock image to a curated, near-zero CVE equivalent on the same distribution. RapidFort Images cover Ubuntu, Debian, Red Hat, and Alpine LTS releases and are pin-for-pin compatible, so the change is one line in the Dockerfile:

# Before
FROM ubuntu:22.04

# After
FROM [INSERT RAPIDFORT CURATED UBUNTU 22.04 IMAGE PATH]

The images are hardened to NIST SP 800-70, FIPS 140-3 validated, and STIG and CIS benchmarked, so teams in regulated environments start from a STIG-compliant OS.

Application dependencies follow the same logic one layer up. RapidFort Libraries provide independently malware-scanned packages for npm, PyPI, Maven, RubyGems, Go, and NuGet, pin-for-pin compatible with the versions developers already use. CVE scanners match packages against published advisories, so a typosquatted or compromised package with no CVE assigned won't appear in their results. Pulling from a malware-scanned source reduces exposure to those packages before they reach the build.

Record decisions as you go. Where a finding stays open, log the advisory and the justification, for example in a VEX statement, so later triage and audits start from a written record.

Stage 3: optimize by eliminating code that never executes

Replacing the base eliminates most known vulnerabilities in the components you keep. Optimizing removes the components you don't need.

Using the RBOM® as the reference, RapidFort Optimizer removes unused packages and files from the image without code changes. This step is how RapidFort reaches up to 99.9% CVE elimination, it removes components that contain vulnerabilities but never execute. The image also gets smaller, which shortens pulls and leaves an attacker fewer tools after a compromise.

With the RapidFort CLI, the sequence looks like this:

# Create an instrumented stub of the image
rfstub my-service:1.4.2

# Run the stub under realistic traffic or a coverage script,
# then build the optimized image from the recorded profile
rfharden my-service:1.4.2-rfstub

Two engineering conditions decide whether this step is safe:

• Profiling has to exercise real behavior. If a code path never runs during profiling, the RBOM® won't include it, and the Optimizer can remove what that path needs. Run the workload under realistic traffic or a test suite that covers startup, error handling, and less common paths before removing anything. Coverage scripts are one way to do this. In addition, you may also specify which components should always be retained in a hardened image by using a profile file.
• Optimized images need a rebuild cadence. An optimized image is a snapshot of one build. RapidFort Optimizer continuously rebuilds optimized, minimal images every 24 hours , so upstream fixes reach the minimal image without manual work.

How to keep elimination continuous after day one

New CVEs are disclosed every day, so an image that is clean on Monday may not be clean on Friday. Shift-left elimination holds only if the sources and the pipeline keep moving.

On the source side, RapidFort Images carry defined service levels:CISA KEV CVEs fixed in 1 day, Critical and High in 7 days, Moderate in 21, Low in 28, from patch availability.. On the deployment side, RapidFort Runtime keeps a dynamic RBOM® updated from live production evidence, matches new disclosures against the components that are present or executing, and flags unauthorized changes to packages, binaries, and processes.

The last change is in what the team measures. A dashboard that counts CVEs discovered rewards the scanner. Track CVEs at intake against CVEs in deployed images, packages removed, and image size, because those numbers show whether risk is going down.

Start with the image that has the biggest backlog

Shift left was meant to make security cheaper by handling it earlier. Moving the scanner moved the information, and eliminating inherited CVEs at the source moves the work. Pick the image with the largest CVE backlog, compare its SBOM with its RBOM®, and swap its base image. The share of findings that disappear after those steps shows how much of your backlog was inherited.

Before/after CVE count when adopting RapidFort images

See which components your images ship but never run.