Check whether a reported CVE affects your container

Use chainctl images advisories list to compare the advisories for the APK packages in an image with the CVEs reported by your scanner.

Note: This command looks up advisories by APK package. Chainguard records a vulnerability in a Go module, Java archive, or other language component against the APK package that ships it, so the results cover those components too. They don’t cover dependencies that your own build adds to the image. For details, see When the finding is a Go module or Java dependency.

FIPS variants

FIPS variants use the same package-level advisory process as other Chainguard images. chainctl images advisories list does not determine coverage from the image name or the -fips suffix. It reads the APK package names and versions in the image SBOM, then looks up advisories for those APK packages. This means:

• If a FIPS image contains the same APK package and version as a non-FIPS image, the same package advisory can apply.
• If a FIPS image contains a FIPS-specific package name or version, that package needs a corresponding advisory record.
• A FIPS image may have a different advisory result from its non-FIPS counterpart because its package set or versions differ.
• An empty result does not by itself mean that the FIPS image is not affected or that the CVE is not covered.

For a FIPS finding, use the exact image digest and platform, then compare the scanner’s package name and version with the APK package data in the image SBOM. Search the Security Advisories page for the exact package and CVE. If the APK package is present but no matching advisory exists, treat the result as an advisory-coverage question and include the image digest, package name and version, CVE, scanner and database versions, and scan output when contacting Support.

Prerequisites

You need:

• chainctl installed and authenticated.
• An image reference with an SBOM attestation attached.
• The image digest or the exact tag scanned by your scanner. A digest is preferred because tags can move.
• The platform that matches the scanner result. The default platform is linux/amd64.

List advisories for the image

Run the command against the same image reference and platform that your scanner analyzed:

chainctl images advisories list \
  cgr.dev/chainguard/<image>@sha256:<digest> \
  --platform=linux/amd64 \
  -o wide

The output includes the APK package, package version, advisory ID, CVE aliases, status, and advisory type. Compare the package name and version—not only the CVE alias—with the scanner’s finding. The TYPE column shows apk on every row, including advisories for a Go module or other component inside the package.

If the image has no SBOM attestation, or the requested platform does not have one, the command cannot use that image to perform the lookup. If no matching advisory is shown, do not treat that alone as proof that the scanner finding is a false positive; first verify the image digest, platform, package ecosystem, package version, and scanner database.

Triage a long scanner report with --status

Use --status to narrow the output to the advisory states you need to review. You can provide multiple values as a comma-separated list, or by repeating the flag:

# Findings that still need attention or confirmation
chainctl images advisories list "$IMAGE" \
  --status=detected,true-positive,pending-upstream

# Findings with a recorded fix or backported patch
chainctl images advisories list "$IMAGE" \
  --status=fixed,patched

# The same filter using repeated flags
chainctl images advisories list "$IMAGE" \
  --status=detected \
  --status=pending-upstream

To inspect one CVE from the table output, filter the displayed aliases after retrieving the results:

chainctl images advisories list "$IMAGE" -o wide | grep 'CVE-2026-42151'

The command filters advisories by their current status. It does not accept a CVE as the primary lookup key, and it does not replace the scanner’s analysis of components that no Chainguard package ships.

Status values

The command reports the status derived from the advisory’s most recent event:

What a missing result means

A missing result can have several explanations:

• No Chainguard package ships the reported component, as with a dependency that your build added.
• The image reference, digest, or platform differs from the image that was scanned.
• The image does not have an SBOM attestation available to the command.
• The advisory database does not contain a matching advisory for that package and version.
• The scanner and advisory database use different package or version metadata.

A missing result is therefore a prompt to reconcile the two data sources, not a standalone false-positive determination.

When the finding is a Go module or Java dependency

Scanners report Go modules, Java archives, and other language components separately from APK packages. How you validate one of these findings depends on where the component came from: a Chainguard package that ships it, or your own build. If your build didn’t add the file where the scanner found the component, a Chainguard package ships it.

To confirm, look up the APK package that owns the file:

1. In the scanner output, find the file path for the component, such as /usr/bin/crane for a Go binary or /usr/share/java/maven/boot/plexus-classworlds-2.11.0.jar for a Java archive.

2. Run the following command against the image and platform that your scanner analyzed, replacing <file-path> with that path. The command exports the image, reads its APK database, and prints the name and version of the package that owns the file:

   crane export --platform linux/amd64 \
       cgr.dev/<organization>/<image>@sha256:<digest> - \
     | tar -xO usr/lib/apk/db/installed \
     | awk -v path="<file-path>" '
         BEGIN { sub(/^\//, "", path) }
         /^P:/ { package = substr($0, 3) }
         /^V:/ { version = substr($0, 3) }
         /^F:/ { directory = substr($0, 3) }
         /^R:/ && directory "/" substr($0, 3) == path { print package, version }
       '

   For /usr/bin/crane in the crane image, the command prints crane 0.22.1-r0. If it prints nothing, no APK package owns the file. The crane command uses the same registry credentials as docker. If it can’t authenticate, run chainctl auth configure-docker first.

If an APK package owns the file, follow Components that a Chainguard package ships. Otherwise, follow Dependencies that your build adds.

Components that a Chainguard package ships

Chainguard records a vulnerability in a bundled component against the APK package that ships it. For example, Chainguard records CVE-2026-39836, a vulnerability in the Go standard library that is compiled into /usr/bin/crane, as an advisory for the crane package. Validate the finding the same way as an APK finding:

1. List the advisories for the image that your scanner analyzed, and filter for the CVE:

   chainctl images advisories list "$IMAGE" -o wide | grep 'CVE-2026-39836'

2. In the row for the package that owns the file, read the status. A fixed version is a version of that package, such as 0.21.5-r1, not a version of the component. Scanners report the component’s own version, such as go1.25.9 for the Go standard library, so don’t compare the fixed version with that value.

3. Compare the owning package’s installed version with the fixed version, as described in Compare the installed package with Chainguard’s fixed version. If the installed version is the fixed version or later, Chainguard has fixed the CVE in that package. If your scanner still reports it, work through the rest of Resolve a scanner finding for a CVE Chainguard has fixed.

If no advisory for the owning package lists the CVE, Chainguard hasn’t recorded the CVE for that package, and the finding stands. To ask about it, contact support.

Dependencies that your build adds

Chainguard’s advisories don’t cover software that you add to an image, such as a Go binary that you compile in a later build stage or a JAR that your application copies in. The absence of a Chainguard advisory for one of these dependencies doesn’t make the finding a false positive. Use the scanner’s language-package evidence and the dependency’s upstream vulnerability data instead.

Go modules

For a Go-module finding:

1. Confirm the module path and version in your build’s SBOM and, where available, in go.mod or go.sum.
2. Check the module’s upstream advisory and the scanner’s reachability or affected-symbol evidence.
3. Rebuild with a non-vulnerable module version when one is available, then rescan the resulting image.

Java dependencies

For a Java finding:

1. Confirm the Maven or Gradle coordinates and version in the SBOM.
2. Check whether the finding is in a standalone dependency, a shaded JAR, or an application layer.
3. Consult the dependency’s upstream advisory and the scanner’s evidence for the affected class or code path.
4. Upgrade, replace, or otherwise mitigate the dependency, then rebuild and rescan.

Further troubleshooting

If an advisory reports a CVE as fixed or not affected but your scanner still reports it, see Resolve a scanner finding for a CVE Chainguard has fixed.

If a result is still unclear, you can contact support. When contacting support, include:

• The image digest and platform.
• The scanner name and database version.
• The CVE and advisory identifiers.
• The detected ecosystem, package/module coordinates, and version.
• The relevant chainctl images advisories list output, preferably in -o wide or JSON form.