← Scryer

Dependency Security for Rails Applications

What a Gemfile.lock actually needs auditing for, and how a live vulnerability-database query differs from a bundled/offline advisory list.

Your own Rails code isn't the only place a real vulnerability can live — a gem you depend on (directly, or transitively through another gem) can carry a known CVE, and Rails apps accumulate dependencies quickly. Dependency security for Rails means checking Gemfile.lock — the exact resolved versions your app actually runs, not just the loose version ranges in Gemfile — against a database of known-vulnerable gem versions, plus a couple of adjacent risks that aren't CVEs but are just as real.

What to actually check

• Known-vulnerable gem versions — does the exact locked version of every gem in Gemfile.lock have a published advisory? This needs an up-to-date vulnerability database, not a fixed list baked into the tool at release time — new CVEs are published continuously, and a scanner with a stale bundled database will miss everything published since its last release.
• Insecure gem sources — a git: or plain http: (not https:) source in Gemfile.lock means that gem's code was fetched over a channel that isn't verified/encrypted the way the default RubyGems source is — a supply-chain risk independent of any specific CVE.
• Ruby's own end-of-life status — an EOL Ruby version stops receiving security patches from ruby-lang.org entirely, which is a real risk even if every gem is current.
• Leaked credentials in the repo — a committed, un-gitignored config/master.key (Rails' encrypted-credentials key) means anyone with repo access — including a public fork, if the repo is or ever becomes public — can decrypt config/credentials.yml.enc.

Live query vs. bundled database — why it matters

There are two honest engineering approaches to "does this gem version have a known vulnerability," and they trade off differently:

	Bundled/offline advisory database	Live query
Works fully offline	Yes	No — needs network
Coverage of very recent CVEs	Only as fresh as the last gem release/DB update	Current as of the query
Maintenance burden	Someone has to keep syncing the database	None — the query is always live

Scryer takes the live-query approach deliberately: every scan queries OSV.dev (Google's open-source, cross-ecosystem vulnerability database) for each unique gem in Gemfile.lock, so there's no stale bundled database to fall out of date between releases — the tradeoff is that it needs network access to run (skip with --no-deps for a fast, fully offline run when that matters more than dependency coverage, e.g. a pre-commit hook). bundler-audit is the other well-known option in this space, built independently on a different data source (the Ruby Advisory Database) — running both costs nothing and covers slightly different ground.

Running it

# Full scan, dependency audit included by default
scryer

# Dependency audit only, no static code scan — CI-gate mode, mirrors `bundle-audit check`
scryer --audit-deps

# One-off check of a single gem, outside a full scan
scryer --check-gem rails:7.0.0

# Skip the dependency audit entirely for a fast, fully offline run
scryer --no-deps

Inside a Rails app: bin/rails scryer:audit_dependencies (dependency audit only) or bin/rails scryer:ci (JSON + SARIF, dependency audit on, meant for a CI job). Every dependency finding gets a severity and, same as every other finding, an optional AI-rewritten remediation suggestion — see Dependency audit in the full README for exact flags and rake tasks.

Further reading