The Ruby Advisory Database is a community effort that stores one YAML file per advisory, grouped by gem name or Ruby implementation. The bundler-audit tool checks your Gemfile.lock against it. Read the patched versions field to learn what to upgrade to.
How the repository is laid out
The README says the database is a list of directories that match the names of Ruby libraries on rubygems.org. Inside each directory are one or more advisory files, named with the CVE or GHSA identifier (older files use a legacy OSVDB number). There are two top level directories:
gems/for libraries, one subdirectory per gem.rubies/for Ruby implementations, such as the reference implementation, JRuby and mruby.
The maintainers say they expect others to create the underlying data, such as getting CVE and GHSA identifiers, and they invite pull requests for vulnerabilities not yet listed.
Fields worth reading
The README shows example advisories. A gem advisory includes the gem name, a CVE and GHSA identifier, a URL, a title, a date, a description, and patched_versions. The description in the example also lists versions affected, versions not affected, fixed versions, impact and workarounds. A Ruby implementation advisory uses an engine field instead of gem.
The part you act on is patched_versions, which uses version constraints. The example for one gem shows several patched series at once, for instance one constraint per supported minor line plus an open ended constraint for the newest line. That is a reminder that fixes are often backported, so you may not need a major upgrade.
Reading a constraint
| Constraint style | Meaning in plain words |
|---|---|
| A pessimistic constraint on a minor series | Patched in that series from a stated point |
| An open ended greater than or equal | Patched in this version and later |
| Several entries together | Patched on any of these series |
If your resolved version satisfies none of the entries, the advisory applies. In the example, the description also says that users on a newer Ruby are not affected, so the advisory text sometimes holds environment conditions that the constraint cannot express. Read both.
Using it with bundler-audit
The README says you can check your own Gemfile.lock against the database using bundler-audit. It also mentions a case where users of a long term support Rails fork are advised to add a list of CVEs that the fork addresses to the ignore section of the bundler-audit configuration file. That is a good model for a documented exception: the ignore list names the specific identifiers and the reason.
A routine
- Run bundler-audit in CI on every pull request and on a nightly schedule.
- Update the advisory data before each run, so a nightly job sees new entries.
- For each finding, open the advisory file and read affected and patched versions.
- Upgrade within the series if a backport exists.
- If you ignore an advisory, record the identifier, the reason, an owner and a review date.
- Re-check ignores when you upgrade Ruby, since a condition in the text may change.
Where Safeguard fits
Safeguard's SBOM and dependency scanning checks the dependencies you ship against advisory data, and policies and gates can fail a pull request on your chosen threshold. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Where do the CVE identifiers in the database come from?
The maintainers say they expect others to create the data, such as getting CVE and GHSA identifiers.
Does a matching gem name always mean I am affected?
No. Compare your resolved version with the patched versions, and read the description for conditions such as the Ruby version.
Sources
- Ruby Advisory Database README, fetched 19 October 2026.
Last reviewed: 19 October 2026.
