# Bytesafe Dependency Firewall Bytesafe Dependency Firewall blocks vulnerable, malicious and policy-violating open source packages before they reach developers, CI/CD pipelines and AI agents. It sits in front of your existing package registry (JFrog Artifactory, Sonatype Nexus, GitLab, GitHub Packages, Azure Artifacts) and evaluates every package request against your policy. - Company: Bytesafe (Bitfront AB), EU-based, Sweden. Software supply chain security since 2018. - Hosting: EU data residency. Cloud (SaaS), Managed Cloud, BYO Cloud, On-Premise. - Ecosystems: npm, PyPI, Maven, NuGet, Go, Containers (OCI). - Pricing model: per dependency firewall endpoint. Unlimited users, package requests and bandwidth on every plan. ## Core capabilities - Policy engine: rules by package name, version range, age, license, CVSS/EPSS severity, provenance. - Vulnerability blocking: block packages with known CVEs before install. CVSS and EPSS thresholds per team or registry. - Malware scanning: block known malicious packages using dedicated malware databases (separate from vulnerability feeds). - Safety delay: hold newly published versions for a configurable window (7 or 14 days) so the ecosystem has time to surface zero-day issues. - Dependency confusion protection: internal packages always resolve from your private registry. - Provenance verification: Sigstore and SLSA attestation checks. Detect version swaps and pipeline tampering. - Publish scanning: scan packages for malware, secrets and sensitive data before upload to an upstream registry. - Audit log: every block, allow and exception recorded and exportable to SIEM. - Live decision logs: package, version, requester, rule and outcome visible to developers and security teams. - Time-limited exceptions with reason and expiry. Exceptions expire automatically. - Policy as code: configuration in Git. API-driven. ## How it works 1. Route CI/CD pipelines and developer tooling at Dependency Firewall instead of public registries directly. 2. Define rules: vulnerability thresholds, malware scanning, safety delays, allowlist/blocklist. Multiple firewalls per environment or team. 3. Every package request is evaluated in real time. Blocked packages are logged with the rule that triggered. Approved packages are served transparently. No agent installs. No workflow changes. Standard package managers (npm, bun, yarn, mvn, pip, nuget) keep working. Only the registry URL changes. ## Pages - /firewall: product overview, capabilities, screenshots, FAQ. - /firewall-next-gen: differences between the new firewall and the current production firewall, plus migration information for existing customers. - /how-dependency-firewall-works: architecture, what is checked on every request, how decisions are logged. - /platform: both products on one page (Dependency Firewall and SBOM Observer) and how they cover CRA, NIS2, DORA and EO 14028. - /pricing: Cloud and Enterprise plans, add-ons, comparison. - /about: company background. - /use-cases: specific scenarios (malware blocking, vulnerability blocking, CI/CD protection, zero-day safety delay, dependency confusion, license enforcement). - /what-is-a-dependency-firewall: product-anchored explainer covering the definition, preventive vs. detective distinction, differences from SCA and repo managers, and how Bytesafe implements it. Links to dependencyfirewall.com for the full category reference. - /security: deployment options (managed SaaS, BYO Cloud, on-premise, partner/MSP), data residency, DPA, who operates it. - /contact: get in touch. --- # /firewall : Bytesafe Dependency Firewall URL: https://bytesafe.dev/firewall Title: Bytesafe Dependency Firewall | Stop risky packages before install Description: Dependency Firewall blocks vulnerable and malicious packages before they reach your developers, CI/CD pipelines, and AI agents. Proxies any registry. ## Summary 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 time to surface zero-day threats. Works in front of enterprise repository platforms and any package registry. No agent installs. No workflow changes. ## Capabilities - 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. - 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. - Dashboard and metrics. Real-time security posture across all registries. See what is 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. ## How it works 1. Route. Point CI/CD pipelines and developer tooling at Dependency Firewall instead of public registries. 2. Define. Set vulnerability thresholds, enable malware scanning, configure safety delays for new versions, write allowlist/blocklist rules. Multiple firewalls per requirement. 3. Block. Every request is evaluated in real time. Blocked packages are logged with the policy that triggered them. Approved packages are served transparently. ## Supported ecosystems npm, Maven, PyPI, NuGet, Go, Containers (OCI). ## Compared to other enterprise dependency firewalls - Works with your existing repository: yes, as a proxy in front of it. Other vendors most often bundle the firewall into their platform. - Deploys in minutes (vs weeks of platform work). - Predictable pricing: flat, no usage-based fees (vs usage-based or opaque). - EU data sovereignty: yes (vs US-based most of the time). ## FAQ - Different policies per project? Yes. Create separate firewalls per project. Firewall configurations are small JSON files that can be managed in Git. Can also differentiate by user or token. - Delay new packages before they reach developers? Yes. Hold newly published versions for a configurable window (7 or 14 days). Attacks on packages like shai-hulud, axios and tanstack exploited the gap between publish and detection. Centralized delay rules apply across all teams and pipelines automatically. - How does malware detection work? Blocks packages that match known malware signatures. - What if a package passes through but malware is found later? Observations track first-seen date, last-seen date, and which firewalls a package passed through. When new malware data surfaces, you can see exactly which projects downloaded the affected package and when. - 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 (UI or CLI) for the rule, package, version, user, IP. - Can firewall rules be automated? Yes. All configuration is available via API. Configurations can be version-controlled in Git and deployed through existing automation. All changes are tracked with rollback support. - Works with enterprise repository platforms? Yes. Dependency Firewall speaks the same protocols as your package managers, so it is fully transparent to JFrog Artifactory, Sonatype Nexus, GitLab, GitHub Packages and Azure Artifacts. - Licensing structure? Two plans: Cloud (SaaS) and Enterprise (custom deployment, Managed Cloud or On-Premise). Both include unlimited users, package requests and bandwidth with no usage-based fees. --- # /firewall-next-gen : Next generation Dependency Firewall URL: https://bytesafe.dev/firewall-next-gen Title: The Next Generation Bytesafe Dependency Firewall Description: Bytesafe is rebuilding Dependency Firewall as a standalone firewall that sits in front of your existing repository. New customers are onboarded to the next generation. Existing customers will receive a migration path and end-of-life timeline. Status: launching early Q3 2026. ## Why a new firewall The current firewall was built around a hosted registry and proxy model. Dependencies now enter through developers, CI/CD pipelines, automation, AI coding tools and internal repository flows. The next generation Dependency Firewall is a standalone control point: it intercepts package requests from all those sources, evaluates them against policy and passes decisions to your existing repository. Like a network firewall, but for open source dependencies. ## What the next generation adds - Redesigned policy engine. Rules based on package name, version range, age, license, vulnerability severity (CVSS and EPSS), ecosystem metadata, provenance and organization-specific criteria. More granular than the current firewall's plugin-based controls. - Malware scanning. Catch known malicious packages before install, cache or promotion. Uses dedicated malware databases, not just vulnerability feeds. - Provenance and trust signals. Verify package origin using Sigstore and SLSA attestations. Detect version swaps and pipeline tampering. - Decision transparency. Live logs of every decision (package, version, rule, requester, timestamp). Developers and security teams read from the same log. - Time-limited exceptions. Logged with reason and expiry. Expire automatically without manual follow-up. - Policy as code. Manage firewall configuration and rules in version control. Roll back safely. Deploy through existing automation. - Publish scanning. Packages scanned for malware, secrets and sensitive data before publish to an upstream registry. - Standalone control point. Sits in front of JFrog Artifactory, Sonatype Nexus, GitLab, Azure DevOps and other repository managers. Does not store or serve packages. - Ecosystems from day one: npm, PyPI, Maven, NuGet, Go, Containers. ## Differences from the current production firewall | Area | Next generation | Current (legacy) | | ---------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------- | | What it is | Standalone firewall in front of your existing repository | Package registry manager + firewall combined | | Package management | None. For teams running JFrog Artifactory, Nexus, GitLab, Azure DevOps | Built-in package registry | | Policy engine | Granular rules: name, version, age, license, CVSS, EPSS, provenance, custom | Plugin-based controls | | Package state | Stateless. Approve, block, or approve by exception. Observations track packages over time | Quarantine state for held packages | | Decision visibility | Live logs with package, version, requester, rule, outcome | Basic activity logging | | Exceptions | Time-limited with approval trail and auto-expiry | Not available | | Vulnerability blocking | Exact CVSS and EPSS thresholds per rule | Severity levels (Low, Moderate, High, Critical) only | | Malware scanning | Built-in, against dedicated malware databases | Not available | | Provenance | Sigstore and SLSA | Not included | | Publish scanning | Yes | Not included | | Operations | API-driven, policy as code, GitOps | Through current product UI | | Ecosystems | npm, PyPI, Maven, NuGet, Go, Containers | npm, NuGet, Maven, PyPI | | Status | Active. New customer onboarding focus | Will reach end of life. Migration path will be provided | ## Pricing model Per dependency firewall endpoint. Developers, package requests and bandwidth are unlimited on every plan. Adding headcount does not change your invoice. Most enterprise dependency firewalls charge per developer or per package volume. ## Migration and end of life - New customers: onboarded to the next generation Dependency Firewall only. - Existing customers: continue on the current firewall until a migration path is agreed. Bytesafe will contact you with timeline and migration plan. End-of-life date is not set yet; advance notice will be given. - If you used the current firewall as a package registry, migration includes moving that storage to a dedicated repository (JFrog Artifactory, Sonatype Nexus or similar). ## FAQ - Can existing customers use the next generation today? Not by default. Contact for early access or migration planning. - When does the current firewall reach end of life? Date not set. Advance notice with a clear migration path will be provided. - Are new customers onboarded to the current firewall? No. Onboarding focuses entirely on the next generation. - Will migration be automatic? No. Migration is scoped per customer based on setup, ecosystems and repository architecture. - Does the next generation replace our existing repository manager? No. It is a standalone control point. It does not store or serve packages. - Which ecosystems? npm, PyPI, Maven, NuGet, Go, Containers. More planned. - How does pricing work? Per dependency firewall endpoint. Unlimited developers, requests and bandwidth. --- # /how-dependency-firewall-works : How Bytesafe Dependency Firewall works URL: https://bytesafe.dev/how-dependency-firewall-works Bytesafe sits between developers, CI/CD pipelines and public package registries. It inspects package requests, enforces policy, and stops malicious, vulnerable or non-compliant dependencies before they enter your environment. ## Request flow 1. Request. A developer, CI/CD pipeline or AI agent runs a package install. 2. Intercept. Bytesafe receives the request before the package reaches the environment. 3. Evaluate. The package is checked against policy: malware, CVEs, licenses, age and provenance. 4. Decide. The package is approved or blocked. Exceptions can be approved by an admin. 5. Log. The result is recorded with the rule, requester and timestamp. ## What is checked on every request - Malware and known malicious packages. Detects malicious payloads, suspicious install hooks, packages flagged in malware databases. - Vulnerabilities. Blocks packages with CVEs above a configurable CVSS or EPSS score. New advisories take effect immediately. - Dependency confusion and namespace risk. Public packages impersonating internal ones are blocked. Private packages always resolve first. - License and compliance policy. Blocks packages with disallowed licenses. - Package age and new releases. Holds newly published versions for a configurable window (7 or 14 days) to let the ecosystem surface zero-day issues. - Provenance and trust signals. Verifies origin using Sigstore and SLSA attestations. Detects version swaps and pipeline tampering. - Ecosystem-specific rules. npm, PyPI, Maven, NuGet, Go and OCI with ecosystem-aware controls. - Custom organization policy. Block or allowlist by package name, version range, requester, team or upstream source. ## Architecture Dependency Firewall is a control point that sits between the package consumer (developer, CI/CD job, AI agent) and the upstream package source (public registry, mirror, enterprise repository). The package consumer keeps using standard package managers (like npm, bun, yarn, mvn, pip, nuget). Only the registry URL changes to point at the firewall endpoint. Upstream registries stay unchanged. --- # /platform : Bytesafe platform URL: https://bytesafe.dev/platform Title: Platform | SBOM Observer Description: SBOM Observer and Dependency Firewall: software supply chain security, compliance, and dependency protection. The Bytesafe platform covers two products. They are sold separately and work independently. Combined agreements are available. ## Dependency Firewall Dependency protection before risky packages reach developers or CI/CD. Sits in front of your existing package registry. Capabilities: - Block CVEs and malware at the registry level. CVSS and EPSS severity filters per team. - Safety delay on new versions. Dependency confusion protection. Sigstore / SLSA provenance. - Publish scanning catches secrets and malware before packages reach your upstream registry. - Full audit log of every block, allow and exception, exportable to SIEM. Flow: public registries (npm, Maven, PyPI, NuGet, Go, OCI / Docker) -> Firewall with rules (CVE, malware, delay) -> compliant packages reach developers and CI/CD. See [/firewall](https://bytesafe.dev/firewall) for the full product page. ## SBOM Observer SBOM management and compliance: component and vulnerability visibility across internal builds and vendor software. Capabilities: - Ingest SBOMs from CI/CD and vendor deliveries. CycloneDX and SPDX normalized into a single model with VEX, VDR and SLSA attestations. - Policy engine for SBOM quality, security and license rules. Enforce in CI/CD, fail builds on violations. - Compliance evidence for CRA, NIS2 and DORA: SBOMs, VEX, VDR and policy results kept per release. Outcomes for compliance teams: single inventory of every component across products, vulnerability exposure mapped to specific applications and releases, audit-ready evidence, supplier SBOM quality tracking. Product website: https://sbom.observer. ## How the platform supports key regulations | Regulation | Product | What the platform covers | | ---------------------------- | ------------------- | -------------------------------------------------------------------------------------------------- | | Cyber Resilience Act (CRA) | SBOM Observer | SBOM, VEX, VDR and policy evidence per release. | | NIS2 | SBOM Observer | Supplier risk via vendor SBOM analysis. | | DORA | SBOM Observer | Third-party ICT risk documented via vendor SBOMs and VEX. | | EO 14028 / NTIA | SBOM Observer | SBOM generation, ingestion, management covering NTIA minimum elements. CycloneDX and SPDX. | | Dependency security policies | Dependency Firewall | Policy on every package request. Block CVEs and malicious packages before install. Full audit log. | ## FAQ - Can we buy a single product, or do we need both? Each product is sold separately and works on its own. Combined agreements across SBOM Observer and Dependency Firewall are available. - How does the platform support CRA, NIS2, DORA and EO 14028? SBOM Observer produces the underlying evidence (SBOMs, VEX, VDR, policy results per release). Dependency Firewall enforces dependency policy before packages enter developer and CI/CD environments. - Is on-premise or private cloud deployment available? SBOM Observer: managed SaaS, private cloud, on-premise (including air-gapped). Dependency Firewall: Managed Cloud, BYO Cloud or On-Premise. - Where is the platform hosted? EU-based company. SaaS hosted in the EU. Private cloud and on-premise deployments run in your own environment. --- # /pricing : Bytesafe Dependency Firewall pricing URL: https://bytesafe.dev/pricing Pricing is per dependency firewall endpoint. A firewall endpoint is one ecosystem ruleset and upstream configuration. Developers, package requests and bandwidth are unlimited on every plan. No per-seat fees, per-scan fees or usage-based overages. ## Plans ### Cloud (Recommended) - €299 / month base. 1 dependency firewall endpoint included. - SaaS only. EU data residency. Standard support. - Unlimited users, no usage-based limits. - Vulnerability and malware blocking. - Package delay for new releases. Cloud add-ons: - Additional firewall endpoints: €99 / endpoint / month. - SSO/OIDC: €129 / month. - Container image firewall (OCI): contact. - Premium support: contact. ### Enterprise - Custom pricing. Includes all Cloud capabilities, plus: - Managed Cloud, BYO Cloud or On-Premise deployment. - Custom firewall endpoint footprint with volume pricing. - SSO/OIDC, Container image firewall, SIEM export scoped into contract. - SLA and premium support scoped to contract. ## Comparison | Area | Cloud | Enterprise | | ------------------------ | ------------------------- | ----------------------------------------- | | Deployment | SaaS only | Managed Cloud, BYO Cloud or On-Premise | | Data residency | EU-hosted | EU, private cloud or customer environment | | Endpoints | 1 included, add more | Custom footprint | | User sign-in | Google, Microsoft, GitHub | Scoped to contract | | SSO/OIDC | Add-on, €129 / month | Scoped to contract | | Audit export | Audit logs included | SIEM export as needed | | Container image firewall | Add-on | Scoped to contract | | Support | Standard | Premium | | SLA | Not included | Scoped to contract | ## FAQ - What counts as a firewall? A firewall endpoint is one ecosystem ruleset and upstream configuration. One npm policy in front of one upstream is one endpoint. Run multiple npm endpoints with different rules for separate teams, applications or environments if needed. - Unlimited users, requests and bandwidth? Yes. No per-seat, per-scan or overage fees on either plan. - When choose Enterprise? Custom firewall footprint (Package firewall and Container firewall endpoints), Managed Cloud / BYO Cloud / On-Premise, SSO/OIDC, SIEM export, premium support with SLA. - Ecosystems supported? Package Firewall Endpoints: npm, Maven, PyPI, NuGet, Go (Cloud and Enterprise). Container Firewall Endpoints: Container image firewall as Cloud add-on or scoped separately on Enterprise. - On-premise / own cloud? Yes, via Enterprise. Cloud is SaaS only. - SSO/OIDC included? Google, Microsoft, GitHub login included. Connecting your own OIDC provider (Okta, Azure AD, etc.) is a Cloud add-on or scoped into Enterprise. - Trial or proof of concept? Yes. Book a demo to scope a PoC. - Fit with existing registries? Sits in front of existing registries. No migration. Works with standard package managers (npm, bun, yarn, mvn, pip, nuget and more). Redirect the package manager config to the firewall endpoint; upstream registries stay unchanged. --- # /use-cases : Dependency Firewall use cases URL: https://bytesafe.dev/use-cases ## Malware Blocking : /use-cases/malware-blocking Stop malicious packages before they reach developer machines. Block account-takeover payloads and install-time malware at the registry, before anyone installs them. Combined with safety delay, closes the gap between publish and detection. Every block is logged with the package, version, requester (user or pipeline) and rule. ## Vulnerability Blocking at Install : /use-cases/vulnerability-management Stop packages with known CVEs before they reach developers. Block at the registry by CVSS or EPSS thresholds, configurable per team. New advisories take effect immediately, no manual rule update needed. Time-limited exceptions with audit records when needed. ## CI/CD Pipeline Protection : /use-cases/ci-cd-protection Apply consistent package policy across every automated build. Route CI/CD pipelines through Dependency Firewall and enforce the same rules on every build. No pipeline changes needed: existing pipelines and package managers continue working, only the registry URL changes. Separate firewalls per environment if needed. Full install-time audit log. ## Zero-Day Safety Delay : /use-cases/zero-day-safety-delay Hold newly published package versions before they reach developers. Configurable delay per ecosystem (e.g. 7 days for npm, 14 for Maven). Closes the window that attacks like shai-hulud, axios and tanstack exploited. Override with a time-limited exception when a specific new version is required urgently. ## Dependency Confusion Prevention : /use-cases/dependency-confusion Internal packages always resolve from your private registry. Prevents public packages from impersonating internal ones. Upstream priority rules enforced at the firewall. No per-developer or per-project configuration. Covers npm, Maven, PyPI, NuGet, Go and OCI. --- # /about : About Bytesafe URL: https://bytesafe.dev/about Bytesafe is a Sweden-based company focused on software supply chain security and transparency. Bootstrapped, founded 2018. EU-based and EU-hosted. Operates as Bitfront AB. Bytesafe builds Dependency Firewall: a control point that sits in front of your existing package registry, blocking risky or unwanted dependencies before they enter production. ## Principles - Clarity. Components should be transparent, not hidden. - Practicality. Compliance frameworks are real; tools should help engineering and security teams do the work. - Trust. EU data stays in the EU. - Independence. Bootstrapped, no venture funding. - Focus. Software supply chain security. - Openness. Open standards (CycloneDX, SPDX), transparent workflows.