Supported package ecosystems

Grype automatically selects the right vulnerability data source based on the package type and distribution information in your SBOM. This guide explains how Grype chooses which vulnerability feed to use and what level of accuracy to expect.

How Grype chooses vulnerability data

Grype selects vulnerability feeds based on package type:

• OS packages (apk, deb, rpm, portage, alpm) use vulnerability data sourced from distribution-specific security feeds.
• Language packages (npm, PyPI, Maven, Go modules, etc.) use GitHub Security Advisories.
• Other packages (binaries, Homebrew, Jenkins plugins, etc.) fall back to CPE matching against the NVD.

OS packages

When Grype scans an OS package, it uses vulnerability data sourced from distribution security feeds. Distribution maintainers curate these feeds and provide authoritative information about vulnerabilities affecting specific distribution versions.

For example, when you scan Debian 10, Grype looks for vulnerabilities affecting Debian 10 packages:

$ grype debian:10
NAME          INSTALLED           FIXED IN     TYPE  VULNERABILITY   SEVERITY
libgcrypt20   1.8.4-5+deb10u1     (won't fix)  deb   CVE-2021-33560  High
bash          5.0-4                            deb   CVE-2019-18276  Negligible
libidn2-0     2.0.5-1+deb10u1     (won't fix)  deb   CVE-2019-12290  High

OS distributions

Grype supports major Linux distributions with dedicated vulnerability feeds, including Alpine, Debian, Ubuntu, RHEL, SUSE, and many others. Some distributions have mature security tracking programs that report both fixed and unfixed vulnerabilities, providing comprehensive coverage.

Derivative distributions automatically use their parent distribution’s vulnerability feed. Grype maps derivative distributions to their upstream source using the ID_LIKE field from /etc/os-release. For example, Rocky Linux and AlmaLinux use the RHEL vulnerability feed, while Raspbian uses Debian’s feed.

When scanning Rocky Linux, Grype uses Red Hat security data:

$ grype rockylinux:9 -o json | jq '.matches[0].matchDetails[0].searchedBy.distro'
{
  "type": "rockylinux",
  "version": "9.3"
}

The distro type shows rockylinux, but Grype searches the RHEL vulnerability feed automatically. You don’t need to configure this mapping –it happens transparently based on the distribution’s ID_LIKE field.

Language packages

Language packages use vulnerability data from GitHub Security Advisories (GHSA). GitHub maintains security advisories for major package ecosystems, sourced from package maintainers, security researchers, and automated scanning.

When you scan a JavaScript package, Grype searches GHSA for npm advisories:

$ grype node:18-alpine
NAME         INSTALLED  FIXED IN  TYPE  VULNERABILITY         SEVERITY
cross-spawn  7.0.3      7.0.5     npm   GHSA-3xgq-45jj-v275   High

Supported language ecosystems

Grype supports these language ecosystems through GHSA:

• Python (PyPI) - Python packages
• JavaScript (npm) - Node.js packages
• Java (Maven) - Java archives
• Go (modules) - Go modules
• PHP (Composer) - PHP packages
• .NET (NuGet) - .NET packages
• Dart (Pub) - Dart and Flutter packages
• Ruby (RubyGems) - Ruby gems
• Rust (Crates) - Rust crates
• Swift - Swift packages
• GitHub Actions - GitHub Actions workflow dependencies

For language packages, Grype searches GHSA by package name and version, applying ecosystem-specific version comparison rules to determine if your package version falls within the vulnerable range.

In addition to language packages, Bitnami packages are searched against Bitnami’s vulnerability feed in a similar manner.

Other packages

Packages without dedicated feeds use CPE fallback matching

Packages using CPE matching

These package types rely on Common Platform Enumeration (CPE) matching against the National Vulnerability Database (NVD):

• Binary executables
• Homebrew packages
• Jenkins plugins
• Conda packages
• WordPress plugins

CPE matching constructs a CPE string from the package name and version, then searches the NVD for matching vulnerability entries.

Understanding CPE match accuracy

CPE matching has important limitations:

• May produce false positives - CPEs often do not distinguish between package ecosystems. For example, the PyPI package docker (a Python library for talking to the Docker daemon) can match vulnerabilities for Docker the container runtime because they share similar CPE identifiers.
• May miss vulnerabilities - Not all vulnerabilities have CPE entries in the NVD.
• Requires CPE metadata - Packages must have CPE information for matching to work.

You should verify CPE matches against the actual vulnerability details to confirm they apply to your specific package. Here’s a CPE match example:

{
  "matchDetails": [
    {
      "type": "cpe-match",
      "searchedBy": {
        "cpes": ["cpe:2.3:a:zlib:zlib:1.2.11:*:*:*:*:*:*:*"]
      },
      "found": {
        "versionConstraint": "<= 1.2.12 (unknown)"
      }
    }
  ]
}

Notice the version constraint shows (unknown) format rather than ecosystem-specific semantics, and the match type is cpe-match instead of exact-direct-match.

For more details on interpreting match types, confidence levels, and result reliability, see Understanding Grype results.

Next steps

Additional resources:

• Filter results: Use result filtering to focus on specific vulnerabilities
• Data sources: Explore vulnerability data sources for details on each data source and supported operating systems