Container image vulnerability remediation
rebuild and redeploy, then verify on the deployed digest
A single new image scan can ship sixty CVEs against the base layer, twenty against the application libraries, a handful against vendored binaries, and a dozen Dockerfile rule failures. Many close on an upstream advisory rather than on the deployed image; many close on a base-image rebuild that the dependent services never inherit; many close on a merged pull request that lands on a branch the production stream does not run. Run container image vulnerability remediation as a rebuild-and-redeploy workflow on the engagement record so every finding carries an image-digest binding, a source-class attribution, an asset fan-out across consuming services, a named rebuild target, and a closure scan against the post-rebuild image digest. AppSec, product security, cloud security, vulnerability management, platform engineering, and security engineering teams read the same record across the rebuild and the verification.
No credit card required. Free plan available forever.
Run container image CVE remediation as a rebuild-and-redeploy workflow, not a closed-ticket count
A single new image scan can ship sixty CVEs against the base layer, twenty against the application libraries, a handful against vendored binaries, and a dozen Dockerfile rule failures. Many of the base CVEs are inherited from an upstream distro the team does not own; many of the library CVEs are not reachable from the application; several of the configuration findings are noise against the deployed runtime. Programmes that close container findings on the upstream advisory or on a closed-ticket count find the next scan reopens half the queue, the deployed image still carries the vulnerable layer, the moving-tag in the registry continues to resolve to the old digest, and the auditor reads the activity log and sees a closure without a rebuilt-image reference. Run container image vulnerability remediation as a rebuild-and-redeploy workflow on the engagement record so every finding carries an image-digest binding, a source-class attribution, an asset fan-out across consuming services, a named rebuild target, and a closure scan against the post-rebuild image digest.
The workflow composes with the rest of the vulnerability management operating model. The upstream intake workflow normalises every inbound container finding from the scanners the team runs in the build and registry pipeline. The dependency triage workflow handles the SCA layer in detail; container image remediation reads the SCA call alongside base, binary, and configuration sources to drive the image-rebuild plan. The fix verification workflow closes the loop by running the post-rebuild scan against the deployed digest and recording the proof-of-fix.
Five source classes the workflow accepts on documented terms
Container image scanners produce findings across multiple distinct source classes that look similar in a CVE listing but require different remediation paths. The register makes the sources explicit so the rebuild target reads against the right artefact rather than against an opaque CVE label.
| Source class | Typical CVE examples | What the source captures | How the workflow handles it |
|---|---|---|---|
| Base image CVEs (operating system layer) | OpenSSL, glibc, zlib, curl, BusyBox, Alpine apk packages, Debian dpkg packages, RHEL/UBI rpm packages | Findings produced by a container scanner (Trivy, Grype, Snyk Container, Anchore, Clair, Docker Scout, the registry-native scanner on AWS ECR or GCP Artifact Registry or Azure Container Registry) that reports CVEs against the operating system packages embedded in the base image. The scan output ships as JSON, SARIF, or CSV against the image tag and the digest. | Bulk finding import maps the scanner output to findings management with the image reference (registry, repository, tag, digest), the affected package and version, the CVE identifier, the fixed version, and the layer that introduced the CVE. The asset binding pairs the finding to the image and to every service in the workspace that pulls the image so a single base-image CVE produces one canonical record shared by every dependent service rather than a parallel record per consumer. |
| Application library CVEs (language ecosystem layer) | npm packages, pip packages, Maven artefacts, Go modules, RubyGems, NuGet packages, Cargo crates | Findings produced by code scanning via Semgrep SCA against the manifest and lockfile inside the application layer of the image (package.json plus package-lock.json, requirements.txt, pom.xml, go.mod plus go.sum, Gemfile.lock, packages.lock.json, Cargo.lock). The scan reads the resolved versions the image actually packages, not the intent the manifest declares. | Findings land against the connected repository on the engagement with the affected package, the resolved version, the CVE identifier, the fixed version, the dependency path (direct or transitive), and the CVSS score. The same finding is correlated to the container image asset so the remediation queue reads against both the source-of-truth code change and the image rebuild that ships the fix. |
| Embedded binary CVEs (statically linked layer) | Bundled OpenSSL inside a Go static binary, embedded libxml2 inside a Python wheel, libcurl inside a Node native module | Findings produced by container scanners that perform binary analysis against statically linked or vendored libraries that the OS package manager does not see. The scan output identifies the binary, the embedded library, the inferred version, and the matching CVE through fingerprinting against a CVE database. | Bulk finding import lands the finding against the image with the binary path, the embedded library and version, the CVE, and the detection method (filename match, version-string fingerprint, hash comparison). The triage step records the confidence band (high, medium, low) the scanner attached so the queue does not treat a fingerprint guess and a confirmed package match as equal. |
| Image configuration findings (Dockerfile and runtime layer) | Running as root, missing USER directive, exposed secrets in ENV, hardcoded credentials in Dockerfile, world-writable directories, sensitive ports exposed | Findings produced by image configuration scanners (Hadolint, Trivy config, Checkov, Conftest) and image-policy linting that read the Dockerfile, the resolved image metadata, and the layer history rather than the embedded software. The scan output describes the misconfiguration, the offending line in the Dockerfile, and the recommended remediation. | Findings land against the image and the source Dockerfile in the connected repository with the rule identifier, the line reference, and the recommended fix. The 300+ remediation templates carry configuration-side guidance for the recurring patterns (drop to non-root user, scrub build-time secrets, restrict file permissions, narrow EXPOSE statements) so the closure note does not require re-authoring the remediation for every recurrence. |
| Manual pentest and code review findings against container content | Hardcoded API keys discovered during a manual review, custom binaries with known weaknesses, image-baked configuration drift | Findings written by hand during a manual pentest, a red team exercise, a code review, or a security architecture review of the container image. The tester selects the relevant remediation template, attaches the evidence, calibrates severity against the deployed environment, and writes the bespoke description that the report needs. | Manual entries land against the engagement record with the image reference on the asset binding, the chosen template, the tester-assigned severity, the calibrated CVSS vector, and the attached evidence. The activity log captures the tester, the engagement, and the in-scope acceptance of the manual entry so the chronology reads continuously from the manual discovery into the rebuild-and-redeploy verification. |
Six closure failures that keep container CVEs alive after they have been marked fixed
Most container-image closure problems look like sensible defaults: trust the upstream patch, rebuild the platform base, close the source-side finding. The cost arrives at the next scan when the same CVE reopens against the same image because the closure never reached the deployed digest.
Closure on the upstream advisory rather than on the deployed image
The CVE advisory says the fix is in OpenSSL 3.0.13. The team marks the finding closed because the upstream is patched. The deployed image is still on the old base, the rebuild has not happened, and the next scan reopens the same CVE three days later. Closure has to read against the post-rebuild image digest, not against the upstream changelog.
Base image rebuilt without the dependent services rebuilt
A platform team rebuilds the shared base image with the patched OpenSSL and pushes the new digest. The dependent services still pin the old base tag in their Dockerfiles or in their CI pipelines and inherit the vulnerable layer at next build. The base-image finding closes on the platform queue while every dependent service silently carries the same CVE.
Rebuild lands on a feature branch that never merges to the deployed stream
The engineering owner ships the patch on a feature branch. The branch passes scans, closes the finding, then sits as an open pull request for two sprints. The deployed branch still runs the vulnerable image. The closure note says fixed; the activity log says merged elsewhere.
Image is rebuilt but the registry still serves the old digest under a moving tag
The fix lands and the new image is pushed to the registry under the same tag. The orchestrator pulls by digest, not by tag, and continues to run the old vulnerable image. Closure has to read against the actual running digest, not the tag the registry now resolves.
Transitive base-image lineage is invisible to the closure check
The application image extends a team base image, which extends a platform base image, which extends an upstream distro image. The CVE lives in the platform layer. The closure reads against the application Dockerfile and confirms no direct introduction; the vulnerability persists because the inherited layer was never re-derived. Closure has to walk the FROM chain back to the layer that introduces the CVE.
Exceptions accumulate against not-reachable CVEs with no review trigger
A CVE in a vendored library is documented as not reachable because the application does not call the affected function. The exception lands with no expiry and no review trigger. A year later, the application has changed enough that the reachability claim no longer holds, the library is still vendored, and the exception is invisible to the next triage cycle.
Six fields every container-image finding has to capture on the record
A defensible container-image finding is six concrete fields on the record, not a free-text title and an upstream CVSS. The fields make the next triage cycle, the rebuild plan, the redeploy coordination, and the next audit reconstructable from the finding rather than from a series of pipeline logs.
Image reference and digest binding
The full image reference (registry host, repository, tag, immutable digest) the finding fires against. Tag-only references stall the closure check because a moving tag changes content under the same name. The digest is the only stable handle that pairs a finding to the exact image content the orchestrator runs.
Source class and layer attribution
The classification of the source: base-image OS package, application library via SCA, embedded binary via fingerprinting, image configuration via Dockerfile rule, or manual entry from pentest or review. The attribution carries the layer identifier (or the Dockerfile line) the CVE is introduced on so the rebuild target is unambiguous.
Affected package, resolved version, and fixed version
The package name and the resolved version that ships in the image, not the version the manifest declares. The fixed version (or the affected version range plus the next safe release) so the remediation owner has the explicit upgrade target rather than an open-ended bump.
Asset fan-out across consuming services
The named services in the workspace that pull the affected image. A base-image CVE is one finding with many consumers; the asset fan-out makes the rebuild and redeploy plan readable as a single coordinated change rather than as many parallel tickets that drift apart.
CVSS, EPSS, KEV listing, and reachability call
The auto-calculated CVSS 3.1 base from the upstream advisory, the EPSS percentile if the workspace policy reads it, the CISA KEV listing if applicable, and the explicit reachability call (reachable from the application, reachable through a transitive call path, not reachable, unknown). The combined priority drives the SLA bracket the workspace policy assigns.
Remediation path and rebuild target
The chosen closure path (rebuild on the patched base, upgrade the embedded library and rebuild, replace the vulnerable image with an alternative, accept as a documented exception) and the named rebuild target (the Dockerfile change, the base image bump, the dependency upgrade, the configuration patch) the engineering owner is on the hook to ship.
Five remediation paths that converge on the same finding record
Every container CVE follows one of five closure paths. The path the finding actually took matters less than that the closure rule reads against the deployed image digest rather than against an upstream advisory or a merged pull request.
Rebuild on a patched base image
When this path applies: The CVE lives in the base layer (operating system package or distro-managed library) and an upstream patched base is available.
Closure rule: The rebuild target is the new base image tag and digest. The closure scan reads against the rebuilt image digest, not against the upstream advisory. Every dependent service in the asset fan-out inherits the rebuild and must redeploy under the new digest before the finding closes against that consumer.
Upgrade the application library and rebuild
When this path applies: The CVE lives in an SCA-detected library inside the application layer.
Closure rule: The rebuild target is the dependency upgrade in the lockfile of record and the image rebuild that ships the upgraded layer. The closure scan reads against the new image digest with the SCA finding now reporting the patched version. Closure on a manifest change without a lockfile regeneration does not satisfy the rule.
Replace the vulnerable embedded binary
When this path applies: The CVE lives in a statically linked or vendored binary the package manager does not see.
Closure rule: The rebuild target is the binary replacement (a patched upstream build, a recompile against a patched source, or a dependency swap that removes the embedded copy) and the image rebuild that ships the replacement. The closure scan re-runs the binary fingerprinting against the new image so the closure reads against the post-rebuild detection, not against an asserted swap.
Patch the Dockerfile or runtime configuration
When this path applies: The finding is a configuration issue (USER directive missing, EXPOSE too broad, build-time secret leaking, file permissions too loose) rather than a CVE.
Closure rule: The remediation lands as a Dockerfile patch on the connected repository. The closure scan re-runs the configuration rule against the rebuilt image. Closures on a merged pull request without a rebuild verification do not satisfy the rule because the deployed image is the artefact the runtime carries.
Documented exception with expiry and review trigger
When this path applies: No fix is available, the cost of the upgrade exceeds the benefit, the vulnerable code path is genuinely unreachable, or the patch breaks a downstream API the consuming service cannot move off in the SLA window.
Closure rule: The exception lands in the exception register with the named approver, the documented rationale, the explicit expiry, and the review trigger (next certification cycle, next major release, next quarter, or 180 days max). The exception inherits into the intake check so the next scan does not re-litigate it.
Eight queues the workflow runs in parallel during the operating week
Container-image remediation runs eight concurrent queues. Each one has a named owner, a documented cadence, and an escalation rule so base-image fan-out, configuration debt, exception expiries, and registry digest drift surface before they become silent gaps.
- Open finding queue with each container CVE captured in the last seven days, the source class, the image digest, the asset fan-out, the calibrated severity, and the named owner of record. The view the on-call AppSec operator and the platform engineering rotation read against the daily standup.
- Base-image fan-out queue with each base-image finding, the rebuild target (new digest), the dependent services that have not yet redeployed under the new digest, and the elapsed time since the platform team shipped the rebuild. The view that prevents the silent gap between base-image patching and dependent-service rollout.
- Reachability override queue with each SCA finding where the calibrated reachability differs from the upstream advisory default, the named triager, the rationale, and the activity-log entry. The view the security architect and the AppSec lead read to confirm reachability decisions are landing on the record rather than in chat.
- Configuration debt queue with each Dockerfile rule failure (non-root user missing, secrets leaking, broad EXPOSE, file permissions too loose), the source repository, the recommended remediation, and the named owner. The view that keeps the misconfiguration backlog visible alongside the CVE queue rather than burying it under CVE volume.
- Exception register queue with each accepted container-image risk, the named approver, the rationale, the expiry, and the review trigger. The view the GRC partner and the AppSec lead read on a quarterly cadence to keep stale acceptances from rotting into permanent backlog.
- Closure verification queue with each finding closed in the last fourteen days, the post-rebuild image digest the closure scan ran against, the verifier, and the verification timestamp. The view that confirms closure on the rebuilt image rather than on the upstream changelog.
- Registry digest drift queue with each running service whose deployed digest is older than the latest digest the registry now serves under the same tag, the elapsed time, and the named owner. The view that catches the moving-tag failure mode before the next scan does.
- SBOM and VEX export queue with each image whose SBOM is ready to ship to a customer security evidence room or to a supplier security questionnaire, the consuming party, the VEX statements for the open CVEs, and the named approver. The view that keeps the SBOM and VEX export aligned with the live remediation state rather than ageing in a folder.
How container image remediation runs in SecPortal
The remediation workflow rides on the feature surfaces the security programme already uses. Container scanner output lands through bulk finding import, code scanning via Semgrep covers SCA against the connected repository, findings management is the canonical record per finding, team management routes the owner of record under RBAC, document management holds the SBOM and VEX artefacts, the activity log captures every state transition, and notifications push the rebuild assignment to the named owner.
Bulk import for scanner output
Bulk finding import maps Trivy, Grype, Snyk Container, Anchore, Clair, Docker Scout, or any CSV scanner output to findings management with the image reference, digest, package, version, CVE, and layer attribution; column-mapping templates make recurring imports a one-click operation.
Findings management as the queue
Findings management is the canonical record per CVE with auto-calculated CVSS 3.1, the workspace severity policy, the 300+ remediation templates, and the activity log of every triage, rebuild, and verification event.
Code scanning for SCA layer
Code scanning via Semgrep runs SCA against the manifest and lockfile of the connected repository on a defined cadence so the application library layer of the image has a continuous source-side record alongside the image-side scanner output.
Repository connections for Dockerfile changes
Repository connections via GitHub, GitLab, or Bitbucket OAuth give the workflow read access to the Dockerfile, the manifests, the lockfiles, and the commit history so the rebuild target reads against a versioned source artefact rather than a hand-passed file.
Engagement management for fan-out
Engagement management structures the image, the dependent services, and the rebuild plan as one engagement record so the asset fan-out from a base-image CVE is queryable rather than spread across many parallel tickets.
RBAC for owner-of-record routing
Team management role-based access control assigns the rebuild owner (platform engineering for base images, application engineering for libraries, the build pipeline owner for Dockerfile changes) and grants the scope needed to triage and remediate without over-sharing access.
Document management for SBOMs and VEX
Document management holds the per-image SBOM exports (SPDX or CycloneDX), the VEX statements per CVE, and the source scanner exports as versioned artefacts the finding cites and the customer evidence room reads against.
Retesting for post-rebuild verification
Retesting workflows run the closure scan against the post-rebuild image digest and attach the verification evidence to the original finding so the closure reads on proof rather than on the upstream advisory.
Notifications to the rebuild owner
Notifications and alerts push the rebuild assignment, the base-image fan-out coordination, the SLA breach escalation, and the verification result to the named recipients so the routing decision lands in front of the right person.
Activity log for the chain of custody
Activity log with CSV export captures the source class, the image digest, the rebuild target, the redeploy reference, the verification scan, and the named actor on every state transition so the audit chain reads continuously.
AI reports for status summaries
AI reports generate the rebuild-and-redeploy status, the open container-image CVE summary by source class, and the leadership view for the engagement so the steering committee reads against live data rather than a stale slide.
Compliance tracking across frameworks
Compliance tracking maps the workflow to ISO 27001 Annex A 8.8 and A 8.25, SOC 2 CC7.1 and CC8.1, PCI DSS 6.3.1 and 6.4.3, NIST 800-53 RA-5 and SI-2 and CM-3 and SR-3, NIST CSF 2.0 ID.RA and PR.PS and DE.CM, and CIS Controls v8.1 Control 7, 16, and 4.
Audit frameworks that read against the container-image workflow
Most enterprise audit cycles ask for evidence that container-image vulnerabilities are captured with traceable provenance, normalised severity, named ownership, and a documented rebuild-and-redeploy closure. The workflow produces the evidence those audits read against.
ISO 27001:2022
Annex A 8.8 (management of technical vulnerabilities) reads against the container-image remediation workflow as the discipline that captures every CVE in the base image, the application library layer, the embedded binary layer, and the Dockerfile configuration, normalises severity against the workspace policy, binds the finding to the image digest and the consuming services, and routes the rebuild target to a named engineering owner with a documented timeline. Annex A 8.25 (secure development lifecycle) reads against the rebuild-and-redeploy closure rule so the closure evidence is the post-rebuild image digest, not the upstream advisory.
SOC 2 Trust Services Criteria
CC7.1 (system operations and monitoring) reads against the workflow as the discipline that detects container-image vulnerabilities across base images, application libraries, embedded binaries, and image configuration on a documented cadence. CC8.1 (change management) reads against the rebuild-and-redeploy closure as the structured change that ships the patched image to the deployed environment with the activity log entry on every state transition. CC9.1 (risk mitigation) reads against the exception register so accepted container-image risks have a named approver and an expiry.
PCI DSS v4.0
Requirement 6.3.1 (security vulnerabilities are identified and managed using industry-recognised sources) reads against the workflow as the gateway that captures CVEs from container scanners (base-image CVEs, embedded binary CVEs, SCA), normalises severity, and routes the rebuild target. Requirement 6.4.3 (changes to the system are managed) reads against the rebuild-and-redeploy discipline that ships the patched image into the cardholder data environment under documented change control.
NIST SP 800-53 Rev. 5
RA-5 (vulnerability monitoring and scanning) reads against the workflow as the consolidated record of detected container-image vulnerabilities across the base, library, binary, and configuration layers. SI-2 (flaw remediation) reads against the rebuild-and-redeploy closure rule that converts intake into deployed remediation. CM-3 (configuration change control) reads against the image rebuild as the change that ships the patched configuration. SR-3 (supply chain controls and processes) reads against the base-image and embedded-binary attribution because container image vulnerabilities are supplier-introduced flaws by definition.
NIST CSF 2.0
ID.RA (risk assessment) reads against the source-class attribution, the asset fan-out across consuming services, and the reachability call as the structured assessment of container-image risk. PR.PS (platform security) and PR.IR (technology infrastructure resilience) read against the rebuild discipline that maintains the patched image as the deployed artefact. DE.CM (continuous monitoring) reads against the registry digest drift queue and the post-rebuild verification scan. RS.MA (incident management) reads against the zero-day path for container CVEs that escalate during an exposure window.
CIS Controls v8.1
Control 7 (continuous vulnerability management) reads against the workflow as the operational discipline that produces a complete and prioritised view of container-image vulnerabilities across the estate. Control 16 (application software security) reads against the SCA and Dockerfile-configuration layers. Control 4 (secure configuration of enterprise assets and software) reads against the Dockerfile rule queue and the configuration debt view that keep image hardening visible alongside the CVE queue.
Where the workflow fits in the wider operating model
Container-image remediation sits between the upstream intake of scanner output and the downstream closure verification, alongside dependency triage and the source-side DevSecOps scanning workflow. The references below trace how the structured remediation record carries across the adjacent disciplines.
Finding intake
The vulnerability finding intake workflow is the front-door discipline that normalises container scanner output, code scan output, and manual entries before they reach the remediation queue.
Dependency triage
The dependency vulnerability triage workflow covers the SCA layer in detail with reachability classification and the upgrade-path decision that the image-rebuild plan reads from.
SBOM and VEX publishing
The SBOM management and VEX publishing workflow keeps the per-image SBOMs and the VEX statements aligned with the live remediation state so downstream consumers read accurate evidence.
DevSecOps scanning
The DevSecOps scanning workflow covers the broader source-side scanning surface (SAST, SCA, secret scanning) that the container build pipeline shares as upstream inputs.
Exception management
The exception management workflow is the register the intake checks against so not-reachable CVEs and accepted risks do not re-litigate at every scan cycle.
Prioritisation
The prioritisation workflow ranks the container queue with CVSS, EPSS, KEV, reachability, and asset criticality so the rebuild plan reads in defensible order rather than upstream advisory order.
SLA management
The SLA management workflow applies the rebuild-and-redeploy SLA window to each container finding so the closure scan runs within the documented bracket rather than the operator memory.
Fix verification at closure
The fix verification workflow runs the post-rebuild scan against the deployed image digest and records the proof-of-fix evidence the audit reads against.
Leadership reporting
The security leadership reporting workflow surfaces the container-image remediation throughput, the base-image rebuild lag, and the exception-backlog trend on the regular leadership cadence.
Buyer audiences for the container-image workflow
The workflow serves the operators and leaders responsible for the discipline that decides how container image vulnerabilities reach the deployed runtime and how the closure proves the deployed image is the patched one. Each audience reads the workflow with a slightly different lens.
AppSec teams
AppSec teams own the SCA and application-library remediation path; the workflow gives them the rebuild target and the redeploy verification rather than only the source-side closure.
Product security teams
Product security teams read the workflow as the SDLC and PSIRT-adjacent discipline that pairs the source-side findings with the image artefact the product actually ships.
Cloud security teams
Cloud security teams read the workflow as the image-side complement to the deployed-cluster posture; the rebuild target ships the patched image the cluster runtime then carries.
Vulnerability management teams
Vulnerability management teams read the workflow as the container slice of the broader remediation queue, with the same intake, prioritisation, SLA, and exception discipline applied to image-side findings.
Platform engineering teams
Platform engineering teams own the base-image rebuild; the workflow surfaces the dependent-service fan-out so the platform rebuild coordinates with the consuming services rather than landing in isolation.
Security engineering teams
Security engineering teams read the workflow as the operating model for image-side risk that the secure-build pipeline and the supply-chain controls feed.
GRC and compliance teams
GRC and compliance teams read the workflow as the evidence chain for technical vulnerability management in containerised environments under ISO 27001, SOC 2, PCI DSS, and NIST audits.
Internal security teams
Internal security teams read the workflow as the operating discipline that makes the container-image side of the remediation programme as defensible as the source-side or the infrastructure-side.
CISOs and security leaders
CISOs read the workflow as the leading indicator of whether the container-image programme closes on deployed digests or on closed-ticket counts the next scan reopens.
Long-form guides that pair with this workflow
Three deeper guides build on the discipline this workflow describes. They explain the broader cloud security context, the SCA versus SAST distinction the workflow reads against, and the SBOM and VEX publishing pattern downstream consumers expect.
Cloud security assessment guide
Cloud security assessment guide covers the wider assessment scope: cloud posture, identity, network, data, and application layers, of which container images are one critical artefact.
SAST versus SCA code scanning
SAST versus SCA code scanning explains the distinction the container-image workflow reads against when triaging application-library CVEs versus Dockerfile rule failures.
Software bill of materials guide
Software bill of materials guide describes how the per-image SBOM and the VEX statements travel downstream of remediation as the evidence customers and suppliers read.
Frequently asked questions
What is a container image vulnerability remediation workflow?
A container image vulnerability remediation workflow is the structured discipline that captures vulnerabilities discovered in container images (base-image operating system CVEs, application library CVEs via SCA, embedded binary CVEs, Dockerfile configuration issues, and manual review findings) and drives each one to closure through a rebuild-and-redeploy path against the deployed image digest. The workflow runs as a continuous loop: detect on a scan, triage the source class and the asset fan-out, assign a rebuild target to a named engineering owner, ship the rebuild, redeploy the image to the production-equivalent surface, and verify the closure by re-running the scan against the post-rebuild digest. Without this discipline, container CVEs close on upstream advisories rather than on deployed images and the next scan reopens them.
How is this different from dependency vulnerability triage?
Dependency vulnerability triage focuses on the software composition analysis layer inside the application code: CVEs in npm, pip, Maven, Go modules, RubyGems, NuGet, and similar package ecosystems detected against the lockfile of record. Container image remediation covers SCA as one of five source classes alongside base-image OS package CVEs, embedded binary CVEs, Dockerfile configuration findings, and manual review findings against image content. Both workflows share findings management, the activity log, and the closure discipline, but the container-image workflow adds the image-digest binding, the asset fan-out across consuming services, and the rebuild-and-redeploy closure rule that maps CVEs to a deployed artefact rather than a source change.
How is this different from a CSPM or KSPM workflow?
Cloud security posture management and Kubernetes security posture management workflows assess the configuration and security posture of the deployed cloud and orchestrator surface: cluster role bindings, network policies, exposed services, public storage buckets, and the like. The container-image remediation workflow is upstream of the deployed cluster: it operates on the image artefact itself before and as it ships through the registry, the build pipeline, and the deployment pipeline. SecPortal supports the image-side workflow through findings management, bulk finding import, code scanning, document management, retesting, and compliance tracking. Cluster-side posture, admission control, and runtime workload protection are not native to the platform and are not implied by this workflow.
Does SecPortal scan container registries directly?
SecPortal does not ship a native container registry scanner that pulls images from AWS ECR, GCP Artifact Registry, Azure Container Registry, Docker Hub, GitHub Container Registry, or a private Harbor instance. The platform consumes the output of the container scanner the team already runs (Trivy, Grype, Snyk Container, Anchore, Clair, Docker Scout, the registry-native scanner) through bulk finding import with column mapping, plus code scanning via Semgrep for SCA against connected repositories. The remediation workflow operates against the consolidated record once findings land on the engagement; the scan itself runs in the team existing scanning pipeline.
How does the workflow handle base-image CVEs that fan out to many services?
A base-image CVE is one canonical finding with many consumers. The image reference binds to the base image; the asset fan-out lists every service in the workspace that pulls the affected image; the rebuild target is the new base-image digest; the closure rule requires every dependent service to redeploy under the new digest before the finding closes against that consumer. Findings management keeps the parent record canonical so the activity log reads as one coordinated remediation rather than as many parallel records that drift apart on different timelines. The base-image fan-out queue surfaces dependent services that have not yet redeployed under the new digest so the silent gap between platform patching and consumer rollout becomes visible on the morning standup.
How does the workflow handle SCA findings inside the image versus SCA findings in source?
SCA findings against the manifest and lockfile of the connected repository land through code scanning as source-side records. SCA findings against the resolved lockfile inside the container image land through bulk finding import as image-side records. Both correlate to the same package and CVE; the workflow keeps the relationship explicit so the engineering owner sees one finding with two evidence sources rather than two findings that look duplicate to the audit and parallel to the team. The rebuild target is the dependency upgrade in the lockfile of record plus the image rebuild that ships the upgraded layer.
How does the workflow handle the moving-tag failure mode in container registries?
Container tags are mutable references; the same tag can resolve to different digests over time. Closure on a tag without a digest pin is a closure that does not survive the next pull. The workflow records the image digest on the finding at intake, requires the closure scan to run against the post-rebuild digest, and surfaces a registry digest drift queue that catches running services whose deployed digest lags the latest digest the registry serves under the same tag. The drift queue makes the failure mode visible operationally rather than waiting for the next scheduled scan to flag it.
How does the workflow handle exceptions for not-reachable CVEs?
Exceptions for not-reachable CVEs (the application does not call the affected function, the binary is loaded only in a test profile, the configuration value is not referenced) land in the exception register with the named approver, the documented rationale, the explicit expiry, and the review trigger. The intake check reads the register so the next scan that re-detects the same CVE inherits the existing exception rather than producing a new ticket the team has to dismiss. The exception register queue runs on a quarterly cadence so stale acceptances do not rot into permanent backlog when the application changes enough that the reachability claim no longer holds.
How does the workflow handle SBOM and VEX export for downstream consumers?
When a customer security evidence room request or a supplier security questionnaire asks for the SBOM and the VEX statements for an image, the SBOM and VEX export queue keeps the artefacts aligned with the live remediation state. Open CVEs map to VEX statements (under_investigation, affected with the documented impact, not_affected with the documented justification, fixed with the post-rebuild reference). Document management holds the versioned SBOM and the VEX exports the consuming party reads against. The detailed sbom-management-and-vex-publishing workflow runs alongside as the downstream evidence-handover discipline.
Does the workflow require integrations with Kubernetes admission control or runtime workload protection?
No. The remediation workflow operates on the workspace record itself: findings management, bulk finding import, code scanning, document management, retesting, activity log, and compliance tracking. Kubernetes admission control (OPA Gatekeeper, Kyverno) and runtime workload protection (Falco, container runtime CWPP agents, Wiz, Lacework, Sysdig, Prisma Cloud) are not native to SecPortal and are not implied by this workflow. Teams that run those controls operate them in parallel; the platform does not ship integrations to them.
How it works in SecPortal
A streamlined workflow from start to finish.
Capture container scanner output as findings on the engagement record
Bulk finding import maps the output of the container scanner the team already runs (Trivy, Grype, Snyk Container, Anchore, Clair, Docker Scout, or the registry-native scanner) into findings management with the image reference, the digest, the affected package, the CVE identifier, the fixed version, and the layer that introduces the CVE. Code scanning via Semgrep covers the SCA layer against the connected repository so the application library findings have a continuous source-side record alongside the image-side output. Findings land on the engagement record with provenance the audit can trace back to the source artefact.
Classify the source class and bind the finding to the image digest
Every container CVE belongs to one of five source classes: base-image OS package, application library via SCA, embedded binary via fingerprinting, image configuration via Dockerfile rule, or manual entry from pentest or code review. The classification carries the layer identifier or the Dockerfile line the CVE is introduced on so the rebuild target is unambiguous. The image-digest binding pairs the finding to the exact image content the orchestrator runs; tag-only references stall the closure check because a moving tag changes content under the same name.
Resolve the asset fan-out across consuming services
A base-image CVE is one canonical finding with many consumers. The asset fan-out lists every service in the workspace that pulls the affected image so the rebuild and redeploy plan reads as a single coordinated change rather than as many parallel tickets that drift apart on different timelines. Application-library and configuration findings often fan out across multiple builds when the same code path or Dockerfile pattern ships across several images.
Prioritise with CVSS, EPSS, KEV, reachability, and asset criticality
Upstream CVSS alone produces a queue that buries the actually dangerous CVEs under a wave of unreachable mediums. The prioritisation step combines the CVSS base from the upstream advisory, the EPSS percentile, the CISA KEV listing if applicable, the explicit reachability call, and the asset criticality on the engagement for blast radius. The combined priority drives the SLA bracket the workspace policy assigns and the rebuild order the platform team and the application teams agree on.
Route the rebuild target to a named engineering owner
Different source classes route to different owners. Base-image findings route to the platform team that owns the shared base. Application-library findings route to the application owner whose lockfile of record holds the resolved version. Dockerfile configuration findings route to the build pipeline owner. Manual findings route to the security engineer who recorded them. The asset-to-owner mapping on the engagement resolves the routing as a query; the routing event lands on the finding with the named owner, the inheritance rationale, and the SLA so the work crosses the seam from triage into engineering on a deliberate decision rather than dissolving in a hallway conversation.
Drive the rebuild, the upgrade, the configuration patch, or the documented exception
Five closure paths converge on the same record. Rebuild on a patched base image is the default for base-layer CVEs; upgrade the application library and rebuild is the default for SCA-layer CVEs; replace the vulnerable embedded binary and rebuild is the path for statically linked CVEs; patch the Dockerfile or runtime configuration and rebuild is the path for configuration findings; documented exception with expiry and review trigger is the path for not-reachable CVEs and accepted risks. Each path produces evidence the audit can read; the difference is the path the finding actually took, not whether the closure was recorded.
Coordinate the redeploy across every consumer in the asset fan-out
A base-image rebuild that the dependent services never inherit closes the finding on the platform queue while every consumer silently carries the same CVE. The base-image fan-out queue surfaces dependent services that have not yet redeployed under the new digest so the silent gap between platform patching and consumer rollout becomes visible on the morning standup. The closure rule applies per-consumer: the finding closes against a consumer when that consumer redeploys under the rebuilt digest, not when the rebuild happens upstream.
Verify the closure with a post-rebuild scan against the deployed image digest
Retesting runs the closure scan against the post-rebuild image digest and attaches the verification evidence to the original finding. Closure on the upstream changelog or on a merged pull request without a deployed-image verification does not satisfy the rule. The registry digest drift queue catches running services whose deployed digest lags the latest digest the registry now serves under the same tag so the moving-tag failure mode is operationally visible rather than waiting for the next scheduled scan to flag it. Verified-fixed findings close with the proof attached and the activity log entry stamped; closures that did not survive the re-scan stay open with the reopen reason captured.
Features that power this workflow
Vulnerability management software that tracks every finding
Bulk finding import bring your scanner data with you
Find vulnerabilities before they ship
Repository connections for SAST and SCA
Orchestrate every security engagement from start to finish
Collaborate across your entire team
Document management for every security engagement
Verify fixes and track reopens on the same finding record
Notifications and alerts for the people who carry the work
Every action recorded across the workspace
AI-powered reports in seconds, not days
Compliance tracking without a full GRC platform
Run container image CVE remediation on the deployed digest, not on the upstream changelog
Image-digest binding, source-class attribution, base-image fan-out, named rebuild targets, and a post-rebuild closure scan that proves the deployed image is the patched one. Start free.
No credit card required. Free plan available forever.