RubyGems Dependency Firewall
A gem can execute third-party code when installed. Bytesafe blocks malware, vulnerable packages and policy violations before they reach your build. New releases can also be delayed, reducing exposure before malicious packages or vulnerabilities are identified.
Dependency Firewall sits in front of your existing repository, protecting developers, CI/CD pipelines and AI agents.
EU-based company · Software supply chain security since 2018.
Logs
| Time | Status | Package | Version | Rule |
|---|---|---|---|---|
| 09:58:15 | Allowed | rack | 3.2.3 | Exception |
| 09:58:12 | Blocked | strong_password | 0.0.7 | Known malware |
| 09:58:09 | Allowed | puma | 7.0.4 | Log all downloads |
| 09:58:06 | Blocked | sidekiq | 8.0.8 | Delay 7 days |
| 09:58:03 | Blocked | rest-client | 1.6.13 | Known malware |
| 09:58:00 | Allowed | rails | 8.0.3 | Log all downloads |
| 09:57:57 | Allowed | nokogiri | 1.18.10 | Log all downloads |
| 09:57:54 | Allowed | rspec | 3.13.1 | Log all downloads |
Intercepts every RubyGems package request before it reaches you.
Every package install is a potential entry point. Traditional SCA tools find problems after packages are already in your environment. Dependency Firewall intercepts every RubyGems request before it reaches your developers, CI/CD pipelines or AI agents.
You define the rules: block packages with known CVEs, block known malicious packages, or delay newly published versions for a configurable period to give the ecosystem community time to surface zero-day threats.
Works in front of enterprise repository platforms and any RubyGems registry. No agent installs. No workflow changes.
Public RubyGems.org registry
Vulnerable and malicious versions included
Dependency Firewall
Policy engineDevelopers and CI/CD
Internal environment
What Dependency Firewall does for RubyGems
Each firewall runs the checks you turn on, on every package request. Rules block or log, and every decision is recorded.
- Malware blocking
- Blocks packages that match malware data, including malicious payloads and suspicious install hooks. Every block is logged with the package and the rule.
- Vulnerability blocking
- Blocks versions with CVEs above a CVSS or EPSS score you set, per firewall. New advisories apply on the next request.
- Package delay
- Holds newly published versions for a window you set, so malware feeds can catch a bad release before your builds install it.
- Exception workflow
- Developers request an exception from the blocked install. The team you choose approves it, adjusting scope or expiry, or denies it with a comment. Every request and decision is in the audit log.
- Dependency confusion
- Upstream priority rules make internal package names always resolve from your private registry. A public package with the same name cannot take its place.
- Package observations
- Every package that passes records first-seen and last-seen time and request counts. When a new advisory lands, you see which firewalls served the package and since when.
- Audit log
- Every allow, block and exception is logged with the package, version, rule, requester and time. Export it to your SIEM.
- A firewall per team
- Run a separate firewall per team, pipeline or registry. A shared baseline firewall runs first, and team firewalls add rules on top without weakening it.
- Licenses
- Blocks packages with licenses you have not approved before they reach a build.
- Rules as code
- Every firewall is a small JSON configuration. Keep it in Git, deploy it through your automation over the API and roll back to any earlier version.
- Publish scanning
- Packages are scanned for malware, secrets and sensitive data before they are published to an upstream registry.
Half the base fee for your first 3 months
€49.50 instead of €99 per month, plus €100 usage credit. Start with a 14-day trial. See what's new
How RubyGems installs go through the firewall
Your package manager asks the firewall instead of the public registry. The firewall fetches the package from upstream, checks it against your rules and serves it only if it passes.
- 1
Change the registry setting
Point Bundler or gem at the firewall, on laptops and CI runners. Lockfiles, manifests and install commands stay the same.
Developer or CI job
bundle install
Dependency Firewall
Checks your rules
Public registry
rubygems.org
- 2
Set the rules
Block by CVSS or EPSS score, known malware, license or package age. Shared rules go on a baseline firewall that team and CI firewalls inherit, and they run first.

Rules on the npm-ci firewall. The 7-day delay is inherited from npm-baseline. Shown for npm. - 3
Read the log
A version held back by a rule is left out of the version list, so the package manager resolves an older one. A blocked download fails the install. Every decision is logged with the rule and who asked.

New versions held by the delay rule, next to allowed downloads. Shown for npm.
Point Bundler at Bytesafe Dependency Firewall
Set Bundler's mirror config to route rubygems.org through the firewall. Every Gemfile keeps naming rubygems.org, so there are no Gemfile or Gemfile.lock changes and the project stays portable.
Works with the repositories you already use
Inside Dependency Firewall
The screens your developers and security team work with.
1 of 7 · Logs
Live firewall logs
Every request is logged: package name, version, status, ecosystem, which firewall evaluated it, which rule triggered and who requested it. Filter by firewall or user, and tail live during incidents or CI/CD runs.
Developers get a fast answer when an install fails, and AppSec gets an audit trail for every decision.

Why a package was blocked
Open a blocked request to see the package, how old the release is, the rule that stopped it and when it will be allowed.
Add or request a time-limited exception from the same drawer to let one package or version through while the rule keeps applying to everything else. The decision stays attached to the original request, so nothing has to be reconstructed from CI output later.

Firewall rules
Each rule targets an ecosystem and applies a condition: vulnerability severity, package age, license or name pattern. Rules block or log, stack per firewall and take effect immediately.
Start with broad guardrails, then narrow by upstream, package, version range, internal status, maximum age, CVSS score and EPSS score.
See everything a rule can match on
A firewall per team or pipeline
Each firewall carries its own rules, exceptions and upstreams, so a CI firewall can be stricter than a local dev one.
A firewall can inherit from another. Set one baseline with the rules every project must follow and point team firewalls at it. Inherited rules run first and can only be changed on the parent.

Every package that passed through
See which packages each firewall served over a period, with ecosystem, version, first-seen and last-seen time, vulnerability signals and request counts.
When a new advisory or malware report appears, search for the package and see where it was observed and when exposure started.

Package details and scorecards
Review advisories, licenses, project metadata, OpenSSF Scorecard checks, dependency counts and source links before you block, allow or investigate further.

Security dashboard
Rules triggered, exceptions granted and package requests over time. See which firewalls are most active and confirm your policies work after rollout.

Known attacks on RubyGems.org
Malicious releases, account takeovers and dependency confusion have all been used against packages there.
rest-client
Account takeover
- An attacker used a maintainer's password, leaked in an earlier breach, to publish four malicious versions of rest-client. Version 1.6.13 ran a hidden payload from Pastebin.com, but only in installations where Rails.env started with p, as in production. The gem was downloaded about 1,000 times before RubyGems pulled it and locked the account.
SleeperGem
Dormant account hijack
- Two dormant RubyGems maintainer accounts were hijacked within hours of each other in July 2026. One published four malicious versions of git_credential_manager, a new package whose dropper fetched a payload from a fake Forgejo repository, disabled SSL verification, and ran it via PowerShell or shell, first checking around 30 CI-platform environment variables so it would only fire on developer machines. The other compromised account belonged to a Fastlane plugin already at 574,661 downloads.
GemStuffer
Build pipeline RCE
- Over 2,000 packages hit RubyGems.org in two days in May 2026, most of them junk from a registration flood, but some carrying a working exploit: a crafted .yardopts file that RubyDoc.info evaluates when it builds a gem's documentation, letting code run on RubyDoc's own servers. RubyGems suspended new signups for several days to add rate limiting. Researchers suspect automated agents drove the flood; OpenAI says it cannot confirm whether the packages came from AI agents or people.
Also blocks vulnerable and malicious container images before they reach a build agent or production node.
Container Dependency FirewallCompared with other enterprise dependency firewalls
Other enterprise dependency firewalls are often bundled into repository platforms. Dependency Firewall is an independent firewall that works with any registry and is built in the EU.
| Criterion | Dependency Firewall | Other enterprise firewalls |
|---|---|---|
| Works with your existing repository | Yes, as a proxy in front of it | Bundled into their platform most often |
| Deploys in minutes | Yes | Usually weeks of platform work most often |
| Predictable pricing | One meter sets the price, no overage | Several axes with overage most often |
| EU data residency | Yes | No, US-based most often |
Frequently asked questions
How do I point Bundler at Bytesafe Dependency Firewall?
Does gem install work, or only Bundler?
Does gem push work through the firewall?
Is RubyGems support production ready?
Can different RubyGems projects have different policies?
Can RubyGems packages be delayed before they reach developers?
What happens if a RubyGems package passes through but malware is found later?
Can firewall rules be automated?
Does Dependency Firewall work with enterprise repository platforms?
How is licensing structured?
Put RubyGems installs behind the firewall
Try the setup above on one project and check the firewall log after the next install. Or book a demo and go through your registries and rules with an engineer.