Data sources

Learn about the vulnerability data sources Grype uses for matching

Grype matches vulnerabilities by comparing package information from your software against vulnerability databases. Grype sources these databases from multiple upstream providers, each covering different operating systems and programming language ecosystems. This page documents each data source, what it covers, and how Grype interprets the data.

Quick reference

Language ecosystems

Ecosystem Data Source Vunnel provider
Composer (PHP) GitHub Security Advisories github
Dart GitHub Security Advisories github
Go GitHub Security Advisories github
Java (Maven) GitHub Security Advisories github
npm (JavaScript) GitHub Security Advisories github
NuGet (.NET) GitHub Security Advisories github
Python (PyPI) GitHub Security Advisories github
Ruby (RubyGems) GitHub Security Advisories github
Rust (crates.io) GitHub Security Advisories github
Swift GitHub Security Advisories github
GitHub Actions GitHub Security Advisories github
Various Bitnami Vulnerability Database bitnami

Operating systems

Operating System Supported Versions Data Source Vunnel provider
Ubuntu 12.04, 14.04, 16.04, 18.04,
20.04, 22.04, 24.04, 24.10,
25.04, 25.10		 Ubuntu CVE Tracker ubuntu
Debian 7 (wheezy), 8 (jessie), 9 (stretch),
10 (buster), 11 (bullseye), 12 (bookworm),
13 (trixie), 14 (forky), 15 (duke),
unstable (sid)		 Debian Security Tracker debian
Alpine Linux 3.2+, edge Alpine SecDB alpine
Red Hat Enterprise Linux 5, 6, 7, 8, 9 Red Hat Security Data API rhel
Amazon Linux 2, 2022, 2023 Amazon Linux Security Center amazon
Oracle Linux 5, 6, 7, 8, 9 Oracle Linux Security oracle
SUSE Linux Enterprise Server 11, 12, 15 SUSE Security OVAL sles
Wolfi Current Wolfi Security wolfi
Chainguard Current Chainguard Security chainguard
AlmaLinux 8, 9 AlmaLinux OSV Database alma
Rocky Linux 8, 9 Rocky Linux Apollo API rocky
CBL-Mariner 1.0, 2.0, 3.0 Microsoft CBL-Mariner OVAL mariner

Cross-cutting sources

The National Vulnerability Database (NVD) provides Common Vulnerabilities and Exposures (CVE) data that supplements ecosystem-specific sources. Grype uses the NVD CVE API 2.0 (Vunnel provider: nvd) to access vulnerability information across all ecosystems using Common Platform Enumeration (CPE) matching.

Language ecosystem providers

GitHub Security Advisories

Data source: GitHub Security Advisories

Vunnel provider: github

What it covers:

GitHub Security Advisories provides vulnerability data for multiple language ecosystems:

  • Composer (PHP) → composer
  • Dart → dart
  • Go → go
  • Java (Maven) → java
  • npm (JavaScript) → npm
  • NuGet (.NET) → nuget
  • Python (PyPI) → python
  • Ruby (RubyGems) → gem
  • Rust (crates.io) → rust
  • Swift → swift
  • GitHub Actions → github-action

How it works:

Grype retrieves vulnerability data from GitHub’s GraphQL Application Programming Interface (API). Each advisory includes a GitHub Security Advisories ID (GHSA-xxx) and may include associated CVE identifiers. The data includes both general vulnerabilities and malware classifications.

The provider downloads advisories in batches of 100 per GraphQL request and handles GitHub’s rate limiting by pausing when fewer than 10 API requests remain. For incremental updates, the provider uses an updatedSince timestamp parameter to fetch only advisories modified since the last update.

Assumptions and interpretation:

  • Severity mapping: GitHub provides four severity levels that map directly to Grype’s normalized scale:

    • LOW → Low
    • MODERATE → Medium
    • HIGH → High
    • CRITICAL → Critical

  • Version matching: GitHub provides version ranges in ecosystem-specific formats. For example, npm packages use semantic versioning (semver) syntax, while Python packages use PEP 440 version specifiers. Grype interprets these ranges according to each ecosystem’s version comparison rules.

  • CVSS scores: When available, Grype extracts and validates CVSS vector strings from the advisory data to provide detailed vulnerability scoring information.

  • Authentication: GitHub requires a personal access token for API access. Without proper authentication, data retrieval fails.

Bitnami Vulnerability Database

Data source: Bitnami Vulnerability Database

Vunnel provider: bitnami

What it covers:

The Bitnami Vulnerability Database contains vulnerability information for applications packaged by Bitnami. The data covers various language ecosystems and is stored in Open Source Vulnerability (OSV) format version 1.5.0.

How it works:

Grype clones the Bitnami VulnDB Git repository from the main branch and processes the OSV-formatted vulnerability records.

Assumptions and interpretation:

  • Data format: All vulnerability records follow the OSV schema, which provides a standardized structure for vulnerability information across different ecosystems.

  • Scope: The database focuses on vulnerabilities affecting Bitnami-packaged applications, which may include both upstream vulnerabilities and Bitnami-specific issues.

Operating system providers

Ubuntu Security Tracker

Data source: Ubuntu CVE Tracker

Vunnel provider: ubuntu

Supported versions:

  • 12.04 (precise)
  • 14.04 (trusty)
  • 16.04 (xenial)
  • 18.04 (bionic)
  • 20.04 (focal)
  • 22.04 (jammy)
  • 24.04 (noble)
  • 24.10 (oracular)
  • 25.04 (plucky)
  • 25.10 (questing)

Additional development and end-of-life releases are also supported.

How it works:

Grype clones the Ubuntu CVE Tracker Git repository and parses the tracking files that document vulnerability status for each Ubuntu release. The tracker includes patch states that indicate whether a package is vulnerable, fixed, or not affected.

For end-of-life Ubuntu releases, Grype examines the repository’s revision history to determine the final patch states before support ended.

Assumptions and interpretation:

  • Severity mapping: Ubuntu uses a six-level severity scale that maps to Grype’s normalized levels:

    • Untriaged → Unknown
    • Negligible → Negligible
    • Low → Low
    • Medium → Medium
    • High → High
    • Critical → Critical

  • Patch states: Ubuntu tracks vulnerabilities with several patch states:

    • DNE (Does Not Exist) → Package not affected because it doesn’t exist in this release
    • needs-triage → Vulnerability confirmed but not yet assessed
    • needed → Vulnerable, no fix available yet
    • released → Vulnerable, fix available at specified version
    • pending → Fix prepared but not yet released
    • active → Vulnerability being actively worked on
    • ignored → Vulnerability acknowledged but deliberately not fixed (not considered vulnerable for matching purposes)

  • Version format: Ubuntu uses dpkg version comparison rules for determining whether a package version is affected.

  • End-of-life handling: For releases that have reached end-of-life, Grype merges patch states from the repository’s revision history to capture the final vulnerability status.

  • Fix availability: When a patch state indicates released, Grype extracts the fix version from the tracking data. A fix version of “None” means the package is vulnerable with no fix available.

Debian Security Tracker

Data source: Debian Security Tracker

Vunnel provider: debian

Supported versions:

  • 7 (wheezy)
  • 8 (jessie)
  • 9 (stretch)
  • 10 (buster)
  • 11 (bullseye)
  • 12 (bookworm)
  • 13 (trixie)
  • 14 (forky)
  • 15 (duke)
  • unstable (sid)

How it works:

Grype retrieves vulnerability data from two Debian sources: a JSON feed from the Debian Security Tracker and Debian Security Advisory (DSA) lists. The provider combines information from both sources to build a complete picture of vulnerabilities affecting Debian packages.

Assumptions and interpretation:

  • Severity mapping: Debian uses an urgency-based severity system with some special notations:

    • unimportant → Negligible
    • low, low** → Low
    • medium, medium** → Medium
    • high, high** → High
    • When Debian doesn’t provide severity information, Grype falls back to NVD severity data if available

  • Version format: Debian uses dpkg version comparison rules, the same as Ubuntu.

  • Special version handling: A fix version of “0” indicates the package is not vulnerable in that particular Debian release.

  • Advisory metadata: When a DSA (Debian Security Advisory) exists for a vulnerability, Grype includes the DSA identifier and provides a link to the advisory.

  • Legacy data support: The provider can also process data from Debian’s previous feed service format to maintain historical vulnerability records.

Alpine SecDB

Data source: Alpine SecDB

Vunnel provider: alpine

Supported versions:

Alpine Linux 3.2 and newer, plus the edge (development) branch.

How it works:

Grype downloads YAML files from Alpine’s Security Database (SecDB) for each supported Alpine release. Each release has separate databases for the main and community package repositories. The provider parses the “secfixes” sections that map package versions to the CVE identifiers they fix.

Assumptions and interpretation:

  • Severity: Alpine’s SecDB does not include severity ratings in the source data. All Alpine vulnerabilities show as “Unknown” severity unless supplemented by data from other sources like NVD.

  • Version format: Alpine uses apk package version comparison rules.

  • Database types: Alpine maintains two package databases:

    • main → Core Alpine packages
    • community → Community-maintained packages

    Note: Alpine 3.2 does not have a community database (community repository support was added in 3.3).

  • Fix mapping: The secfixes section lists package versions and the CVE IDs they address. When a package version includes a fix for a CVE, Grype considers that version and all later versions non-vulnerable.

Red Hat Enterprise Linux

Data source: Red Hat Security Data API

Vunnel provider: rhel

Supported versions:

Red Hat Enterprise Linux 5, 6, 7, 8, 9 (RHEL 3 and 4 are skipped by default)

How it works:

Grype retrieves vulnerability data from Red Hat’s Common Vulnerabilities and Exposures (CVE) summary Application Programming Interface (API) and supplements it with detailed information from either Common Security Advisory Framework (CSAF) or Open Vulnerability and Assessment Language (OVAL) sources. You can configure which advisory format to use.

The provider performs a minimal initial download of CVE summaries, then fetches full CVE details only for relevant vulnerabilities. To avoid excessive API calls, the provider performs full synchronization at a configurable interval (default: 2 days) and uses incremental updates between full syncs.

Assumptions and interpretation:

  • RHSA source options: Red Hat Security Advisories (RHSA) are available in two formats:

    • CSAF (Common Security Advisory Framework) → Structured JSON format
    • OVAL (Open Vulnerability and Assessment Language) → XML format for automated assessment

  • Version format: Red Hat uses RPM version comparison rules.

  • Extended Update Support (EUS): The provider handles EUS versions, which receive extended security updates beyond the normal RHEL lifecycle.

  • Parallel processing: By default, Grype processes Red Hat data using 4 parallel workers to improve performance during large synchronizations.

Amazon Linux

Data source: Amazon Linux Security Center

Vunnel provider: amazon

Supported versions:

  • Amazon Linux 2
  • Amazon Linux 2022
  • Amazon Linux 2023

How it works:

Grype retrieves Amazon Linux Security Advisories (ALAS) from RSS feeds maintained for each Amazon Linux version. The provider parses the RSS feed to get advisory summaries, then scrapes the HTML pages for detailed package and vulnerability information.

Due to occasional HTTP 403 errors when accessing advisory pages, the provider tolerates up to 25 such errors by default before failing.

Assumptions and interpretation:

  • Severity mapping: Amazon Linux uses four severity levels:

    • low → Low
    • medium → Medium
    • important → High
    • critical → Critical

  • Version format: Amazon Linux uses RPM version comparison rules.

  • RSS feeds: Each Amazon Linux version has its own RSS feed URL:

    • AL2: https://alas.aws.amazon.com/AL2/alas.rss
    • AL2022: https://alas.aws.amazon.com/AL2022/alas.rss
    • AL2023: https://alas.aws.amazon.com/AL2023/alas.rss

Oracle Linux

Data source: Oracle Linux Security

Vunnel provider: oracle

Supported versions:

Oracle Linux 5, 6, 7, 8, 9

How it works:

Grype downloads a compressed OVAL XML file that contains all Enterprise Linux Security Advisories (ELSA) for Oracle Linux. The provider parses this XML file to extract vulnerability and package information.

Assumptions and interpretation:

  • Severity mapping: Oracle Linux uses a five-level severity scale:

    • n/a → Negligible
    • low → Low
    • moderate → Medium
    • important → High
    • critical → Critical

  • Version format: Oracle Linux uses RPM version comparison rules.

  • Ksplice filtering: The provider filters out packages related to Ksplice (Oracle’s kernel live-patching technology) because these packages are not fully supported for vulnerability matching.

  • OVAL format: The data comes from a single compressed XML file: https://linux.oracle.com/security/oval/com.oracle.elsa-all.xml.bz2

SUSE Linux Enterprise Server

Data source: SUSE Security OVAL

Vunnel provider: sles

Supported versions:

SUSE Linux Enterprise Server 11, 12, 15 (configurable, defaults to these three versions)

How it works:

Grype downloads OVAL XML files from SUSE’s FTP server, with one file per major SLES version. Each file contains vulnerability definitions and affected package information.

Assumptions and interpretation:

  • Severity mapping: SUSE uses multiple terms that map to Grype’s normalized levels:

    • low → Low
    • moderate → Medium
    • medium → Medium
    • high → High
    • important → High
    • critical → Critical

  • Version format: SUSE uses RPM version comparison rules.

  • URL template: OVAL files follow this pattern: https://ftp.suse.com/pub/projects/security/oval/suse.linux.enterprise.server.{version}.xml.bz2

Wolfi

Data source: Wolfi Security

Vunnel provider: wolfi

What it covers:

Wolfi is a Linux distribution (undistro) designed for containers. The security feed covers packages in the Wolfi OS.

How it works:

Grype downloads a JSON file from Wolfi’s package repository that contains security information for all Wolfi packages.

Assumptions and interpretation:

  • Version format: Wolfi uses apk package version comparison rules (similar to Alpine).

Chainguard

Data source: Chainguard Security

Vunnel provider: chainguard

What it covers:

Chainguard Images are minimal container images based on Wolfi. The security feed covers packages used in Chainguard Images.

How it works:

Grype downloads a JSON file from Chainguard’s package repository that contains security information for packages in Chainguard Images.

Assumptions and interpretation:

  • Version format: Chainguard uses apk package version comparison rules (same as Wolfi and Alpine).

AlmaLinux

Data source: AlmaLinux OSV Database

Vunnel provider: alma

Supported versions:

AlmaLinux 8, 9

How it works:

Grype clones the AlmaLinux OSV Database Git repository and processes vulnerability records stored in Open Source Vulnerability (OSV) format.

Assumptions and interpretation:

  • Data format: All vulnerability records follow the OSV schema.

  • Version format: AlmaLinux uses RPM version comparison rules.

Rocky Linux

Data source: Rocky Linux Apollo API

Vunnel provider: rocky

Supported versions:

Rocky Linux 8, 9

What it covers:

Rocky Linux is a community enterprise operating system designed to be downstream compatible with Red Hat Enterprise Linux.

How it works:

Grype fetches vulnerability data for Rocky Linux from the Rocky Linux Apollo API, which provides records in Open Source Vulnerability (OSV) format.

Assumptions and interpretation:

  • Data format: All vulnerability records follow the OSV schema.

  • Ecosystem normalization: The provider normalizes ecosystem identifiers from the OSV format. For example, “Rocky Linux:8” becomes “rocky:8” for consistency with Grype’s internal ecosystem naming.

  • Version format: Rocky Linux uses RPM version comparison rules.

CBL-Mariner

Data source: Microsoft CBL-Mariner OVAL

Vunnel provider: mariner

Supported versions:

CBL-Mariner 1.0, 2.0, 3.0

What it covers:

CBL-Mariner (Common Base Linux) is Microsoft’s internal Linux distribution, also available as an open source project.

How it works:

Grype downloads OVAL XML files for CBL-Mariner and parses them using the xsdata library. The provider processes rpminfo_test, rpminfo_object, and rpminfo_state elements to extract vulnerability and package information.

Assumptions and interpretation:

  • Version format: CBL-Mariner uses RPM version comparison rules.

  • OVAL processing: The provider handles standard OVAL XML structures to identify which package versions are affected by vulnerabilities.

Cross-cutting providers

National Vulnerability Database (NVD)

Data source: NVD CVE API 2.0

Vunnel provider: nvd

What it covers:

The National Vulnerability Database provides comprehensive Common Vulnerabilities and Exposures (CVE) data across all ecosystems. Unlike ecosystem-specific providers, NVD uses Common Platform Enumeration (CPE) matching to identify vulnerable software.

How it works:

Grype retrieves CVE data from the NVD API 2.0, which provides up to 2000 results per request. For initial synchronization, the provider downloads all CVEs. For subsequent updates, it uses the last modified timestamp to fetch only CVEs that changed since the previous update.

The provider caches input data in a SQLite database to improve performance across runs. It supports retry logic (10 retries by default) to handle transient API failures.

Assumptions and interpretation:

  • CPE matching: NVD identifies vulnerable software using CPE (Common Platform Enumeration) identifiers. A CPE describes a software product with vendor, product name, version, and other attributes. Grype matches packages against CPE patterns to determine vulnerability status.

  • Incremental updates: The provider uses lastModStartDate and lastModEndDate parameters to fetch only CVEs modified within a specific time range, reducing API calls and bandwidth.

  • API rate limits: NVD enforces rate limits on API requests. You can provide an API key to enable higher rate limits. Without an API key, you’re limited to the public rate limit.

  • Fix date enrichment: NVD data often lacks information about when fixes became available. Grype supplements NVD data with fix dates from external databases when available, improving the accuracy of vulnerability timelines.

  • CPE configuration overrides: The provider supports custom CPE configurations that can override or supplement the default CPE matching data from NVD.

  • Publication date ranges: When querying by publication date, the API enforces a maximum 120-day range per request. The provider automatically splits larger date ranges into multiple requests.

Relationship to other providers:

NVD serves as a cross-cutting data source that complements ecosystem-specific providers. When an ecosystem-specific provider lacks severity information (such as Alpine), Grype can fall back to NVD severity ratings. NVD is also essential for CVE-only lookups where you need to check for a specific CVE across all ecosystems.

Because NVD uses CPE matching rather than package manager metadata, it can identify vulnerabilities in software that doesn’t come from a package manager. However, ecosystem-specific sources typically provide more accurate and granular information for their respective ecosystems by using native package version information.

Common patterns across providers

Severity normalization

All vulnerability providers map their severity ratings to a common scale that Grype uses for reporting:

  • Unknown → Severity information not available
  • Negligible → Minimal or no practical impact
  • Low → Limited impact, typically requiring complex exploit conditions
  • Medium → Moderate impact, may require specific conditions
  • High → Serious impact, relatively easy to exploit
  • Critical → Severe impact, easily exploitable, or widespread effect

Different providers use different severity scales in their source data. For example, Amazon Linux uses “important” while Oracle Linux uses “important” with the same meaning (both map to High). Grype normalizes these provider-specific terms to ensure consistent severity reporting across all data sources.

When a provider doesn’t include severity information in their data, Grype may fall back to NVD severity ratings if available.

Version matching

Version matching rules depend on the package format:

DEB-based systems (Ubuntu, Debian):

These systems use dpkg version comparison rules, which handle Debian-specific version components like epochs and revisions. For example, 1:2.0-1 has an epoch of 1, making it newer than 2.0-1 despite appearing lower numerically.

RPM-based systems (RHEL, Amazon, Oracle, SLES, Mariner, Alma, Rocky):

These systems use RPM version comparison rules, which compare version strings segment by segment. RPM versions can include release numbers and distribution tags. For example, 1.2.3-4.el8 includes version 1.2.3, release 4, and distribution tag el8.

APK-based systems (Alpine, Wolfi, Chainguard):

These systems use Alpine package version rules, which follow a simpler numeric comparison scheme with support for suffix modifiers like -r1 for package revisions.

Language packages (GitHub):

Language ecosystems use their own version comparison rules:

  • npm uses semantic versioning (semver) with ranges like >=1.2.3 <2.0.0
  • Python uses PEP 440 version specifiers with ranges like >=1.2,<2.0
  • Ruby uses RubyGems version comparison
  • Maven uses Maven version ordering rules

Each ecosystem has its own syntax for expressing version ranges, and Grype interprets these ranges according to the ecosystem’s version comparison semantics.

Fix date enrichment

Many providers supplement vulnerability records with “fix available” dates, which indicate when a vulnerability fix first became available. This information establishes accurate vulnerability timelines.

Grype uses external databases (called “fixdaters”) to determine fix availability dates. These databases track when security advisories were published or when fixed package versions were released. The fix date information includes:

  • Date: When the fix became available
  • Kind: The type of evidence (such as “advisory” for security advisory publication dates or “snapshot” for package repository snapshots)

Fix dates improve matching accuracy by allowing Grype to determine whether a vulnerability existed in a package at a specific point in time.

Data freshness

Different providers use different strategies for keeping vulnerability data current:

Incremental updates:

Some providers support incremental updates that fetch only changed data since the last run:

  • GitHub Security Advisories: Uses an updatedSince timestamp parameter to fetch only advisories modified after a specific date
  • NVD: Uses lastModStartDate and lastModEndDate parameters to fetch only CVEs modified within a date range
  • Red Hat: Downloads minimal CVE summaries, then selectively fetches full CVE details for relevant vulnerabilities; performs full synchronization every 2 days by default

Full refresh:

Other providers re-download and re-process all data each run, though they may use caching to improve performance:

  • Git-based providers (Ubuntu, Bitnami, Alma): Clone the entire Git repository each run
  • Feed-based providers (Debian, Alpine, Oracle, SLES): Download complete feeds, which may be cached locally
  • RSS-based providers (Amazon): Parse RSS feeds and fetch advisory pages

The update strategy affects how quickly new vulnerability data appears in Grype. Providers with incremental updates can fetch recent changes more efficiently, while full refresh providers ensure complete data consistency at the cost of higher bandwidth usage.

Last modified October 10, 2025: fix reference links (1594d93)