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.
The next generation Dependency Firewall is launching soon. See what’s new
Dependency Firewall for
Blocks malicious, vulnerable and policy-violating packages.
Bytesafe 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.
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
Intercepts every 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 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 package registry. No agent installs. No workflow changes.
Public registries
npm, Maven, PyPI, NuGet, Go, Containers
Your repositories
Enterprise platforms and mirrors
Vulnerable packages
Dependency Firewall
Policy engineVetted and compliant
Developers and CI/CD
Internal network
Dependency Firewall capabilities
Policy controls, malware blocking, package delay, provenance checks, publish scanning, and full audit visibility across every 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.
Provenance verification
Verify packages were built by expected publishers using Sigstore and SLSA attestations. Detect pipeline swaps and version downgrades early.
Dependency confusion
Block namespace attacks where public packages impersonate your internal ones. Configurable upstream priority rules ensure private packages always win.
Package observations
Every package is fingerprinted: first-seen date, download frequency, requester, version age.
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.
Dashboard and metrics
Real-time security posture across all registries. See what's blocked and why, which teams trigger the most flags and how exposure trends over time.
Publish scanning
Packages are scanned for malware, secrets, and sensitive data before they are published to an upstream registry.
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. Rules are easy to review because the selector and effect are visible in one place.
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. Tail live during incidents or CI/CD runs.
The log view gives developers a fast answer when an install fails and gives AppSec a complete audit trail for policy enforcement. Open a row to inspect request metadata, package context and the exact rule that caused the decision.
Block reason details
Every blocked package shows full context: ecosystem, version, publish date, the rule that triggered and whether the effect is block, log, or both. No guesswork for developers or security teams.
When a package is blocked, teams can decide whether to add an exception, change the rule, or fix the dependency without searching through CI output. The drawer keeps the investigation attached to the original request.
Firewall observations
See which packages have passed through each firewall over a selected period, including ecosystem, version, first-seen time, last-seen time, vulnerability signals and request counts.
Observations turn package traffic into an inventory of what your organization actually requested. When a new advisory or malware report appears, you can search for the package and see where it was observed and when exposure started.
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, repository hygiene and dependency structure from the same screen.
Security dashboard
Monitor rules triggered, exceptions granted, and package requests over time. See which firewalls are most active, spot trends, and verify your policies are working as expected.
Dashboard charts make policy behavior visible after rollout. Use them to confirm traffic is flowing, understand request volume, and spot unusual spikes before they become incidents or noisy developer escalations.
See how Dependency Firewall works
Covers the architecture, what gets checked on every request, how decisions are made and logged, and how it fits in front of your existing registry setup.
How it works →Add a security layer to any package manager
Route package traffic through Dependency Firewall, define policies for what's allowed and let the firewall block the rest. Developers and pipelines keep their existing URLs and credentials.
01
Route package requests through Dependency Firewall
Instead of pulling public packages directly, point CI/CD pipelines and developer tooling at Dependency Firewall. Every request passes through the firewall before reaching 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.
Works with the repositories you already use
JFrog Artifactory
Sonatype Nexus
GitLab
GitHub Packages
Azure Artifacts
AWS CodeArtifact
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 |
| Deploys in minutes | Yes | Usually weeks of platform work |
| Predictable pricing | Flat, no usage-based fees | Usage-based or opaque |
| EU data sovereignty | Yes | No, US-based most of the time |
Frequently asked questions
Common questions from security and engineering teams.
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. Attacks on packages like shai-hulud, axios and tanstack exploited the gap between publish and detection. Centralizing delay rules means the protection applies automatically across all teams and pipelines without each project configuring it separately.
How does malware detection work?
Dependency Firewall blocks packages that match known malware signatures.
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. This gives your AppSec team a clear investigation trail.
Are there alerts when a package is blocked?
The package manager reports the version could not be found, which breaks the build. Developers and CI/CD check the firewall logs (via UI or CLI) to see exactly which rule triggered and why. Audit entries include package name, version, user, IP, and the blocking rule.
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. It evaluates each package against your defined policies before it is served.
How is licensing structured?
Two plans: Cloud for SaaS and Enterprise for custom deployment, Managed Cloud or On-Premise. Both include unlimited users, package requests and bandwidth with no usage-based fees. See pricing for plan details and add-ons.
Watch it block real threats
Book a 30-minute session and we'll show you how Dependency Firewall fits into your existing setup. Your registries stay unchanged.