Container Image Scanning vs. Hardening: Why One Without the Other Is Not Enough

Most organizations that have invested in container security have invested in scanning. They have a tool that runs against every image in their pipeline and reports findings. The report goes to a security engineer. The security engineer looks at the findings, marks some as acceptable risk, creates tickets for others, and the cycle continues.

This cycle is not a security failure. It is a capability gap. Scanning identifies vulnerabilities. It does not remove them. Hardening removes them. The two are complements, not substitutes, and organizations that have only scanning are operating with half the capability they need.

What Scanning Does Well?

Container image scanning does several things effectively:

Inventory visibility: Scanners extract the software bill of materials from an image and cross-reference against CVE databases. You know what is installed and what vulnerabilities are known to affect those packages.

Severity classification: Scanners classify findings by CVSS score, providing a prioritization signal for remediation.

Policy gate enforcement: Scanners can gate pipeline promotion on CVE thresholds — images with Critical CVEs above a defined count do not proceed.

Compliance evidence generation: Scan results with timestamps provide audit evidence that images were assessed before deployment.

These are genuine capabilities with genuine security value. Scanning is the diagnostic. It tells you where the problems are.

What Scanning Cannot Do?

A scanner cannot remove a CVE. It can report that the CVE is present. The remediation is a separate activity:

Patching: Update the affected package to a version where the CVE is fixed. Requires: a fix exists, the updated version is compatible with the application, the dependency tree is updated, the image is rebuilt and tested.

Package removal: Remove the package entirely from the image. Requires: confirming the package is not needed, verifying removal does not break the application.

Risk acceptance: Document that the CVE is accepted as a risk because remediation is not feasible. Does not reduce the attack surface.

Most container security programs spend the majority of their effort on the patching path. Patching is necessary — critical vulnerabilities in packages the application uses must be patched. But patching alone cannot address the majority of container CVEs because the majority are in packages the application does not use.

“Patching is the right remediation for CVEs in packages your application uses. Removal is the right remediation for CVEs in packages your application does not use. Most containers have far more of the second category than the first.”

The Report-and-Ignore Cycle

Security teams familiar with container scanning recognize the pattern: the scanner returns 300-500 findings, the team triages 50-100 of them, the rest are dismissed as “not applicable” or “acceptable risk,” and the cycle repeats with the next scan.

This is not a failure of rigor. It is a rational response to the volume. Most of those 300-500 findings are in packages the application never calls. Addressing them individually through patching is not feasible.

But the risk does not disappear by being dismissed. The packages are still present. The CVEs are still exploitable. The attack surface has not changed.

Automated hardening through component removal changes this dynamic by addressing the root cause: the packages generating the noise are removed from the image before scanning. The scanner then runs against a hardened image with 40-60 packages rather than 400-500 packages. The findings are all in packages the application uses. Every finding is actionable.

The Scanning + Hardening Pipeline

The integrated model:

Step 1: Application image is built Step 2: Runtime profiling captures which packages are executed during test suite runs Step 3: Automated container hardening removes packages with zero execution evidence Step 4: Container vulnerability scanner runs against the hardened image Step 5: Scan results gate pipeline promotion based on the threshold policy Step 6: All findings in the scan report are in packages the application uses — these are the findings worth addressing

The output of step 6 is a manageable finding set. If the hardened image has 50 packages and the scanner finds 5 Critical CVEs across them, those 5 findings all represent genuine risk in code that is actually executed. Each warrants investigation and remediation.

This is categorically different from triaging 300 findings and marking 250 as not applicable. The security effort is directed at real risk.

The Risk Calculus for Package Removal vs. Patching

For CVEs in packages the application does not use, removal is the appropriate remediation for three reasons:

Completeness: Removal eliminates the package and all its CVEs simultaneously. Patching one version of a package may fix one CVE but leave others; removal fixes all of them.

Permanence: A removed package does not re-accumulate CVEs. New CVEs disclosed against the package after removal do not affect the image because the package is gone.

Speed: Removal can happen immediately once the runtime profile confirms the package is unused. Patching requires a fix to be available, compatibility to be verified, and the fix to be tested.

For CVEs in packages the application uses, patching is the appropriate remediation. There is no alternative: the package must be updated because removal would break the application.

The hardening-then-scanning model cleanly separates these categories. After hardening, all remaining packages are in the “used” category. All scanner findings are for packages that require patching. The triage step — “is this package used?” — is already answered by the hardening process.

Frequently Asked Questions

What is the difference between container image scanning and container image hardening?

Container image scanning identifies vulnerabilities by extracting a software bill of materials from the image and cross-referencing it against CVE databases. It produces a report of findings but does not fix anything. Container image hardening removes unused packages, libraries, and components from the image, eliminating CVEs by removing the vulnerable code entirely. Scanning is the diagnostic; hardening is the treatment. Both are necessary — scanning without hardening leaves most CVEs unaddressed, and hardening without scanning lacks evidence generation and policy gate enforcement.

Why does container image scanning alone produce so many unactionable findings?

Most container images contain 300–500+ packages, but a typical application only actively calls 40–60 of them. The remaining packages are transitive dependencies installed automatically by the package manager but never executed by the application. Scanner findings in unused packages cannot be practically patched because the packages have no application function — there is nothing to upgrade or fix. Hardening removes these packages before scanning, so every finding in the resulting scan is in code the application actually uses and warrants genuine remediation.

How does container image hardening reduce the CVE triage burden for security teams?

After hardening, the image contains only packages the application executes. When a scanner then runs against a hardened image with 40–50 packages instead of 400–500, findings drop from hundreds to single digits or low tens — and all of them are actionable. Security teams no longer spend the majority of their time marking findings as “not applicable” or “acceptable risk” for packages the application never calls. The triage step of determining whether a vulnerable package is used is already answered by the hardening process.

Should container image scanning happen before or after hardening in the CI/CD pipeline?

Scanning should happen after hardening. The integrated pipeline runs as follows: build the image, perform runtime profiling to capture which packages are executed, run automated hardening to remove unused packages, then scan the hardened image. Running the scanner against the hardened image means every finding is in a package the application genuinely depends on. Running the scanner against the unhardened image produces a high volume of findings that obscure the genuine risk and create unnecessary triage work.

Measuring the Improvement

Teams that add hardening to an existing scanning program can measure the before-and-after improvement:

• Finding count: How many findings does the scanner return before and after hardening?
• Actionable finding rate: What percentage of findings are in packages the application actually uses?
• Time to triage: How long does it take to review scanner findings from a hardened image vs. an unhardened image?

These metrics give security leadership a concrete before-and-after comparison. Scanning alone versus scanning-plus-hardening is a measurable difference in both security posture (CVE count reduction) and operational efficiency (finding volume reduction, triage time reduction).

The combination is what a complete container image security program looks like. Scanning without hardening is diagnosis without treatment. Hardening without scanning lacks the measurement and evidence generation. Together, they close the loop.