No, they lower risk but do not guarantee safety. Multi-factor authentication makes account takeover harder, and trusted publishing removes long lived API keys from release pipelines. Neither reviews the code. As a consumer you still lock versions, scan advisories and watch for unexpected releases.
What each control does
| Control | What it protects | What it does not cover |
|---|---|---|
| MFA on the author account | Stops login with only a stolen password | A maintainer who publishes bad code on purpose |
| WebAuthn or passkeys | Resists phishing better than one time codes | Compromised developer machines |
| Trusted publishing | Short lived tokens for CI releases, no key to leak | A compromised repository or workflow |
| Scoped API keys | Limits what a stolen key can do | Keys with broad scope |
The RubyGems security guide calls MFA the most effective defense against account takeover, and prefers WebAuthn, which resists the phishing behind recent account takeovers in other packaging ecosystems. The command line page states that owners of any gem with more than 180 million cumulative downloads must enable MFA.
How trusted publishing works
The Trusted Publishing guide describes OpenID Connect exchanging short lived identity tokens between GitHub Actions and RubyGems.org. You register a repository, workflow and optional environment as a publisher for a gem. A release is then a git tag push, with no API token to create, rotate or store. The tokens it mints are scoped to push only to that gem.
What this means when you choose dependencies
These are signals, not proof. A gem whose maintainers use these controls is harder to hijack through a stolen password. It can still ship a vulnerable version or be abandoned.
A consumer checklist
- Lock versions and review every Gemfile.lock diff.
- Record the checksums in the lock file, as in our guide to the CHECKSUMS section.
- Scan the lock file for known advisories in CI.
- Watch for new versions of critical gems with no matching changelog or tag.
- Prefer gems with active maintainers and recent releases.
- Consider a delay on brand new versions so the community has time to spot a bad one.
If you publish gems
Turn on MFA with WebAuthn, scope your API keys, add owners sparingly, and switch release pipelines to trusted publishing. The security guide notes that every owner has the same permissions you do, including pushing, yanking and adding other owners.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how new events are surfaced against the packages you actually use.
Where Safeguard fits
Safeguard's SBOM and dependency scanning reads composer.lock and Gemfile.lock and flags known advisories. A free scan takes a few minutes.
Quick check
Is a gem with trusted publishing audited?
No. It only changes how releases are authenticated. The code itself is not reviewed by the mechanism.
Does SMS count as an MFA method on RubyGems?
The setup guide says SMS based authentication or recovery is not supported.
Sources
- RubyGems Guides: Security
- RubyGems Guides: Trusted Publishing
- RubyGems Guides: Using MFA in the command line
- RubyGems Guides: Setting up multi-factor authentication
Last reviewed: 19 October 2026.
