Learn how to scan container images, filesystems, and SBOMs for known software vulnerabilities.
Vulnerability scanning is the automated process of proactively identifying security weaknesses and known exploits within software and systems. This is crucial because it helps developers and organizations find and fix potential security holes before malicious actors can discover and exploit them, thus protecting data and maintaining system integrity.
Grype is an open-source vulnerability scanner specifically designed to analyze container images and filesystems. It works by comparing the software components it finds against a database of known vulnerabilities, providing a report of potential risks so they can be addressed.
1 - Getting Started
Vulnerability Scanning Getting Started
Introduction
Grype is an easy-to-integrate open source vulnerability scanning tool for container images and filesystems.
Install the latest Grype release
Grype is provided as a single compiled executable. Issue the command for your platform to download the latest release of Grype. The full list of official and community maintained packages can be found on the installation page.
curl -sSfL <https://get.anchore.io/grype> | sudo sh -s -- -b /usr/local/bin
brew install grype
nuget install Anchore.Grype
Once installed, ensure the grype binary is in the PATH for your system.
Scan a container for vulnerabilities
grype <image>
Scan a public container image for vulnerabilities
Run grype with default options against a small container, which will be pulled from DockerHub. Grype will also download the latest vulnerability database. The output will be a simple human-readable table.
Grype can scan containers directly, but it can also scan an existing SBOM document.
Note
This presumes you already created alpine_latest-spdx.json using Syft, or some other tool. If not, go to SBOM Generation Getting Started and create it now.
grype alpine_latest-spdx.json
Grype should give similar output to the previous table.
Create a vulnerability report in JSON format
The JSON-formatted output from Grype may be processed or visualized by other tools.
Create the vulnerability report using the --output, and via jq to make it prettier.
Grype uses a locally cached database of known vulnerabilities when searching a container, directory, or SBOM for security vulnerabilities. Anchore collates vulnerability data from common feeds, and publishes that data online, at no cost to users.
When Grype is launched, it checks for an existing vulnerability database, and looks for an updated one online. If available, Grype will automatically download the new database.
Users can manage the locally cached database with the grype db command:
Check and update the database
Manually checking for updates shouldn’t be necessary, due to Grype automatically doing this on launch. However, it is possible to force Grype to look for an updated vulnerability database.
grype db check
A message will indicate if no updates are available since the last download.
Installed DB version v6.0.2 was built on 2025-05-08T04:08:40Z
No update available
If the database is outdated, a message such as this will be displayed.
Installed DB version v6.0.2 was built on 2025-05-07T04:08:13Z
Updated DB version v6.0.2 was built on 2025-05-08T04:08:40Z
You can run 'grype db update' to update to the latest db
[0000] ERROR db upgrade available
grype db update
A short animation will show progress of downloading, uncompressing and hydrating (creating indexes on) the database. Then a message reporting the successful update will be displayed.
grype db update
✔ Vulnerability DB [updated]
Vulnerability database updated to latest version!
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.
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.
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.
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.
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.
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 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 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.
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:
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 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
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.
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.