False Positives

False positives in vulnerability scanning fall into two distinct categories, and Anchore Enterprise gives you a different tool for each:

The package was identified correctly, but its metadata is wrong — the analyzer guessed a CPE or PURL that doesn’t line up with how vulnerability data describes the same component. Findings either appear that shouldn’t, or fail to appear at all. Fix with Corrections.
The package was not identified at all — your build installs software that Anchore Enterprise’s analyzers don’t recognize, so the SBOM (and therefore the scan) misses it entirely. Fix with Hints.

Corrections and Hints apply only to packages discovered through container image analysis — they do not modify externally supplied SBOMs.

Both features are user-controlled refinements that sit alongside Anchore Enterprise’s built-in false-positive controls — see Reducing False Positives and Noise for the broader context. For the matching pipeline that produces every vulnerability finding before these controls apply, see How It Works.

1 - Corrections

A correction is a rule that rewrites a package’s metadata at vulnerability-scan time. Anchore Enterprise’s analyzers generate a best-effort PURL and CPE for every package they find, but for some ecosystems — particularly Java archives that ship without a complete manifest — the guess does not match what vulnerability data uses to identify the same component. The result is either spurious matches or missed matches. A correction restates the package’s PURL, CPEs, or other fields so that subsequent scans match against the right vulnerability records.

For the broader context — how SBOM packages get matched against vulnerability data, and the synthetic-CPE fallback that handles unknown ecosystems — see How It Works.

Corrections apply only to packages discovered through container image analysis; they do not modify externally supplied SBOMs.

When to Add a Correction

A worked example: an Anchore Enterprise analysis of a Tomcat image surfaces the catalina.jar archive with this content:

{
  "cpes": [
    "cpe:2.3:a:apache:catalina:9.0.88:*:*:*:*:*:*:*"
  ],
  "package": "catalina",
  "purl": "pkg:maven/org.apache.tomcat-catalina/[email protected]",
  "type": "JAVA-JAR",
  "version": "9.0.88"
}

The CPE vendor/product (apache:catalina), the Maven group/artifact in the PURL (org.apache.tomcat-catalina/catalina), and the package name (catalina) all disagree with how the upstream advisory data describes Tomcat Catalina. Vulnerability matches against this package will be unreliable.

Add a Correction

Corrections are managed with anchorectl correction. The command supports both an inline form and a JSON-file form.

anchorectl correction add \
  --description "Correct Tomcat Catalina package metadata" \
  --type java \
  --match package=catalina \
  --replace cpes="cpe:2.3:a:apache:tomcat_catalina:{version}:*:*:*:*:*:*:*" \
  --replace purl="pkg:maven/org.apache.tomcat/tomcat-catalina@{version}" \
  --replace package="tomcat-catalina"

Or, the equivalent JSON body submitted directly:

anchorectl correction add -i correction.json

{
  "description": "Correct Tomcat Catalina package metadata",
  "type": "package",
  "match": {
    "type": "java",
    "field_matches": [
      { "field_name": "package", "field_value": "catalina" }
    ]
  },
  "replace": [
    { "field_name": "cpes", "field_value": "cpe:2.3:a:apache:tomcat_catalina:{version}:*:*:*:*:*:*:*" },
    { "field_name": "purl", "field_value": "pkg:maven/org.apache.tomcat/tomcat-catalina@{version}" },
    { "field_name": "package", "field_value": "tomcat-catalina" }
  ]
}

Field reference:

description — free-text note describing the correction’s intent.
type — the correction type. Only package is supported.
match.type — the package ecosystem to apply the correction to. In the inline form this is what the --type flag sets; the correction type is always package. Supported values are driven by the analyzers your deployment runs and currently include java, gem, python, npm, os, go, and nuget. Run anchorectl image content --available-types to list the valid content types on a given deployment.
match.field_matches — one or more (field_name, field_value) pairs that select which packages this correction applies to.
replace — the field/value pairs the correction will write. For cpes and purl only, curly-brace templates like {version} are substituted from the matched package at scan time. If a templated field is missing on the package, the CPE component is replaced with * and the PURL replacement is skipped entirely.

Manage Corrections

anchorectl correction list
anchorectl correction get <correction-uuid>
anchorectl correction delete <correction-uuid>

Corrections are referenced by the UUID returned at creation. The same operations are available on the /corrections API — see the API browser for the full request and response schemas.

Verify a Correction

Corrections take effect at the next vulnerability scan. To confirm a correction is matching the way you intended, inspect the analyzed content for a representative image:

anchorectl image content -t java <image-digest> -o json

For the Tomcat Catalina example above, the corrected package content should show the rewritten CPE, PURL, and package name:

{
  "cpes": [
    "cpe:2.3:a:apache:tomcat_catalina:9.0.88:*:*:*:*:*:*:*"
  ],
  "package": "tomcat-catalina",
  "purl": "pkg:maven/org.apache.tomcat/[email protected]",
  "type": "JAVA-JAR",
  "version": "9.0.88"
}

2 - Hints

A hints file lets a build process tell Anchore Enterprise about packages that its analyzers cannot detect on their own. If you know a container image installs a piece of software through a non-standard mechanism — a manual tar extract, a vendored binary, a build-time install that leaves no package-manager trace — you can declare those packages in a hints file and Anchore Enterprise will include them in the SBOM exactly as if they had been discovered normally.

Hints add packages to the SBOM. They cannot modify or remove findings produced by the regular analyzers — for that, see Corrections. If a hints record names a package the analyzers also find, the hint is ignored and a warning is logged.

Hints apply only during container image analysis; they do not affect externally supplied SBOMs.

The hints feature is disabled by default. Enabling it means whoever builds your container images can inject additional packages into the SBOM — entries the analyzers didn’t produce — which directly affects vulnerability and policy outcomes. Only enable this feature when the build process is fully under your control. See Configuring Content Hints for how to enable it.

How the Hints File Works

When the hints feature is enabled, the Anchore Enterprise analyzer looks for a file at /anchore_hints.json inside every container image it analyzes. Records in that file are added to the image’s SBOM and become part of every subsequent scan.

The file is a JSON object with a single packages array. Each record describes one package:

{
  "packages": [
    { "name": "musl",   "version": "1.1.20-r8", "type": "apkg" },
    { "name": "wicked", "version": "0.6.1",     "type": "gem"  }
  ]
}

The schema differs slightly between OS packages and language packages, covered below.

OS Package Records

OS packages represent components installed through an OS distro’s package manager. Supported types are rpm (Red Hat / Rocky / Alma / Amazon), dpkg (Debian / Ubuntu), and apkg (Alpine).

Package names are unique per SBOM in this category. If a hint names an OS package the analyzers already discovered, the hint is ignored (per the rule above); OS hints add only packages the analyzers don’t detect on their own.

Minimum record:

{
  "name": "musl",
  "version": "1.1.20-r8",
  "type": "apkg"
}

Full record:

{
  "name": "musl",
  "version": "1.1.20",
  "release": "r8",
  "origin": "Timo Teräs <[email protected]>",
  "license": "MIT",
  "size": "61440",
  "source": "musl",
  "files": ["/lib/ld-musl-x86_64.so.1", "/lib/libc.musl-x86_64.so.1", "/lib"],
  "type": "apkg"
}

Language Package Records

Language packages cover the ecosystem-specific package managers. Supported types include java, python, gem, npm, nuget, go, and binary. The full set available on a given deployment is whatever anchorectl image content lists.

Multiple packages with the same name can legitimately co-exist (a project can depend on two versions of the same library installed in different locations), so a location field is the primary disambiguator.

Minimum record:

{
  "name": "wicked",
  "version": "0.6.1",
  "type": "gem"
}

Full record:

{
  "name": "wicked",
  "version": "0.6.1",
  "location": "/app/gems/specifications/wicked-0.9.0.gemspec",
  "origin": "schneems",
  "license": "MIT",
  "source": "http://github.com/schneems/wicked",
  "files": ["README.md"],
  "type": "gem"
}

Verify a Hint Was Applied

After re-analyzing an image whose /anchore_hints.json declares a package, the package should appear in the SBOM:

anchorectl image content <image-digest> -t os
anchorectl image content <image-digest> -t gem

The musl and wicked records from the examples above will appear in the os and gem content listings respectively, as if the analyzers had discovered them directly.