Remediation

Anchore Enterprise produces a continuous stream of findings against your images — enumerated vulnerabilities discovered in the SBOMs extracted from container images, plus policy failures produced during compliance evaluation. Teams typically learn that a finding needs attention through the Reporting engine (for example, a scheduled “Images With Critical Vulnerabilities” report landing in a team channel, or a “Policy Compliance History by Tag” report showing a newly failing tag), or through direct Notifications when a tag’s vulnerability list or policy-evaluation result changes. Either path surfaces the same underlying data; the difference is whether the team pulls it via a query or is pushed to it via an event.

Knowing about a finding is only the first step — remediation is how teams triage, document, and close out those findings. Anchore Enterprise supports three complementary remediation mechanisms, each suited to a different kind of response.

VEX Annotations on Vulnerability Findings

A VEX annotation (Vulnerability Exploitability eXchange) is a per-vulnerability statement declaring whether a given CVE is actually exploitable in the context of a particular image. Every vulnerability enumerated in an SBOM can be annotated individually, and annotated vulnerabilities are filtered out of reports and dashboards by default — so teams stop re-triaging the same non-exploitable findings on every scan.

Each annotation carries:

  • A status — Not Affected, Affected, Fixed, or Under Investigation.
  • A justification (for Not Affected) — for example, Vulnerable Code Not in Execute Path or Inline Mitigation Already Exists.
  • Free-form impact, action, and additional-detail statements that explain the decision to downstream consumers.

Annotations can be exported as machine-readable VEX documents in OpenVEX or CycloneDX format and shared with customers, auditors, or other stakeholders. They can also drive policy decisions: the vulnerabilities gate accepts filters such as missing annotation and annotation status to enforce an annotation discipline.

For the full status and justification vocabulary, RBAC requirements, and export formats, see Vulnerability Annotations and VEX.

Action Workbench for Policy Failures

When an image fails a policy evaluation, the Action Workbench in the Enterprise UI is where teams plan, assign, and communicate the response. Action Workbench lives on the image’s Artifact Analysis view and surfaces two capabilities:

  • Action plans — a structured grouping of resolutions for the specific policy failures and vulnerabilities on an image. Each resolution associates a remediation message with one or more trigger IDs from the policy evaluation, so the context of the failure travels with the remediation.
  • Notification delivery — an action plan can be dispatched to various destinations such as email, chat tools, and issue trackers through a preconfigured notification endpoint. This makes the workbench the natural bridge from “Anchore Enterprise flagged this” to “the team responsible has been told what to do.” For the canonical list of destinations and their setup, see Supported Endpoints.

Action plans are also available via the API, which lets CI jobs or custom integrations generate them programmatically.

For the action-plan payload, supported types, and permission requirements, see Reporting and Remediation.

Corrections for False-Positive Matches

Not every finding is an exploitability question — some are simply wrong. A vulnerability match is only as accurate as the identifiers Anchore Enterprise attaches to each package, and those identifiers (primarily Package URLs and CPEs) are synthesized from the metadata available at analysis time. That metadata is often incomplete or ambiguous:

  • Java/Maven packages frequently omit the canonical groupId and artifactId from their JAR manifests, so the analyzer has to guess a purl from partial information.
  • Multi-valued version fields in JAR manifests mean the analyzer must pick a “best” version, which may not be the one the vulnerability feed keyed against.
  • CPE candidates are synthesized heuristically from vendor, product, and version metadata, and the synthesized vendor/product string does not always agree with what downstream feeds (NVD, GHSA, vendor feeds) use to describe the same component.

When any of these guesses drifts from the identifier the vulnerability feed actually uses, the package is matched against the wrong vulnerability records — a finding that looks real but does not reflect the software actually installed.

A correction overrides the extracted metadata (CPEs, Package URLs, package name, and related fields) at scan time so subsequent evaluations match against the right identifiers. Corrections are the appropriate tool when the match itself is wrong, as opposed to correct-but-not-exploitable (a VEX case).

For the correction format, supported package types, and worked examples, see Corrections.

Last modified April 22, 2026