CI/CD hardening and near-zero CVE images reshape appsec control

At a glance

What this is: This white paper says CI/CD security can be improved by combining curated container images, continuous profiling, and hardening to reduce vulnerabilities and attack surface.

Why it matters: It matters because appsec and cloud teams need stronger control over container provenance, runtime exposure, and supply chain risk without slowing delivery.

By the numbers:

• Up to 99.9% of software vulnerabilities can be eliminated within hours through continuous scanning and container hardening, according to Rapidsort.
• The platform claims up to 90% reduction in software attack surface through curated images and runtime optimisation, according to Rapidsort.

👉 Read Rapidsort's white paper on CI/CD hardening and near-zero CVE images

Context

CI/CD pipelines compress development, testing, and deployment into short cycles, but that speed can also compress security review time to the point where vulnerable components move into production before they are understood. In containerised environments, the main governance problem is not only code quality but also image provenance, runtime footprint, and the visibility needed to prove what actually runs.

This white paper frames container hardening as a way to reduce attack surface without code changes, using curated images, vulnerability analysis, and runtime profiling. The identity angle is indirect but real: software supply chain controls depend on trustworthy service identities, signed artefacts, and restricted build-time privileges, especially where pipelines can introduce secrets exposure or privileged access.

For many enterprises, that starting position is typical rather than exceptional. Most teams have some scanning in place, but far fewer can reconcile build-time findings with what executes in production.

Key questions

Q: What breaks when container security relies only on CVE scanning?

A: Teams miss the difference between vulnerable components that are present and components that are actually reachable at runtime. That creates false confidence, noisy backlogs, and poor prioritisation. A better model combines image scanning with runtime evidence, then focuses remediation on code paths that attackers can actually use.

Q: Why do CI/CD service accounts increase supply chain risk?

A: CI/CD service accounts are dangerous when they can change builds, approvals, or deployments across many systems with one credential. If those identities are overprivileged, an attacker does not need source code access to alter release outcomes. The risk rises further when the same account is reused across environments, because compromise becomes reusable trust rather than a one-time event.

Q: How do security teams know whether a hardened container image is really safer?

A: They should compare the image’s SBOM, runtime profile, and scanner visibility. If the image still carries many dormant packages, the risk may be lower than a standard image, but the operational gain is limited until unreachable code and unnecessary tooling are removed.

Q: Who is accountable when malicious open-source code reaches production pipelines?

A: Accountability usually spans application security, platform engineering, and identity teams because the issue crosses code, pipeline, and credential governance. Frameworks such as NIST CSF and software supply chain controls expect clear ownership for integrity, detection, and response. Organisations need explicit escalation paths for dependency compromise, not informal handoffs.

Technical breakdown

Why curated container images change the CI/CD trust model

Curated container images shift security from post-build remediation to pre-approved baselines. Instead of treating each application image as a fresh aggregation of packages, the model starts from hardened, known-good components and then removes unnecessary libraries and binaries that increase exploitability. That reduces the number of packages scanners must inspect and narrows the path for common CVEs, but it also makes image provenance and scanner compatibility critical. If the image source is opaque or poorly recognised, organisations can lose confidence in the claimed reduction. Practical implication: define who can publish base images and require traceable provenance for every image promoted into the pipeline.

Practical implication: require traceable provenance and controlled publishing for every image promoted into the pipeline.

How SBOM and RBOM complement each other in runtime governance

An SBOM lists the software components present in a build, while an RBOM identifies what code actually executes at runtime. That distinction matters because many vulnerabilities sit in dormant libraries that never execute, yet still expand exposure and compliance effort. Runtime profiling adds evidence on the attack surface that static scanning cannot provide, especially for container workloads that start from broad distributions and then shed functionality over time. The governance value is in reconciling build inventory with execution reality, not in producing more documentation. Practical implication: use both artefacts to separate theoretical exposure from active exposure before prioritising remediation.

Practical implication: use both artefacts to separate theoretical exposure from active exposure before prioritising remediation.

Why attack-surface reduction matters more than vulnerability count alone

A raw CVE total is a weak operational signal if many findings are unreachable or unused. Attack-surface reduction focuses on removing code paths, libraries, and tools that an attacker could actually leverage, which changes the economics of exploitation and the work required from defenders. This approach is especially relevant in software supply chain security, where dependency sprawl and build-tool complexity can create hidden entry points. The practical question is not whether a container contains vulnerabilities, but whether those vulnerabilities can be triggered in the deployed context. Practical implication: prioritise reduction of reachable code paths and unnecessary packages before chasing every low-value finding.

Practical implication: prioritise reachable code paths and unnecessary packages before chasing every low-value finding.

Threat narrative

Attacker objective: The attacker aims to exploit reachable container components or pipeline weaknesses to gain execution, persistence, or downstream access through the software supply chain.

1. Entry occurs when vulnerable or unnecessary components are introduced through the build pipeline or inherited from a broad base image, creating an exploitable software supply chain foothold.
2. Escalation follows when exposed packages, tools, or libraries provide a path from ordinary application execution into broader container or host impact.
3. Impact is realised as attackers exploit reachable code paths, expand the container attack surface, or use the compromised workload as a pivot into connected systems.

NHI Mgmt Group analysis

Curated images create a supply chain control point, not just a packaging choice. The article is really about where organisations choose to establish trust in the software lifecycle. Curated images reduce the breadth of what must be scanned and patched, but they also shift governance pressure onto provenance, scanner compatibility, and approval workflows. For appsec teams, the practical conclusion is that image curation only helps if it is governed as a lifecycle control rather than a convenience layer.

Runtime evidence is the missing control in many container programmes. SBOMs tell you what entered the build, but they do not prove what executes in production. RBOM-style profiling closes that gap by narrowing remediation to active code paths, which is how teams avoid treating theoretical exposure as operational risk. This is a control maturity issue, not just a tooling issue, and it belongs alongside NIST CSF and CIS Controls in container governance.

Software supply chain security is now an identity problem as much as a code problem. Build systems, artifact publishers, and deployment pipelines all rely on machine identities, tokens, and service credentials to move software forward. When those identities are over-privileged or poorly governed, container hardening becomes a downstream bandage rather than a preventative control. The named concept here is execution truth gap: the difference between what the build says is present and what the workload actually runs. Practitioners should treat that gap as a governance signal, not a reporting nuance.

Attack-surface reduction is more actionable than broad vulnerability scoring for container estates. Teams often drown in CVE volume because they lack a way to distinguish reachable exposure from inherited noise. The stronger programme design question is which packages, binaries, and tools can be removed before deployment. That focus aligns with operational resilience because it lowers both exploitability and maintenance burden, and it gives security teams a more defensible prioritisation model.

The market signal is toward integrated supply chain controls that span build and runtime. The article describes a shift away from one-off scanning toward continuous hardening and runtime verification. That direction fits where container security is heading more broadly. For practitioners, the implication is that appsec, platform engineering, and identity governance need a shared operating model for approvals, signing, and runtime visibility.

What this signals

Execution truth gap: container programmes will increasingly be judged on whether they can prove what runs, not just what was scanned. That means platform teams should expect more demand for runtime evidence, supply chain attestation, and tighter linkage between build artefacts and production exposure. The control model is moving toward continuous verification, not periodic review.

Identity governance now reaches deeper into software delivery than many teams assume. CI/CD service accounts, signing tokens, and automated publishing credentials are part of the trust boundary, and they need lifecycle control, not ad hoc ownership. Where those identities are weak, hardened images can reduce fallout but cannot replace upstream governance.

For teams building container controls, the practical watchpoint is whether reduction metrics are tied to real remediation outcomes. If CVE counts drop but the pipeline still permits unknown images, unreviewed tokens, or opaque provenance, the programme has improved reporting more than resilience.

For practitioners

• Establish approved base-image governance Define a short list of approved container base images, require provenance for each one, and block pipeline promotion when an image source cannot be reconciled by standard scanners.
• Pair SBOM with runtime profiling Use SBOM output for build inventory and RBOM or runtime profiling for execution evidence, then route remediation only to packages that are both present and reachable.
• Reduce privileged build identities Review CI/CD service accounts, API tokens, and signing credentials so build systems can publish artefacts without standing privilege that could be abused in a supply chain compromise.
• Measure attack-surface reduction, not only CVE counts Track how many binaries, libraries, and packages are removed from production images, then compare that reduction against exploitability and maintenance effort over time.

Key takeaways

• CI/CD security problems often stem from trust and visibility gaps, not only from vulnerable code.
• The article’s main evidence is that hardening and runtime profiling can reduce exposure materially, but only if provenance and governance are tight.
• Practitioners should treat build identities, runtime evidence, and attack-surface reduction as one control set rather than separate tasks.

Key terms

• Curated Container Image: A curated container image is a pre-built image based on approved components and reduced software content. It is designed to lower exposure by removing unnecessary packages and limiting the code that ships into production, while preserving the application’s required function.
• Pipeline Bill Of Materials: A Pipeline Bill of Materials extends SBOM thinking into the delivery chain by recording what was used, transformed, and promoted during build and release. It matters because many supply chain risks are introduced after code is written, inside automation, packaging, and deployment steps.
• Attack Surface Reduction: Attack surface reduction is the practice of removing or constraining the externally reachable paths an attacker can use to find, authenticate to, or exploit a system. In operational terms, it means shrinking public exposure, closing unused interfaces, and limiting what reachable services can do if compromised.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.

What's in the full article

Rapidsort's full white paper covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of how curated images, profiling, and hardening fit into an existing CI/CD workflow.
• Detailed explanation of the platform's intake, build, and runtime stages for teams designing implementation plans.
• Compliance-oriented evidence generation, including SBOM, RBOM, CIS, and STIG alignment for audit readiness.
• The specific claims behind the near-zero CVE approach and the conditions that affect scanner visibility.

👉 Rapidsort's full white paper covers the build, runtime, and compliance details behind its container hardening model.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security practitioners connect build, runtime, and access governance across modern delivery pipelines.