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.