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

Dependency Firewallfor NuGet

Your rules check every package dotnet restore pulls and block risky versions before they reach the build.

  • Built in Sweden and hosted in the EU
  • Supply chain security since 2018

Supported NuGet upstreams

nuget.org
JFrog Artifactory
Sonatype Nexus
GitLab
GitHub Packages
Azure Artifacts
AWS CodeArtifact

Any NuGet-compatible feed can be an upstream.

Connect one project or the whole company

Package manager config

Set the registry per project

The clear element removes nuget.org, so restore only uses the firewall. nuget.exe reads the same file.

dotnetNuGet.Config
<packageSources>  <clear />  <add key="firewall"       value="https://FIREWALL_HOST/v1/NAMESPACE_ID/nuget/FIREWALL_ID/index.json" /></packageSources>

Best for: trying it on one project, CI pipelines, teams that own their config.

Web proxy chaining

Route the company through your web proxy

Your web proxy hands NuGet traffic to the firewall. Nothing changes on developer machines.

  1. Laptop, CI or agentPackage managernuget.org
  2. Web proxyZscaler, Prisma Access, Squid
  3. Your rulesDependency Firewall

Best for: every laptop and agent at once, including machines nobody has configured.

Web proxy chaining

What your team sees after a block

1 of 3 · 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.

NuGet incidents and the rule that covers each

  • Malicious NuGet packages

    Security researchers documented campaigns uploading hundreds of malicious NuGet packages that impersonated popular Microsoft and community packages. Many contained obfuscated PowerShell payloads in MSBuild targets.

    Malware blocking
  • MSBuild target injection

    NuGet packages can include MSBuild .targets and .props files that run automatically during restore and build. Malicious packages have used this to execute arbitrary code at build time without any explicit install step.

    Release delay
  • Dependency confusion

    Researchers published packages with the same names as internal .NET packages used at large enterprises. The dotnet restore command resolved the public version from NuGet.org over the internal one, silently installing attacker-controlled code.

    Dependency confusion

Clients, proxies and deployment

  • Clients

    dotnet CLI, nuget.exe, Visual Studio and MSBuild restore.

  • Web proxies

    Zscaler, Prisma Access, Squid and other web proxies that decrypt TLS.

  • Deployment

    Cloud as EU-hosted SaaS. Enterprise as Managed Cloud, BYO Cloud or On-Premise.

Explore supported ecosystems

See the setup, rules and incidents for each package ecosystem.

How do I configure dotnet to restore through Bytesafe Dependency Firewall?
Add a package source to your NuGet.config with the Bytesafe Dependency Firewall endpoint URL. Include `<clear />` before the source entry to disable direct NuGet.org access. The dotnet CLI, Visual Studio and MSBuild all read from NuGet.config automatically.
Can I proxy my private Azure Artifacts feed through Bytesafe Dependency Firewall?
Yes. Bytesafe Dependency Firewall can proxy multiple upstreams including Azure Artifacts, GitHub Packages and Sonatype Nexus. Private package names resolve to your internal feed, preventing dependency confusion attacks.
Does it intercept MSBuild target execution from packages?
Bytesafe Dependency Firewall evaluates packages before they are restored to disk, so a blocked package never reaches the MSBuild stage. If a package is blocked, the restore fails before any .targets or .props files are extracted.
Will package version pinning in packages.lock.json still work?
Yes. Bytesafe Dependency Firewall is a transparent proxy that serves the same package metadata and .nupkg files as NuGet.org. Lock file resolution continues to work without modification.
Can different NuGet 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 NuGet installs go through the firewall without changing developer machines?
Yes, with web proxy chaining. A company web proxy that already decrypts TLS, such as Zscaler, Prisma Access or Squid, hands registry traffic to the firewall. Package managers keep the public registry address, and rules, exceptions and logs apply as with a configured client. It is set up on request. Web proxy chaining
What happens if a NuGet 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 own 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 transparent to enterprise repository platforms and package registries, including JFrog Artifactory, Sonatype Nexus, GitLab, GitHub Packages and Azure Artifacts. It can also sit directly in front of the public registry.
How is licensing structured?
Cloud is the SaaS plan. Enterprise is for custom deployment, Managed Cloud or On-Premise. Cloud is priced on whichever you use most: active users, packages scanned or downloads served. Plan details and add-ons

Put NuGet installs behind the firewall

Point one pipeline at Dependency Firewall and read the decisions in the log. The trial runs for 14 days.