Many Python advisories come from the Python Packaging Advisory Database, a community owned repository of advisories for packages on PyPI. Its data is exposed through pip-audit, the OSV API and the PyPI JSON API, so you can follow it without cloning the repository.
What the database is
The PyPA project describes its repository as a community owned set of advisories for packages published on PyPI. Each advisory lives in a YAML file in the vulns directory and follows the OSV schema. New entries arrive as pull requests, and automation allocates the final ID once a change is merged, which is why new files are named with a PYSEC-0000- placeholder.
Where the records come from
According to the repository README, much of the existing set is collected from the NVD CVE feed. A tool performs heuristics to match CVEs with exact Python packages and versions, and a small amount of human triage produces the YAML entries. The README itself calls that matching a difficult problem.
That has a practical meaning for you. A record built by matching can be less precise than one written by a maintainer, so a surprising result deserves a look at the advisory text before you act on it.
Three ways to consume it
| Method | What you do | Good for |
|---|---|---|
| pip-audit | Run it against a requirements file or an environment | CI checks and local runs |
| OSV API | POST a package name, ecosystem and version to the query endpoint | Custom tooling |
| PyPI JSON API | Read the known vulnerabilities section for a project | Checking one package |
The README shows the OSV query shape: a JSON body with a version and a package object holding the name and the ecosystem value PyPI. It also shows pip-audit installed with pip and run with -r requirements.txt, plus a GitHub Action published under the pypa organization.
An optional precision field
The README describes an ecosystem_specific block that can list the exact modules and attributes affected, for example a single class inside a larger package. When a record includes it, a tool that understands it can reduce false positives, because an import of an unaffected part of the package would not match. Not every record has it, so do not assume it exists.
A short routine
- Pin and lock your Python dependencies so there is a clear version to check.
- Run pip-audit in CI on every pull request and on a nightly schedule, since new advisories appear without any change in your code.
- When a finding appears, open the advisory and read the affected range and fixed version.
- Check whether your code imports the affected module. If the record names one, that is a quick test.
- Upgrade, or record why you are not affected.
Some Python projects, such as Django, also publish their own security releases and policies. Following those gives you early context that a database entry may add later.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a dependency list becomes the thing an advisory is matched against.
Where Safeguard fits
Safeguard's SBOM and dependency scanning checks the dependencies you ship against advisory data, and reachability analysis helps show whether the vulnerable code is called. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Does pip-audit use the PyPA data?
Yes. The PyPA README states the data is exposed by pip-audit.
Is every PYSEC record written by a human?
No. The README says much of the set is collected from the NVD feed with automated matching and a small amount of human triage.
Sources
- PyPA advisory-database README, fetched 19 October 2026.
Last reviewed: 19 October 2026.
