A dependency audit for Rails or Laravel means checking your lockfile against known advisories on every change and on a schedule, recording decisions, and ranking findings by whether your code reaches the vulnerable part. Use bundle-audit for Ruby and composer audit for PHP, then act on the results.
Step one: know what you ship
You cannot audit what you have not listed. Commit Gemfile.lock and composer.lock, so the exact versions are recorded. The bundler-audit README says it checks Gemfile.lock for vulnerable versions. Composer's documentation lists an audit command among its commands and offers audit options on install and update, which include choosing the output format.
An inventory should also include transitive packages, JavaScript dependencies pulled in by your asset pipeline, and anything in the container image.
Step two: wire checks into CI
| Check | Ruby | PHP |
|---|---|---|
| Lockfile audit | bundle-audit check --update | composer audit |
| Run on | Pull requests and nightly | Pull requests and nightly |
| Output | JSON for records | Table, plain, JSON or summary formats |
| Ignores | .bundler-audit.yml or flag | Composer audit ignore settings |
Both tools can write machine readable output, which you can keep as a build artifact. Our guides on bundler-audit in CI and composer audit cover each in detail.
Step three: triage with a short rubric
- Is the vulnerable version actually deployed?
- Is a fixed version available, and is the upgrade small?
- Does your code call the affected function or accept the affected input?
- Is the service internet facing?
- Is there a known exploit in the wild?
A finding that is deployed, fixable and reachable goes first. One that is in a development only gem and unreachable can wait, with a note.
Step four: record decisions
Every ignore needs a reason, an owner and a review date. Without that, an ignore list becomes a graveyard of forgotten risk. The Composer settings document ignores for audit and for abandoned packages, so there is a natural place to write them down.
Step five: schedule it
New advisories appear while your code sits still. A nightly job on the main branch catches them, and a weekly review turns them into tickets. After a security release of your framework, run the audit the same day.
Try it yourself
Open the walkthrough to see how reachability changes the order of a findings list. Click a finding and look at what moves down once it is marked unreachable.
Click through it at your own pace, or open it full screen.
Quick check
Is one audit tool enough for a mixed app?
Each tool reads one ecosystem's lockfile. An app with Ruby, PHP and JavaScript needs coverage of each, or a scanner that reads all of them.
How often should the audit run?
On every pull request that touches a lockfile, nightly on the main branch, and right after a framework security release.
Safeguard offers SBOM and dependency scanning with reachability analysis and policy gates, so findings arrive ranked and enforced in the pull request. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
