Dependency Firewall offer: 50% off the base fee. See pricing

What's new in Dependency Firewall

Dependency Firewall intercepts every package request before it reaches developers, CI/CD pipelines or AI agents, and blocks malicious, vulnerable and policy-violating packages. Every decision is logged and explained. Existing customers get a supported migration path.

Book a demoStart a free trial

Logs

Firewall All
StatusPackageRule
Allowed
minimist@1.2.5
Exception
Blocked
org.apache.logging.log4j:log4j-core:2.14.1
Block CVSS ≥ 7
Allowed
requests@2.32.5
Log all downloads
Blocked
nx@21.6.4
Delay 7 days
Blocked
event-stream@3.3.6
Known malware
Allowed
react@19.1.1
Log all downloads
Allowed
laravel/framework@12.31.1
Log all downloads
Allowed
github.com/gin-gonic/gin@v1.11.0
Log all downloads

Why a new dependency firewall?

The way teams consume open source has changed. Dependencies enter through developers, CI/CD pipelines, automation, AI coding tools and internal repository flows. The previous-generation firewall was built around a hosted registry and proxy model that predates this picture.

Dependency Firewall is designed as a standalone control point. It intercepts package requests from all of these sources, evaluates them against policy and passes decisions to your existing repository. Think of it like a network firewall, but applied to open source dependencies instead of network traffic.

The policy engine is new from the ground up: more granular rules, live decision logs, malware scanning and exception management that the previous-generation firewall does not have.

What this generation of Dependency Firewall adds

Capabilities not available in the previous-generation firewall.

Redesigned policy engine
Rules based on package name, version range, age, license, vulnerability severity (CVSS and EPSS), ecosystem metadata and organization-specific criteria. More granular than the previous-generation firewall's plugin-based controls.
Malware scanning
Catch known malicious packages before they are installed, cached or promoted internally. Uses dedicated malware databases, not just vulnerability feeds.
Container image firewalling
Container images are gated like any other dependency. Every layer is scanned for malware and secrets, and the apk, dpkg and rpm databases inside the image are read to block images carrying vulnerable OS packages. The previous generation covered packages only.
Decision transparency
See exactly why a package was approved, blocked or approved by exception. Live logs show the package, version, rule, requester and timestamp. Developers and security teams read from the same log.

Works with the repositories you already use

JFrog Artifactory
Sonatype Nexus
GitLab
GitHub Packages
Azure Artifacts
AWS CodeArtifact

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 how it works

Start trialBook a demo

How Dependency Firewall differs from the previous generation

The two products share a name and a purpose. The architecture, policy model and capabilities are different.

Current
Current
What it is
Standalone Dependency Firewall. Sits in front of your existing package registry manager and does not replace it.
Package registry manager with security policies. The previous-generation firewall stores and serves packages.
Package management
No package manager. Designed for teams that already run JFrog Artifactory, Sonatype Nexus, GitLab, Azure DevOps or similar.
Built-in package registry. Teams without a dedicated repository manager used it for storage and serving.
Policy engine
Redesigned rule engine: package name, version range, age, license, CVSS, EPSS and custom rules. More granular and more composable.
Plugin-based controls: vulnerability scanner, license compliance, quarantine, delay upstream, block install scripts and others.
Package state
Stateless: packages are approved, blocked or approved by exception. Observations track which packages have passed through and when.
Quarantine state: packages can be held pending review or attestation.
Decision visibility
Live logs showing the package, version, requester, rule and outcome. Developers see exactly why an install failed and who triggered it.
Basic activity logging.
Exceptions
Developers request exceptions, and the team you choose approves or denies them. Exceptions expire automatically and are logged with the reason.
Not available.
Vulnerability blocking
Define exact CVSS and EPSS score thresholds per rule. Block on numeric score, not just severity label.
Vulnerability scanner plugin with severity levels (Low, Moderate, High, Critical).
Malware scanning
Built-in scanning against dedicated malware databases. Separate from vulnerability feeds.
Not available. Vulnerability feeds only.
Publish scanning
Packages are scanned before upload to your upstream registry.
Not included.
Operations
API-driven. Policy as code. Designed for automation and GitOps workflows.
Managed through the previous product UI.
Ecosystems
npm, PyPI, Maven, NuGet, Go, Composer, Cargo, RubyGems, Conda, Containers. Broader coverage planned.
npm, NuGet, Maven, PyPI.
Status
Active. New customer onboarding focuses on the current Dependency Firewall.
Previous-generation firewall. End of life December 31, 2026. Existing customers can evaluate it now and follow the supported migration path.

One meter sets your price.
The other two come with it.

Your price follows whichever you use most: active users, packages scanned or downloads served. The other two are included at the same plan size.

Enterprise dependency firewalls most often bill on several axes at once: a seat count, a scan count and a bandwidth line, each with its own overage. One team pays three times for being a single size measured three ways, and the invoice is hard to forecast.

Bytesafe measures all three meters and charges for the largest one only. The price per unit falls as you grow. Nothing throttles and nothing blocks when a month runs heavy: the plan sizes itself to the trailing 30 days and settles back as the spike ages out. Optional Cloud add-ons cover SSO/OIDC, container image firewall and Deep Scan. Enterprise plans agree limits in the contract.

See full pricing

Supported ecosystems

Imagenpm dependency firewallImageMaven dependency firewallImagePyPI dependency firewallImageNuGet dependency firewallImageGo dependency firewallImageComposer dependency firewallImageCargo dependency firewallImageRubyGems dependency firewallImageConda dependency firewallImageOCI dependency firewallImageDocker dependency firewall

Migration and end of life

The previous-generation Bytesafe reaches end of life on December 31, 2026. Existing customers can start evaluating the new generation now and migrate before that date. We provide a supported migration path and work through the transition with you based on your setup, ecosystems and repository architecture.

New customers

New customer onboarding focuses on the current Dependency Firewall. We are not onboarding new customers to the previous-generation firewall.

Book a demo to see it in action or get a walkthrough of how it fits your setup. Or start a free trial and set up your first policy.

Book a demoStart a free trial

Existing customers

You can keep using the previous-generation firewall while you prepare and test your migration. Both generations run at the same time, so you can validate the new firewall before production workloads switch.

If you use Bytesafe to store private packages, migration also includes moving those packages to a dedicated repository manager or private registry.

Plan your migration

Common questions

Can existing customers use the new Dependency Firewall today?
Yes. Start a free trial today and evaluate the new Dependency Firewall while continuing to use the previous-generation firewall. The migration page for existing customers covers the process, the commercial offer and the relevant documentation.
When will the previous-generation firewall reach end of life?
The previous-generation Bytesafe reaches end of life on December 31, 2026. Existing customers can evaluate it now and migrate before that date. We help plan the migration based on your existing Bytesafe setup and repository architecture.
Are new customers onboarded to the previous-generation firewall?
No. New customer onboarding focuses entirely on the current Dependency Firewall.
Will migration be automatic?
No. We will work with each customer to determine the right migration approach based on their setup, ecosystems and repository architecture. Migration paths will differ depending on whether you used the previous-generation firewall as a registry or only as a proxy.
Does Dependency Firewall replace our existing repository manager?
No. Dependency Firewall is a standalone control point designed to work in front of your existing repository. It does not store or serve packages.
The previous-generation firewall also stored our packages. What happens to that?
The new Dependency Firewall is a standalone enforcement layer with no package storage. If you relied on the previous-generation firewall for package storage, you will need to migrate to a private package repository such as JFrog Artifactory, Sonatype Nexus or a similar solution. if you would like to discuss a migration path.
Which ecosystems are supported?
npm, PyPI, Maven, NuGet, Go, Composer, Cargo, RubyGems, Conda and Containers are supported. See docs.bytesafe.dev/firewall/ecosystems for current maturity status per ecosystem. Contact us if you need a specific ecosystem that is not listed.
How does pricing work?
Cloud is priced on whichever you use most: active users, packages scanned or downloads served. The other two are included at the same size, so you are never billed twice for one team. From EUR 99 a month. See the pricing page for current plans.

Move to the current Dependency Firewall

Talk to us about access, migration or how the new firewall fits with your repository architecture.

See how it worksBook a demo