Supported Scan Targets

Grype can scan a variety of scan targets including container images, directories, files, archives, SBOMs, and individual packages. In most cases, you can simply point Grype at what you want to analyze and it will automatically detect and scan it correctly.

Scan a container image from your local daemon or a remote registry:

grype alpine:latest

Scan a directory or file:

grype /path/to/project

Scan an SBOM:

grype sbom.json

To explicitly specify the scan target type, use the --from flag:

Instead of using the --from flag explicitly, you can instead:

• provide no hint and let Grype automatically detect the scan target type implicitly based on the input provided

• provide the scan target type as a URI scheme in the target argument (e.g., docker:alpine:latest, oci-archive:/path/to/image.tar, dir:/path/to/dir)

Scan target-specific behaviors

With each kind of scan target, there are specific behaviors and defaults to be aware of.

For scan target capabilities that are inherited from Syft, please see the SBOM scan targets documentation:

• Container image scan targets
• Directories
• Files and archives
• OCI layout/archive scan targets

For scan targets that are uniquely supported by Grype, see the sections below.

SBOM Scan Targets

You can scan pre-generated SBOMs instead of scanning the scan target directly. This approach offers several benefits:

• Faster scans since package cataloging is already complete
• Ability to cache and reuse SBOMs
• Standardized vulnerability scanning across different tools

Scan an SBOM file

Grype scans SBOM files in multiple formats. You can provide an explicit sbom: prefix or just provide the file path:

Explicit SBOM prefix:

grype sbom:sbom.json

Implicit detection:

grype sbom.json

Grype automatically detects the SBOM format. Supported formats include:

• Syft JSON
• SPDX JSON, XML, and tag-value
• CycloneDX JSON and XML

Use the explicit sbom: prefix when the file path might be ambiguous or when you want to be clear about the input type.

Scan an SBOM from stdin

You can pipe SBOM output directly from Syft or other SBOM generation tools:

Syft → Grype pipeline:

syft alpine:latest -o json | grype

Read SBOM from file via stdin:

Grype detects stdin input automatically when no command-line argument is provided and stdin is piped:

cat sbom.json | grype

Package scan targets

You can scan specific packages without scanning an entire image or directory. This is useful for:

• Testing whether a specific package has vulnerabilities
• Lightweight vulnerability checks
• Compliance scanning for specific dependencies

Grype supports two formats for individual package scanning: Package URLs (PURLs) and Common Platform Enumerations (CPEs). When Grype receives input, it checks for PURL format first, then CPE format, before trying other scan target types.

Scan Package URLs (PURLs)

Package URLs (PURLs) provide a standardized way to identify software packages.

A PURL has this format:

pkg:<type>/<namespace>/<name>@<version>?<qualifiers>#<subpath>

Grype can take purls from the CLI or from a file. For instance, to scan the python library urllib3 (version 1.26.7):

grype pkg:pypi/urllib3@1.26.7

You’ll see vulnerabilities for that specific package:

NAME     INSTALLED  FIXED IN  TYPE    VULNERABILITY        SEVERITY  EPSS           RISK
urllib3  1.26.7     1.26.17   python  GHSA-v845-jxx5-vc9f  High      0.9% (74th)    0.6
urllib3  1.26.7     1.26.19   python  GHSA-34jh-p97f-mpxf  Medium    0.1% (35th)    < 0.1
urllib3  1.26.7     1.26.18   python  GHSA-g4mx-q9vg-27p4  Medium    < 0.1% (15th)  < 0.1
urllib3  1.26.7     2.5.0     python  GHSA-pq67-6m6q-mj2v  Medium    < 0.1% (4th)   < 0.1

For operating system packages (apk, deb, rpm), use the distro qualifier to specify the distribution:

grype "pkg:apk/alpine/openssl@3.1.5-r0?distro=alpine-3.19"
grype "pkg:deb/debian/openssl@1.1.1w-0+deb11u1?distro=debian-11"
grype "pkg:rpm/redhat/openssl@1.0.2k-19.el7?distro=rhel-7"

You can specify distribution information with the --distro flag instead:

grype "pkg:rpm/redhat/openssl@1.0.2k-19.el7?arch=x86_64" --distro rhel:7

Without either the distro qualifier or the --distro flag hint, Grype may not find distribution-specific vulnerabilities.

Other qualifiers include:

• upstream: The upstream package name or version. Vulnerability information tends to be tracked with the source or origin package instead of the installed package itself (e.g. libcrypto might be installed but the pacakge it was built from is openssl which is where vulnerabilities are attributed to)
• epoch: The epoch value for RPM packages. This is necessary when the package in question has changed the methodology for versioning (e.g., switching from date-based versions to semantic versions) and the epoch is used to indicate that change.

You can scan multiple packages from a file. The file contains one PURL per line:

# contents of packages.txt follow, which must be a text file with one PURL per line

pkg:npm/lodash@4.17.20
pkg:pypi/requests@2.25.1
pkg:maven/org.apache.commons/commons-lang3@3.12.0

grype ./packages.txt

Grype scans all the packages in the file:

NAME           INSTALLED  FIXED IN  TYPE          VULNERABILITY        SEVERITY
lodash         4.17.20    4.17.21   npm           GHSA-35jh-r3h4-6jhm  High
requests       2.25.1     2.31.0    python        GHSA-j8r2-6x86-q33q  Medium
commons-lang3  3.12.0     3.18.0    java-archive  GHSA-j288-q9x7-2f5v  Medium
...

Scan Common Platform Enumerations (CPEs)

Common Platform Enumeration (CPE) is an older identification format for software and hardware. You can scan using CPE format:

grype "cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*"

Grype supports multiple CPE formats:

# CPE 2.2 format (WFN URI binding)
grype "cpe:/a:apache:log4j:2.14.1"

# CPE 2.3 format (string binding)
grype "cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*"

Use CPE when:

• You’re working with legacy systems that use CPE identifiers
• You need to test for vulnerabilities in a specific CVE that references a CPE
• PURL format is not available for your package type

For most modern scanning workflows, PURL format is preferred because it provides better precision and ecosystem-specific information.

Next steps

Additional resources:

• Understand results: Learn how to interpret scan output
• Filter vulnerabilities: Use result filtering to focus on specific findings
• Private registries: Set up authentication for private images