Container Image Patching. No Dockerfile. No Rebuild.
HarborGuard rewrites vulnerable OS package layers in-place, pushes the patched image back to your registry under a new tag, and automatically re-scans to confirm the CVEs are gone. No Dockerfile change, no CI rebuild, no broken layer cache.
0
Dockerfile changes required
2–30 min
Typical patch time
OS-layer
Patch scope
100%
Auto re-scan post-patch
What it does
Remediate OS-layer CVEs without touching your build pipeline.
Most CVEs found in container images live in OS packages — curl, openssl, libssl, glibc, expat, libxml2. These packages were installed in a base image weeks or months ago and have since received security updates. The conventional fix requires updating the FROM line in a Dockerfile, rebuilding the image, waiting for CI to pass, and deploying. That process typically takes 2 to 5 days including review cycles. For a CRITICAL CVE with a 72-hour SLA, the rebuild timeline is the bottleneck.
HarborGuard's patch engine bypasses the build cycle entirely. It pulls the existing image, identifies the layer where the vulnerable package was installed, rewrites that layer with the patched package binary (selected by the package manager detected in the scan findings), and produces a new OCI image. No Dockerfile, no CI run, no rebuild from scratch.
The patched image is pushed to the registry under a new tag (for example api-server:v2.14.1-patched), keeping the original image intact. A follow-up scan immediately runs the same six-scanner pipeline against the patched tag to confirm remediation. The complete chain — original scan, patch operation, follow-up scan — is stored in the audit log with source and patched digests, patched packages, and MTTR.
How it works
Container image patching, step by step.
Select CVEs to patch from a completed scan
From the scan detail page, choose one or more fixable CVEs. The platform validates that all selected CVEs share a patchable package type and that a fixed version is available upstream. Mixed package manager selections are rejected early.
Choose a sink registry and tag
Specify where the patched image will be pushed: a sink registry (which can be the same as the source or a different one in the same organization) and the output tag. The sink registry must belong to the same organization and have valid push credentials.
The plan billing gate runs
The platform checks your plan's patching entitlement before dispatching. Free-tier organizations have a lifetime patch limit; Team and Enterprise plans have unlimited patches. The check runs before any DB writes so limit errors are clean rejections with no orphan rows.
The patch operation is created and dispatched
A patch operation record is created with PENDING status. The platform enqueues the patch on its job queue and transitions the record to DISPATCHED atomically, preventing race conditions if retries fire.
Source and sink registry credentials are resolved
The patch worker resolves credentials for both the source and sink registries independently. Source credentials authorize the pull. Sink credentials authorize the push. Both are decrypted from AES-256-GCM envelope storage and validated before the container is dispatched.
The sensor container rewrites the layers
An ephemeral sensor container (with dedicated CPU and memory) pulls the source image, applies package updates to the affected layers, and produces a new OCI image with patched binaries. No Dockerfile is needed.
Patched image is pushed to the sink registry
The sensor pushes the patched OCI image to the sink registry under the specified tag. The new image digest is captured and recorded on the patch operation. The source scan's vulnerabilities for patched packages are marked as remediated.
Automatic re-scan confirms CVEs are remediated
For registry sinks, a follow-up scan is automatically queued against the patched image tag. The follow-up scan runs the same six-scanner pipeline as the original scan, confirming that the patched CVEs are no longer present. Results are linked to the patch operation for traceable before-and-after evidence.
Source and sink registry credentials
Container image patching is unique among HarborGuard operations in that it requires credentials for two different registries: the source registry (to pull the image for patching) and the sink registry (to push the patched result). These can be the same registry, the same organization's different registries, or different registries with different credential sets.
Source credentials
Resolved from the image tag's parent registry. Used to pull the source image into the patch container. If the source registry requires authentication, the credential is decrypted from AES-256-GCM envelope storage and passed securely to the sensor container.
Sink credentials
Resolved from the explicitly specified sink registry record. Passed independently of the source credentials so the patched image can be pushed to a different registry if you choose. If the sink registry is the same as the source, both credential lookups resolve to the same record.
Registry sink (OCI push)
The default sink kind. The patched image is pushed as a standard OCI manifest to the sink registry under the specified tag. This path triggers a follow-up scan automatically after the push succeeds.
S3 / presigned sink (object storage)
For registries configured with an S3 or presigned sink kind, the patched image is stored as a docker-archive tarball in S3-compatible object storage. This path is used when the patched image needs to go to a bucket rather than a registry. Follow-up scans are not automatic for object-storage sinks.
Patch audit trail and remediation timeline
Every patch operation captures a complete remediation timeline for compliance evidence. The audit log records who requested the patch, when it was dispatched, the source image digest, which packages were patched and to which versions, the patched image digest, and a link to the follow-up scan. The source scan's vulnerabilities for patched packages carry remediation timestamps that power MTTR (mean time to remediation) calculations.
Patch lifecycle
PENDING → DISPATCHED
On creation, the platform records the requesting actor, the source scan ID, the target sink registry, the requested tag, and the list of CVEs selected for patching. The atomic transition from PENDING to DISPATCHED prevents race conditions if retries fire.
DISPATCHED → RUNNING
The patch worker resolves source and sink credentials, validates the sink permission to push, and dispatches the sensor container. State transitions are recorded in the audit log with timestamps.
RUNNING → SUCCESS
The sensor produces the patched OCI image, pushes it to the sink registry, captures the new digest, and posts the patch envelope back to the platform. Vulnerabilities for patched packages are marked remediated; a follow-up scan is queued automatically.
RUNNING → FAILED → ROLLBACK
If the sensor fails or the push is rejected, the operation transitions to FAILED, no remediation timestamps are written, and the source image and its vulnerabilities remain untouched. The failure reason and any rollback steps taken are captured in the audit log.
What is and is not patchable
Patchable
- OS packages with a fixed version available upstream
- apt/dpkg packages (Debian, Ubuntu)
- apk packages (Alpine Linux)
- yum/rpm packages (RHEL, CentOS, Amazon Linux)
- CVEs where the package manager is deterministically identifiable from scan findings
Not patchable via this method
- CVEs with no fixed version published upstream
- Application-layer vulnerabilities in your own code
- Libraries statically compiled into application binaries
- CVEs whose fix requires a multi-package dependency resolution
- Java/.NET runtime vulnerabilities embedded in application JARs
Explore related capabilities
Questions about container image patching
How does in-place container image patching work without a Dockerfile?
Traditional image remediation requires updating a Dockerfile, rebuilding from source, waiting for your CI pipeline, and re-deploying. HarborGuard's patch engine takes a different approach: it pulls the existing image, identifies which OS layers contain the vulnerable packages, and rewrites those layers with the patched package binaries. The patched image retains all your application layers unchanged — only the OS package layers are modified. The result is a new OCI image with a new digest pushed back to your registry under the tag you specify. No Dockerfile, no rebuild, no broken layer cache.
Which CVEs are patchable?
A CVE is patchable if: (1) the vulnerability record includes a fixed version, and (2) the package type is one that the patch engine supports — OS packages (deb, rpm, apk), plus select language package managers. CVEs without a fixed version cannot be patched automatically. CVEs in packages that are statically compiled into application code rather than installed as OS or runtime packages are not patchable via this method. The scan detail page shows a 'patchable' indicator on each finding so you can see which CVEs qualify before creating a patch request.
Does the patched image get automatically re-scanned?
Yes, for registry-sink patches. After the sensor pushes the patched image and posts the patch envelope back to the platform, the ingest pipeline creates a follow-up scan record linked to the patch operation. The follow-up scan runs the same six-scanner pipeline as the original scan. If the re-scan finds that the patched CVEs are still present (for example, the upstream fix was incomplete), the result is visible on the patch detail page and in the new scan. For object-storage sinks (S3, presigned), the follow-up scan is intentionally skipped because the output is a docker-archive tarball that cannot be pulled as an OCI image ref.
How long does a patch operation take?
Patch times depend on the size of the image, the number of packages being patched, and the speed of the sink registry push. The sensor container runs on dedicated CPU and memory so it can hold the entire image layers in memory during the overlay application. A typical Alpine-based image with one to three OS package patches takes 2 to 5 minutes. Large multi-layer images patching many packages can take up to 30 minutes. The hard ceiling is 40 minutes. All patch operations are tracked in the dashboard with per-package status (SUCCESS/FAILED per patched package).
What is a follow-up scan and how does it link to the patch?
A follow-up scan is an automatic container vulnerability scan triggered immediately after a successful patch operation. It scans the patched image using the same scanners as the original scan, and the resulting scan record is linked back to the patch operation. The follow-up scan serves as verification evidence: it confirms which CVEs are now absent, producing a before-and-after evidence chain for compliance reporting. Both the original scan and the follow-up scan IDs are included in patch audit log entries, creating a complete remediation timeline with MTTR (mean time to remediation) tracking.
Patch your first critical CVE today
Start your 14-day trial. Patch a CRITICAL CVE without touching your Dockerfile.
Scan an image, select the patchable CVEs, and watch the patched image land in your registry in minutes. No Dockerfile change. No CI run.