Snyk Broker is an open-source client-server proxy that lets the Snyk SaaS platform scan source code sitting behind your firewall — such as GitHub Enterprise, GitLab self-managed, or Bitbucket Server — without you opening any inbound ports or exposing your Git tokens to the internet. If you run self-hosted source control and want a cloud scanner to reach it, the Broker is the mechanism that makes that safe. This post explains the architecture, the security properties that make it acceptable to security teams, and how to deploy it without weakening those properties.
The problem the Broker solves
Cloud security scanners need to read your repositories to analyze dependencies and manifests. If your Git server lives inside a private network, there are two bad ways to grant that access: open an inbound firewall hole so the SaaS can reach in, or hand the SaaS a long-lived credential to your Git that lives on someone else's infrastructure. Both expand your attack surface — the first exposes an internal service, the second puts a powerful token outside your control.
The Broker exists to avoid both. It splits into two pieces and inverts the connection direction so that access is initiated from inside your network, not from the outside.
How the architecture works
Snyk Broker has two components:
- The Broker Server runs on the Snyk SaaS backend. Snyk operates it; you install nothing for this half.
- The Broker Client runs inside your own network, on infrastructure you control, typically as a container.
At startup, the Client initiates an outbound connection to the Server and they establish a persistent, bidirectional secure WebSocket tunnel. Because the Client dials out, there is no inbound port to open on your firewall — the connection is established from the trusted side. Once the tunnel is up, requests flow both directions through it: Snyk asks for manifest files from monitored repositories, and webhooks posted by your Git travel back out.
The important consequence for a security review: your Git tokens stay inside your network perimeter. The Broker Client holds the credential and injects it into requests locally; the token is never stored on or exposed to the Snyk SaaS. The SaaS talks to the Broker Client, and only the Client talks to your Git.
The security properties worth naming
When a security team reviews the Broker, these are the properties that make it acceptable:
- No inbound ports. Communication is outbound-initiated, so you do not expose an internal service to the internet.
- Credentials stay local. The Git token lives with the Client, inside your perimeter.
- Encrypted transport. The tunnel is a secure WebSocket, so traffic is encrypted in transit.
- Scoped and filterable access. The Broker can be configured to restrict which requests are allowed through, so the SaaS cannot make arbitrary calls into your network.
That last point is the one teams most often under-use. The Broker is not just a dumb pipe — it enforces an accept list of the requests it will proxy, which is your opportunity to constrain exactly what the SaaS can reach.
Deploying it without weakening the model
The Broker's security depends on how you run the Client. A few practices keep the model intact:
- Give the Git token least privilege. Provision a dedicated service account whose token can read the repositories Snyk needs and nothing more. Do not reuse an admin PAT.
- Run the Client in an isolated network segment that can reach only your Git server and the outbound tunnel endpoint, not your entire internal network. If the Client host is compromised, you want its blast radius to be small.
- Keep the Client image current. The Broker is distributed as a container and a package; treat it like any other dependency and patch it on a schedule. An SCA tool such as Safeguard can flag known advisories in the Client image before you deploy an outdated one.
- Restrict the accept list. Configure the Broker to proxy only the specific request paths your integration needs, rather than leaving it broadly permissive.
- Monitor the tunnel. Log the Client's activity so you can see what is being requested through it and detect anomalies.
Because the Broker Client holds a real credential to your source of truth, it is a high-value target. Treating its host as a sensitive system — hardened, isolated, monitored — is what keeps the "credentials stay inside the perimeter" promise from becoming "credentials sit on a neglected box inside the perimeter."
When you would (and would not) use it
The Broker makes sense when you run self-hosted source control or container registries and want to use a SaaS scanner against them. GitHub Enterprise Server, self-managed GitLab, Bitbucket Server or Data Center, and on-prem container registries are the canonical cases.
You would not need it if your source control is already cloud-hosted and reachable by the SaaS directly — in that case the extra hop adds operational overhead with no security gain. And if your requirement is that scanning data itself never leaves your network at all, a broker to a SaaS is the wrong tool; you would want a fully self-hosted or on-premise scanner instead. If you are weighing deployment models across tools, the comparison against Snyk touches on on-prem options, and the Academy has a module on secure SaaS-to-on-prem integration patterns.
FAQ
Does Snyk Broker require opening inbound firewall ports?
No. The Broker Client, running inside your network, initiates an outbound connection to the Broker Server on the Snyk SaaS. The resulting tunnel is bidirectional, so no inbound port needs to be opened on your firewall.
Where are my Git credentials stored when using the Broker?
Inside your network. The Broker Client holds the Git token and injects it into requests locally. The token is never stored on or exposed to the Snyk SaaS backend, which is the main reason the Broker satisfies security reviews.
What source control systems does Snyk Broker support?
Self-hosted systems such as GitHub Enterprise Server, self-managed GitLab, and Bitbucket Server or Data Center, as well as on-prem container registries. It is designed for source control that lives behind your firewall rather than cloud-hosted services.
How do I deploy the Broker Client securely?
Give it a least-privilege, dedicated Git service account, run it in an isolated network segment that can reach only your Git server and the tunnel endpoint, keep the Client image patched, restrict the accept list to only needed request paths, and monitor its activity.