Most container security programs separate scanning from remediation. The scanner runs in CI, produces a report, and engineers triage the findings manually — sometime later, in a separate workflow, without automated verification that the remediation worked. This separation is where security programs lose momentum. Findings accumulate. Triage becomes a backlog item. The pipeline and the security posture drift apart.
A hardening pipeline treats scanning and remediation as a single automated workflow. Scan. Analyze what the scan found. Remove what can be removed. Verify the result. Each step feeds the next, and the output is a hardened image that has been demonstrably improved — not a report waiting for someone to act on it.
The Four Stages of a Hardening Pipeline
Stage 1: Scan
The pipeline begins with a standard vulnerability scan of the image as built. This baseline scan captures the CVE footprint before any hardening has been applied.
The scan should capture:
- OS package CVEs (from package manager databases)
- Language package CVEs (pip, npm, Maven, Go modules)
- Binary-level CVEs where package manager data is incomplete
- License violations if relevant to compliance requirements
The baseline scan output feeds directly into analysis — it is not a final report, it is input data for the next stage.
Stage 2: Analyze
Analysis determines which CVEs are actionable and which packages can be removed. This is where the pipeline goes beyond what basic scanners provide.
Static analysis alone cannot answer the question “does the application actually use this package?” A package may be installed as a transitive dependency of a direct dependency that itself is only used in a rarely-invoked code path. Static reachability analysis can trace these paths in theory but misses dynamic loading patterns.
Runtime profiling answers the question empirically. Run the application against its test suite under profiling instrumentation. Capture which packages, modules, and functions are called. Anything with zero execution evidence during representative testing is a candidate for removal.
The analysis stage produces two lists:
- Packages with no execution evidence — candidates for automated removal
- Packages with execution evidence that carry CVEs — require manual remediation through version upgrades
Stage 3: Remove
Automated container hardening acts on the removal candidates. Packages with no execution evidence are removed from the image. This is safe because the application never called them during profiling; they provide zero application value while contributing CVEs to the image.
The removal step produces a hardened image artifact. The hardened image is a different artifact from the base image — it has a different digest and should be stored separately in the registry with a naming convention that distinguishes it (e.g., myapp:1.2.3-hardened).
Typical removal outcomes:
- 60-90% of CVEs eliminated through package removal
- 30-60% image size reduction
- No application behavior change (removed packages were never called)
Stage 4: Verify
The hardened image requires verification before promotion. Verification has two components:
Functional verification: Run the test suite against the hardened image. If anything was incorrectly removed — if the profiling missed a code path that is exercised by the tests — the test suite will catch it. Verification failures feed back to the analysis stage to expand the profiling coverage.
Security verification: Rescan the hardened image. The post-hardening scan produces a CVE report for the packages that remain. This report is the auditable artifact: it shows the before count, the after count, and the delta.
Pipeline Implementation in CI/CD
A GitHub Actions implementation of the four-stage pipeline:
jobs:
harden:
runs-on: ubuntu-latest
steps:
– name: Build image
run: docker build -t myapp:${{ github.sha }} .
– name: Stage 1 – Baseline scan
run: |
trivy image –format json –output baseline-scan.json myapp:${{ github.sha }}
– name: Stage 2 – Profile runtime usage
run: |
# Run application under profiling against test suite
# Capture execution trace
# Output: component-usage-report.json
– name: Stage 3 – Automated hardening
run: |
# Apply hardening based on profiling output
# Output: myapp:${{ github.sha }}-hardened
– name: Stage 3 – Functional verification
run: |
# Run test suite against hardened image
docker run myapp:${{ github.sha }}-hardened npm test
– name: Stage 4 – Post-hardening scan
run: |
trivy image –format sarif –output hardened-scan.sarif \
myapp:${{ github.sha }}-hardened
– name: Upload security results
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: hardened-scan.sarif
– name: Gate on Critical CVEs
run: |
trivy image –exit-code 1 –severity CRITICAL \
myapp:${{ github.sha }}-hardened
Making Hardening Artifacts Auditable
Hardened container images are most valuable when they are auditable. The pipeline should produce artifacts that demonstrate:
- What the CVE count was before hardening (baseline scan)
- What was removed and why (profiling-based removal log)
- What the CVE count is after hardening (post-hardening scan)
- That functional tests passed against the hardened image (test results)
These four artifacts together constitute a complete hardening record. Security teams can present them to auditors as evidence of systematic CVE reduction. Compliance programs that require documented remediation evidence — FedRAMP, SOC 2, PCI DSS — benefit from the automated audit trail the pipeline produces.
Frequently Asked Questions
What are the four stages of a container hardening pipeline?
A container hardening pipeline consists of four sequential stages: Scan, Analyze, Remove, and Verify. The baseline scan captures CVE exposure before hardening. The analysis stage uses runtime profiling to determine which packages are actually used during execution. The removal stage eliminates packages with zero execution evidence, typically reducing CVEs by 60-90%. The verification stage runs functional tests against the hardened image and rescans to produce an auditable before-and-after record.
How does runtime profiling improve container hardening compared to static analysis?
Runtime profiling answers empirically which packages the application actually calls during representative execution, something static analysis cannot reliably determine. By running the application against its test suite under profiling instrumentation, the pipeline captures which modules, functions, and libraries are genuinely invoked. Packages with zero execution evidence are safe to remove because they provide no runtime value while contributing CVEs to the image.
What evidence does a container hardening pipeline produce for compliance audits?
A well-implemented container hardening pipeline produces four auditable artifacts: the baseline scan showing the CVE count before hardening, a profiling-based removal log documenting what was removed and why, the post-hardening scan showing the resulting CVE count, and functional test results confirming the hardened image behaves correctly. These artifacts together satisfy compliance evidence requirements for frameworks like FedRAMP, SOC 2, and PCI DSS.
Consistency Across Teams
One failure mode in distributed organizations: each team applies hardening differently, or some teams skip it. The pipeline approach solves this by making hardening a standard pipeline stage that runs automatically.
When hardening is a pipeline stage rather than a manual step, teams do not need to remember to do it. The image that gets deployed is always the hardened image because the pipeline does not produce an unverified artifact for deployment.
The teams that treat scanning and hardening as a unified automated pipeline rather than separate manual workflows are the ones whose container security posture improves continuously rather than deteriorating between review cycles.