Policy engine
Rules by package name, version range, age, source, license and custom criteria. Block or log-only, with time-limited exceptions. Re-evaluated on every request.
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.
Bytesafe Dependency Firewall sits in front of your existing repository, protecting developers, CI/CD pipelines and AI agents.
npm dependency firewallMaven dependency firewallPyPI dependency firewallNuGet dependency firewallGo dependency firewallComposer dependency firewallCargo dependency firewallRubyGemsConda dependency firewallContainers dependency firewall
EU-based company · Software supply chain security since 2018.
bytesafe.dev / Firewall
47
Blocked today
1,284
Requests today
12
Active rules
Package
Rule
Status
malicious-pkg@2.1.0
Malware scan
BLOCKED
lodash@4.17.20
CVSS ≥ 7.0
BLOCKED
react@19.1.1
Allowlist
APPROVED
new-release@0.0.1
Age < 7 days
DELAYED
axios@1.7.9
Allowlist
APPROVED
Blocked
malicious-pkg@2.1.0
By Exception
lodash@4.17.21
Delayed
new-release@0.0.1
Approved
react@19.1.1
Offer now
50% off your base fee for 3 months + €100 usage credit.
Supply chain attacks on RubyGems.org
A selection of documented supply chain attacks on RubyGems.org. Malicious releases, account takeovers and dependency confusion have all been used against packages there.
rest-client2019
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.
Account takeoverSleeperGem2026
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.
Dormant account hijackGemStuffer2026
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.
Build pipeline RCEDependency confusionOngoing
RubyGems.org has no namespaces or scopes, so any internal gem name can also be published publicly. A Gemfile source block that is missing or misconfigured resolves against the public gem instead of your private one.
Namespace attackDependency Firewall does not prevent all attacks, but blocks packages that match known malware signatures or violate your policies.
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
Risky packages
Dependency Firewall
Policy engineVetted packages only
Developers and CI/CD
Internal environment
Dependency Firewall capabilities
Policy controls, malware blocking, package delay, dependency confusion protection, and full audit visibility across every RubyGems request.
Vulnerability blocking
Block packages with known CVEs before install. Filter by CVSS and EPSS severity per registry or team. New advisories take effect immediately.
Malware scanning
Detect malicious payloads, suspicious install hooks and obfuscated code before execution. Quarantined packages are logged and never silently dropped.
Dependency confusion
Block namespace attacks where public packages impersonate your internal ones. Configurable upstream priority rules ensure private packages always win.
Zero-day safety delay
Hold newly published versions for a configurable window (7 or 14 days) before they reach developers or pipelines. Gives the ecosystem time to surface threats.
Package observations
Every package is fingerprinted: first-seen date, download frequency, requester, version age. Know exactly what passed through and when.
Audit logging
Every block, allow and exception is recorded and exportable to your SIEM. Built to make security teams and auditors happy out of the box.
Publish scanning
Packages are scanned for malware, secrets, and sensitive data before they are published to an upstream registry.
Time-limited exceptions
Unblock a package with a reason and an expiry date. The exception lapses on its own, so a temporary allowance does not quietly become permanent policy.
Add a security layer to RubyGems
Route RubyGems package traffic through Dependency Firewall, define policies for what's allowed and let the firewall block the rest. Developers and pipelines keep their existing package manager commands.
01
Route RubyGems requests through Dependency Firewall
Point your RubyGems configuration at Dependency Firewall. Every install request passes through the firewall before reaching the registry or your environment.
02
Define your security policies
Set vulnerability thresholds, enable malware scanning, configure safety delays for new versions and write allowlist or blocklist rules. Create multiple firewalls with individual rules for different teams or projects.
03
Bad packages are blocked. Safe ones flow through.
Every request is evaluated in real time. Blocked packages are logged with the policy that triggered them. Approved packages are served transparently.
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
JFrog Artifactory
Sonatype Nexus
GitLab
GitHub Packages
Azure Artifacts
AWS CodeArtifact
Firewall rules
Each rule targets an ecosystem and applies a condition: vulnerability severity, package age, license type or name pattern. Rules either block or log. Stack multiple rules per firewall. Changes take effect immediately.
Security teams can start with broad guardrails, then narrow policies by upstream, package, version range, internal status, maximum age, CVSS score and EPSS score.
Live firewall logs
Every blocked package is logged: package name, version, status, ecosystem, which firewall evaluated it, which rule triggered and who requested it. Filter by firewall or user.
The log view gives developers a fast answer when an install fails and gives AppSec a complete audit trail for policy enforcement.
Package details and scorecards
Open a package to review advisories, licenses, project metadata, OpenSSF Scorecard checks, dependency counts and source links before deciding whether to block, allow or investigate further.
The package page brings runtime firewall context together with upstream project health. Security teams can compare CVEs, maintainer signals, and repository hygiene from the same screen.
Sits in front of what you already run
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 |
RubyGems Dependency Firewall: frequently asked questions
Common questions from security and engineering teams.
How do I point Bundler at Bytesafe Dependency Firewall?
Set bundle config set --global mirror.https://rubygems.org to the firewall URL, then set the matching credential in bundler's global config. Every existing Gemfile keeps naming rubygems.org, so there are no Gemfile or Gemfile.lock changes and the project stays portable. The dashboard generates the exact commands for your firewall when you create it.
Does gem install work, or only Bundler?
Both. For gem install, pass the firewall with --clear-sources --source instead of adding it with gem sources --add: adding a source makes RubyGems fetch the legacy Marshal index, which the firewall does not serve, while passing it per command goes through the compact index.
Does gem push work through the firewall?
Yes. Pushes and yanks are forwarded to the registry you configure as the publish target, and scanned for malware and secrets first. gem push authenticates with GEM_HOST_API_KEY rather than Bundler's own credentials, so set that separately for the publish path.
Is RubyGems support production ready?
Yes. The full rule set applies: the compact index, .gem downloads, the legacy gemspec route older RubyGems clients still request, and gem push and gem yank, on the same vulnerability, malware and license data as every other ecosystem. See docs.bytesafe.dev/firewall/ecosystems/rubygems for current status.
Can different projects have different policies?
Yes. You can create separate firewalls per project. They are lightweight and easy to clone. You can also differentiate by the user or token used for the session. Firewall configurations are small JSON files that can be managed in Git.
Can packages be delayed before they reach developers?
Yes. Dependency Firewall can hold newly published package versions for a configurable window (7 or 14 days) before they reach developers or pipelines. Centralizing delay rules means the protection applies automatically across all teams and pipelines without each project configuring it separately.
What happens if a package passes through but malware is found later?
The firewall tracks all packages via observations: first-seen date, last-seen date, and which firewalls they passed through. When new malware data surfaces, you can see exactly which projects downloaded the affected package and when.
Can firewall rules be automated?
Yes. All configuration is available via API. Configurations can be version-controlled in Git and deployed through your existing automation. All changes are tracked with full rollback support.
Does Dependency Firewall work with enterprise repository platforms?
Yes. Dependency Firewall speaks the same protocols as your package managers, so it is fully transparent to enterprise repository platforms and package registries, including JFrog Artifactory, Sonatype Nexus, GitLab, GitHub Packages and Azure Artifacts.
How is licensing structured?
Two plans: Cloud for SaaS and Enterprise for custom deployment, Managed Cloud or On-Premise. Cloud is priced on whichever you use most: active users, packages scanned or downloads served. See pricing for plan details and add-ons.
Watch it block RubyGems threats
Book a 30-minute session and we'll show you how Dependency Firewall fits into your existing setup. Your registries stay unchanged.