Run composer audit in CI and let its exit code decide the build. The Composer docs define exit code 0 as no issues and 1 as packages matching dependency policies or a failure from missing required packages. Audit the lock file, not whatever happens to be in vendor.
What the command checks
By default, composer audit lists security advisories using the Packagist.org API. It can read advisories from other repositories too, if they are configured in the repositories section of composer.json. It also reports abandoned packages. Since Composer 2.7 the default for abandoned packages is to fail; in 2.6 it defaulted to report.
Options that matter in a pipeline
| Option | Effect |
|---|---|
| locked | Audit the lock file regardless of what is in vendor |
| no-dev | Skip require-dev packages |
| abandoned | Set to ignore, report or fail, overriding config |
| format | table, plain, json or summary |
| ignore-severity | Skip advisories of a given severity, repeatable |
composer audit --locked --format=json
composer audit --locked --no-dev --abandoned=report
The first form gives machine readable output for a dashboard. The second checks only what ships to production and reports abandoned packages without failing the build.
A rollout that does not break everyone
- Run audit in report mode for one sprint. Record the baseline.
- Fix or replace what is fixable. Note why anything remains.
- Turn the gate on for new advisories, so the build fails on regressions.
- Document each ignore with a reason and a review date.
- Review the ignore list on a schedule.
Composer lets you ignore advisories by ID or ignore whole severities in config. Avoid ignoring a severity globally. An ignored high severity advisory today will not be re-raised when it becomes actively exploited next month.
Know the limits
Audit matches package versions against advisories. It does not tell you whether your code calls the vulnerable function, and it only knows about advisories that have been published. A clean result means no known matching advisory, not that the code is safe.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many advisories remain once you ask whether the code path is reachable.
Where Safeguard fits
Safeguard's policies and gates can check dependency changes in a pull request before merge. A free scan shows what it finds today.
Quick check
Why audit the lock file rather than vendor?
The lock file is what you will deploy. A developer's vendor directory may have drifted from it.
Does a passing audit mean my dependencies are safe?
No. It means no published advisory matches the locked versions. Newer or unreported problems will not appear.
Sources
Last reviewed: 19 October 2026.
