Auditing RubyGems Dependencies with bundler-audit

A Rails application is a dependency graph with a web framework attached. Bundler resolves dozens of gems from your Gemfile, and each of those brings its own, so the Gemfile.lock you deploy pins a tree far larger than the list you maintain by hand. Ruby has seen its share of serious gem vulnerabilities over the years, and because so much Ruby code is web-facing, an unpatched gem is rarely a theoretical concern. bundler-audit is the community's standard tool for keeping that tree honest.

How bundler-audit works

bundler-audit is maintained by the rubysec project. It reads your Gemfile.lock — the exact resolved set of gems and versions — and compares it against ruby-advisory-db, a curated database of Ruby security advisories. Because it audits the lockfile, it covers the full transitive graph, and it checks two distinct things: known-vulnerable gem versions, and insecure gem sources (for example, a gem being pulled over plain HTTP instead of HTTPS, which is a supply-chain risk in its own right).

Install it and run a check, updating the advisory database first so you are scanning against current data:

gem install bundler-audit
bundle audit check --update

The --update flag pulls the latest ruby-advisory-db before scanning. The report lists each advisory: the gem, the vulnerable version, the advisory identifier (CVE or OSVDB/GHSA), the criticality, the patched versions, and a description. If a gem has no safe upgrade path yet, that shows too, which helps you plan mitigations rather than blind upgrades.

Handling findings and CI

When you have triaged an advisory and decided to accept it temporarily, ignore it explicitly by identifier rather than muting the whole run:

bundle audit check --update --ignore CVE-2024-00000

bundle audit exits non-zero on findings, so a CI gate is simply:

bundle audit check --update

Run it on every pull request and on a schedule against your main branch, so advisories disclosed after you shipped still surface. Because --update reaches out to fetch the advisory database, in locked-down CI you can pre-vendor the database and drop --update to keep builds hermetic.

Keeping the advisory database current

bundler-audit is only as good as the copy of ruby-advisory-db it scans against, which is why --update matters so much. The database is a separate, continuously updated project, and a check run against a database you fetched weeks ago will happily miss advisories published since. In interactive use, always pass --update. In CI where you want reproducible, network-isolated builds, the better pattern is to vendor a known-good snapshot of the advisory database into your build image on a controlled cadence and run bundle audit check without --update, so you know exactly which advisory set produced a given result. Either way, treat the freshness of the database as a first-class concern — an audit against stale data produces false confidence, which is worse than no audit at all because it feels like diligence.

Where bundler-audit stops

• No reachability. It reports that a vulnerable gem version is in your lockfile, not whether your application calls the vulnerable code. A flaw in an image-processing gem you only use on one admin screen is presented the same as one in your session middleware.
• ruby-advisory-db scope. The database is well-maintained but community-curated and Ruby-specific. Coverage and timeliness depend on volunteers filing advisories.
• Snapshot, no policy. Each run is a point-in-time check with no SLA tracking, no durable accepted-risk record with an expiry, and no consolidated dashboard across services.
• No remediation. It tells you the patched version exists; editing the Gemfile, running bundle update for the specific gem, and validating the app is manual.

Going further

Keep bundler-audit as your fast, Ruby-native gate — the insecure-source detection in particular is worth having on every build. Then layer a continuous platform for the questions it cannot answer. Safeguard's software composition analysis engine ingests the same Gemfile.lock and adds call-path reachability, so the advisories touching code your app actually executes are separated from the long tail that does not, and both are tracked under real policy instead of a per-run printout.

When a safe upgrade exists, the autonomous auto-fix workflow opens a pull request that runs bundle update for the affected gem, resolves the lockfile, and re-runs your test suite — so the fixes bundler-audit merely suggests become review-and-merge changes. Developers keep the familiar local loop through the Safeguard CLI, which runs the same analysis on their machine and in CI.

If you are comparing this against a commercial scanner, the Safeguard vs Snyk comparison breaks down how reachability and autonomous remediation reshape the day-to-day workflow for Ruby teams.

Ruby dependency audit checklist

1. Commit Gemfile.lock; audits are only meaningful against the graph you actually deploy.
2. Run bundle audit check --update on every pull request and fail on findings.
3. Use --ignore CVE-... with a documented reason instead of silencing the whole run.
4. Watch for insecure-source warnings and force HTTPS sources in your Gemfile.
5. Schedule recurring audits of your main branch to catch newly disclosed advisories in shipped code.
6. Add reachability-aware, continuous scanning so engineers fix what is exploitable and every service reports into one policy.

bundler-audit gives Ruby teams a dependable baseline, and its attention to insecure gem sources shows a supply-chain awareness many tools lack. Add reachability, cross-service policy, and autonomous fixes on top, and dependency auditing becomes a managed program rather than a periodic chore.

Bring continuous, prioritized auditing to your Ruby and Rails apps — get started free or read the documentation.