+++
title = "Vulnerability Database"
description = "Using the Grype Vulnerability Database"
weight = 50
tags = ["grype", "vulnerabilities", "grype-db"]
+++

{{< alert title="TL;DR" color="primary" >}}

- Grype uses a **locally cached database** of known vulnerabilities
- Database **auto-updates** on each Grype launch when newer version is available
- Manage manually with `grype db check` and `grype db update`
- Database published by Anchore at no cost from multiple upstream feeds

{{< /alert >}}

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.

{{% alert title="Learn more" color="primary" %}}
Find out more about the vulnerability data sources at [Vulnerability Data Sources]({{< relref "/docs/reference/grype/data-sources" >}}).
{{% /alert %}}

## Updating the local database

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.

{{% alert title="Database age validation" color="warning" %}}
Grype will automatically fail scans if the vulnerability database is **more than 5 days old**.

You can disable this behavior or adjust the age threshold in your configuration:

- Set `db.validate-age: false` to disable age validation
- Adjust `db.max-allowed-built-age` to change the threshold (e.g., `168h` for 7 days)

{{% /alert %}}

To update the database manually, use the following command:

```
grype db update
```

If instead, you would like to simply check if a new DB is available without actually updating, use:

```
grype db check
```

This will return 0 if the database is up to date, and 1 if an update is available.

Or, you can delete the local database entirely:

```
grype db delete
```

## Searching the database

The Grype vulnerability database contains detailed information about vulnerabilities and affected packages across all supported ecosystems.
While you can examine the raw SQLite database directly (use `grype db status` to find the local storage path),
the `grype db search` commands provide a much easier way to explore what's in the database.

{{% alert title="Search tips" color="primary" %}}

For both affected package and vulnerability searches, keep these tips in mind:

- **Result limit**: By default, searches return up to 5,000 results. Use `--limit 0` for unlimited results.
- **JSON output**: Add `--output json` for programmatic processing of results.

{{% /alert %}}

### Search for affected packages

Use `grype db search` to find packages affected by vulnerabilities. This is useful when you want to understand
what packages are impacted by a specific CVE, or when you want to see all vulnerabilities affecting a particular package.

For example, to find all packages affected by [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell) across all ecosystems:

```bash
grype db search --vuln CVE-2021-44228
```

To find all vulnerable versions of the [`log4j`](https://en.wikipedia.org/wiki/Log4j) package:

```bash
grype db search --pkg log4j
```

To search by PURL or CPE formats:

```bash
grype db search --pkg 'pkg:rpm/redhat/openssl'
grype db search --pkg 'cpe:2.3:a:jetty:jetty_http_server:*:*:*:*:*:*:*:*'
```

Any version value provided will be ignored entirely.

You can also use these options in combination to filter results further (finding the common intersection);
in this example, finding packages named "openssl" in Alpine Linux 3.18 that have fixes available:

```bash
grype db search --pkg openssl --distro alpine-3.18 --fixed-state fixed
```

### Search for vulnerabilities

Use `grype db search vuln` to look up vulnerability details directly, including descriptions, severity ratings, and data sources.

This is subtly different from searching for affected packages, as it focuses on the vulnerabilities themselves, so you can find information
about vulnerabilities that may not affect any packages (there are a few reasons why this could happen.)

To view full metadata for a specific CVE:

```bash
grype db search vuln CVE-2021-44228
```

To filter by data provider:

```bash
grype db search vuln CVE-2021-44228 --provider nvd
```

## Next steps

{{< alert title="Explore more" color="success" url="/docs/guides/sbom/getting-started/" >}}
Generate SBOMs with [Syft]({{< relref "/docs/guides/sbom/getting-started/" >}}) to enable faster vulnerability scanning workflows.
{{< /alert >}}

Now that you understand how Grype's vulnerability database works, here are additional resources:

- **Scan targets**: Learn about all [supported scan targets]({{< relref "/docs/guides/vulnerability/scan-targets/" >}}) Grype can analyze
- **EOL detection**: Understand [end-of-life distro warnings]({{< relref "/docs/guides/vulnerability/eol-detection/" >}}) and incomplete vulnerability data
- **Filter results**: Use [result filtering]({{< relref "/docs/guides/vulnerability/filter-results/" >}}) to focus on actionable findings
- **Data sources**: Explore [vulnerability data sources]({{< relref "/docs/reference/grype/data-sources" >}}) for details on each feed
- **License scanning**: Check dependency licenses with [Grant]({{< relref "/docs/guides/license/getting-started/" >}})