Vet a gem by downloading it without installing, unpacking it, and reading the gemspec, the files list and any native extension script before you run anything. Then check who owns it, how old its releases are, and install through a lockfile with a cooldown. Ten minutes beats a compromised laptop.
Why does installing a gem need care?
The RubyGems security guide opens with a blunt sentence: installing a gem runs someone else's code on your machine, with your privileges. That is true for the gem's Ruby files when you require them, and it is also true earlier, at install time, for gems with native extensions. An extension ships a configuration script, conventionally named extconf.rb, and the build runs it. A gem can therefore do something at the moment you type install, before your application ever loads it.
How do you look inside without running it?
RubyGems gives you the tools. gem fetch downloads a gem into the current directory without installing it. gem unpack extracts the files so you can read them. gem spec prints the specification, which shows the declared version, authors, dependencies and, importantly, the list of extension scripts.
A short read order works well:
- The specification: do the authors, homepage and license match the project you meant? Does it declare extensions it has no reason to need?
- The dependencies: a tiny gem that pulls in several obscure ones deserves a closer look.
- Any
extconf.rb: read it fully. Network calls, shell commands or encoded strings in a build script are a stop sign. - The files list: does it match the repository, or are there files that exist only in the packaged version?
The RubyGems guide also tells authors to build the gemspec file list from an explicit allowlist and to review packaged files with gem unpack before pushing. Doing the same as a consumer is the mirror image.
What about owners and history?
On the gem's page, look at the owner list and the version history. A gem with one owner, no repository link and three releases in one day is different from one with years of releases and several maintainers. RubyGems guidance for authors recommends multi-factor authentication, preferably WebAuthn, and says you can require MFA from all owners of your gems, so check whether a gem you depend on does. For publishing, Trusted Publishing lets a CI workflow push with short-lived tokens, so a gem released that way has no long-lived API key to steal. These are signals, not guarantees.
Compare the name against what you meant to install. A constructed case: you want a popular HTTP helper but type a name that swaps two letters. The page exists, it has a plausible description, and it was published last week. Fetch and unpack it and the repository link is missing, which is enough to stop.
How do you reduce the damage if you are wrong?
Commit Gemfile.lock so later installs use the exact code you reviewed. Newly generated lockfiles carry a CHECKSUMS section that Bundler verifies, and a tampered gem then fails to install. Set a Bundler cooldown, since the guide notes most malicious releases are yanked within days, and run bundler-audit in CI against the community advisory database. If you suspect a malicious gem, the guide asks you to report it to security@rubygems.org and not to open a public issue.
What to do
- Run
gem fetchfor the exact version you plan to use. - Run
gem unpackand read the specification and file list. - Read every extension script and any install hook in full.
- Check owners, release dates, repository link and whether the code matches the repository.
- Add the gem, commit the lockfile with checksums, and keep a cooldown enabled.
- Install first in a disposable container or CI job with no secrets.
- Record why you approved the gem in the pull request.
Safeguard can also look up package details and risk signals; the free scan at gold.safeguard.sh/scan checks up to 100 dependencies in the browser.
Quick check
Can a gem run code before I require it?
Yes. Gems with native extensions run a build script during install, so read it before installing.
Do checksums prove a gem is safe?
No. They prove the gem has not changed since the lockfile was created. They say nothing about whether the original was safe.
Sources
- RubyGems Guides: Security
- RubyGems Guides: Command Reference
- RubyGems Guides: Gems with Extensions
- RubyGems Guides: Trusted Publishing
Last reviewed: 18 October 2026.