The next generation Dependency Firewall is launching soon. See what’s new

Go Dependency Firewall

Go's decentralized module system fetches code directly from version control hosts and mirrors. Module path confusion, malicious forks, and compromised module proxies are real vectors. The Go Dependency Firewall sits in front of your module proxy, enforcing policy on every download before it reaches your build environment.

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
Malware
By Exception
lodash@4.17.21
Exception
Delayed
new-release@0.0.1
Age < 7d
Approved
react@19.1.1
Allowlist

Supply chain attacks on Go

A selection of documented supply chain attacks on Go. The Go ecosystem has been targeted by malicious packages, account takeovers, and dependency confusion attacks.

Module path confusion2026

Go modules are identified by their import path. An attacker can register a module at a path similar to a popular one (e.g., github.com/user/go-utils vs github.com/user/go-util) and rely on copy-paste or CI automation mistakes.

Namespace attack
Compromised VCS hosts2026

Go modules are often fetched directly from GitHub, GitLab or Bitbucket. A compromised repository, tag rewrite, or malicious commit pushed to a tag can affect any project that pins to that tag without verifying the go.sum hash.

Source compromise
Malicious Go modules2022+

Security researchers have found Go modules on GitHub that execute malicious code during init() functions. Because Go modules run code at import time, a compromised transitive dependency can execute payloads during go build.

Malware upload
Module proxy poisoning2023

The Go module proxy caches module versions. Researchers demonstrated that module proxies can be targeted to serve modified versions. Running through Bytesafe Dependency Firewall adds a policy evaluation layer before the module reaches your build.

Proxy attack
Dependency confusion2021+

Organizations using private Go module servers are vulnerable to dependency confusion if the go toolchain falls back to public sources. GOPROXY configuration through Bytesafe Dependency Firewall enforces that internal modules always resolve first.

Namespace attack

Dependency Firewall does not prevent all attacks, but blocks packages that match known malware signatures, fail provenance checks, or violate your policies.

Intercepts every Go 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 Go 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 Go registry. No agent installs. No workflow changes.

Public Go registry

Vulnerable and malicious versions included

Risky packages
Bytesafe

Dependency Firewall

Policy engine
Vetted packages only

Developers and CI/CD

Internal environment

Dependency Firewall capabilities

Policy controls, malware blocking, package delay, provenance checks, publish scanning, and full audit visibility across every Go request.

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.

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.

Add a security layer to Go

Route Go 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 Go requests through Dependency Firewall

Point your Go 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.

Configure Go to fetch modules through Bytesafe Dependency Firewall

Set the GOPROXY environment variable to your Bytesafe Dependency Firewall endpoint. The Go toolchain respects GOPROXY across all commands: go get, go mod tidy, go build. Existing go.sum files and module paths continue to work without changes.

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.

Dependency Firewall rules configuration
Dependency Firewall rules configuration

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.

Live request log with blocked packages and rule details
Live request log with blocked packages and rule details

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.

Dependency Firewall package details with security advisories and OpenSSF Scorecard
Dependency Firewall package details with security advisories and OpenSSF Scorecard

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.

CriterionDependency FirewallOther enterprise firewalls
Works with your existing repositoryYes, as a proxy in front of itBundled into their platform most often
Deploys in minutesYesUsually weeks of platform work most often
Predictable pricingFlat, no usage-based feesUsage-based or opaque most often
EU data sovereigntyYesNo, US-based most often

Go Dependency Firewall: frequently asked questions

Common questions from security and engineering teams.

How do I configure Go to use Bytesafe Dependency Firewall as a module proxy?
Set GOPROXY to your Bytesafe Dependency Firewall endpoint: `go env -w GOPROXY=https://registry.bytesafe.dev/go/<firewall-id>/,direct`. The `,direct` fallback is optional. Remove it to force all traffic through the firewall with no bypass. See docs.bytesafe.dev for details.
Does it work with private Go modules on internal VCS hosts?
Yes. Configure GONOSUMDB and GOPRIVATE to list your internal module paths. Bytesafe Dependency Firewall can proxy requests to your internal VCS or GOPROXY server for private modules, while evaluating public modules against your policies.
Does it verify go.sum checksums?
Bytesafe Dependency Firewall enforces your policy rules (CVEs, malware, package age) before the module reaches your build. go.sum checksum verification runs client-side as usual. The two layers are complementary.
Will it work with go mod tidy and go mod download?
Yes. All go toolchain commands that resolve modules respect the GOPROXY environment variable. Bytesafe Dependency Firewall intercepts all of them: go get, go mod tidy, go mod download, and go build.
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. Both include unlimited users, package requests and bandwidth with no usage-based fees. See pricing for plan details and add-ons.

Watch it block Go threats

Book a 30-minute session and we'll show you how Dependency Firewall fits into your existing setup. Your registries stay unchanged.

Book a Demo