By default, composer audit queries the Packagist.org security advisories API. Each advisory carries an ID, package name, affected versions as a Composer constraint, a severity and its sources. You can add other advisory repositories in composer.json. The data lists known issues only.
The endpoint in plain terms
The Packagist API documentation describes a public endpoint at packagist.org/api/security-advisories/ that needs no authentication. You pass either a list of package names or an updatedSince timestamp. Packages known to have no advisories return an empty list, and unknown packages are left out of the response.
What each record contains
| Field | Meaning |
|---|---|
| advisoryId | Identifier for the advisory |
| packageName | The affected Composer package |
| title and link | Short title and a disclosure URL |
| cve | The CVE ID, when one exists |
| affectedVersions | A Composer version constraint |
| sources | Where the advisory was found, with a remote ID |
| severity | Based on CVSS 3 |
The docs give GitHub and FriendsOfPHP/security-advisories as examples of source names. They do not describe how advisories are gathered beyond that, so do not assume more than the page says.
Why the affected versions field is useful
Because affectedVersions is written as a Composer constraint, a tool can test your locked version directly against it. That is why advisory checks on composer.lock are fast and exact on version matching. It also explains a common surprise: if a package was never reported to any source, nothing matches, and the audit stays quiet.
Steps to use the data well
- Audit the lock file in CI, as covered in our guide to audit exit codes.
- For packages that are private, add your own advisory repository, or track them in a separate inventory.
- Treat the severity as a starting point. A CVSS number does not know your architecture.
- Check the link to the original disclosure before you decide how to respond.
- Record each decision, so a later reviewer can see why you ignored or fixed it.
What the API cannot tell you
It cannot say whether your application calls the affected code. It cannot see a malicious release that nobody has reported yet. And it cannot judge a package that is abandoned but has no advisory. Pair advisory matching with lock file review and a look at maintainer activity.
Try it yourself
Click through it at your own pace, or open it full screen. See what monitoring looks like for issues that appear before a database entry does.
Where Safeguard fits
Safeguard's SBOM and dependency scanning reads composer.lock and Gemfile.lock and flags known advisories. A free scan takes a few minutes.
Quick check
Does composer audit need an account or API key?
For the public Packagist API, no authentication is required according to its documentation.
Can I audit packages from a private repository?
Yes, if that repository serves advisories and is listed in the repositories section of composer.json.
Sources
Last reviewed: 19 October 2026.
