Add a CI step that runs bundle-audit check --update. It reads your Gemfile.lock, refreshes the ruby-advisory-db, and fails the job when a gem version has a known advisory. Pair it with a documented ignore list and a regular update schedule, so the check stays useful rather than noisy.
What bundler-audit does
The project README describes bundler-audit as patch level verification for Bundler. It checks Gemfile.lock for vulnerable gem versions, flags insecure gem sources that use http:// or git://, lets you ignore advisories you have worked around, and prints advisory information. Its database check does not need a network connection once the database is local.
Each finding shows the gem name, installed version, advisory id, criticality, a link, a title and a solution that names fixed versions.
The commands
gem install bundler-audit
bundle-audit check --update
The --update flag refreshes the advisory database before checking, which the README suggests for CI runs. If your pipeline already has a fresh copy, use --no-update to skip it. You can point at another lockfile, and you can write JSON for later processing:
bundle-audit check --format json --output bundle-audit.json
For a Rakefile, require bundler/audit/task and add Bundler::Audit::Task.new. That gives you rake bundle:audit and rake bundle:audit:update.
Steps for a clean CI setup
- Install the gem in the CI image or add it to a tools group in the Gemfile.
- Run
bundle-audit check --updateafterbundle install. - Fail the build on any finding, at least on pull requests that change
Gemfile.lock. - Run the same job on a nightly schedule on the main branch, since new advisories appear even when your code is unchanged.
- Keep ignores in a
.bundler-audit.ymlfile, with an ignore list, and comment each one with a reason and review date. - Store the JSON output as a build artifact.
Handling an ignore properly
An ignore should say what you decided, not just silence the tool. A reasonable entry records why the advisory does not apply, who decided, and when to look again. The README supports ignores on the command line and in the config file.
| Decision | Record |
|---|---|
| Fixed by upgrading | No ignore needed |
| Not reachable in your code | Ignore with reason and review date |
| No fix available | Ignore with mitigation and owner |
What it cannot tell you
A match means a vulnerable version is installed. It does not say whether your code calls the vulnerable part. That is the gap reachability analysis addresses. It also checks only gems listed in the lockfile, not system libraries in the container image or JavaScript packages.
Try it yourself
Open the inventory walkthrough to see how a dependency list turns into findings. Click a package and look at how the version, advisory and fix are related.
Click through it at your own pace, or open it full screen.
Quick check
Does bundler-audit scan my code?
No. It checks the gems in Gemfile.lock against an advisory database.
Should the build fail on every finding?
Start strict on pull requests, and use dated ignores for accepted cases. A check that always warns gets ignored.
Safeguard offers SBOM and dependency scanning with reachability analysis, so you can see which findings matter in your code. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
