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

Policy Governance

Let your security team set the dependency rules every team follows and decide the exceptions. When a rule blocks a package a developer needs, they request an exception from the blocked install. Every request and decision is recorded in the audit log.

Start free trialBook a demo

Today every team sets its own dependency rules

Your security team decides which packages are allowed but has no simple way to enforce that across every team.

Rules differ between teams
Each project has its own package manager settings and CI checks, and they drift apart.
Blocked developers wait on a ticket
A developer asks for an exception in a ticket or a chat message and waits. Sometimes the rule is widened for everyone instead.
Exceptions never expire
An exception stays until someone remembers to remove it, and the reason is lost in a chat thread.
No record of why a package was allowed
Answering an auditor means searching chat, tickets and job logs.

Set the rules for every team and approve the exceptions

The rules sit on a baseline firewall. Team, pipeline and agent firewalls inherit them and cannot weaken them. An exception lets a blocked package past the rule it names, with a reason and an end date.

Log before you block
Run a new baseline rule as log-only first, to see what it would stop across every team.
Configuration as code
Each firewall is a JSON configuration. Review changes in Git, deploy them through the API and roll back.
Audit log
Every block, exception and exception request is recorded, and the log exports to your SIEM.
Malware blocking
A malware rule on the baseline covers every firewall that inherits it.

Only the registry URL changes. Nothing is installed on developer machines.Supported ecosystems

Teams inherit the baseline

Each team, pipeline and agent gets its own firewall with the baseline as its parent. It can add stricter rules and cannot weaken or switch off the ones it inherits.

The justification comes with the request

A request shows why the developer needs the package, next to the exception they asked for. The reviewer can narrow the version or shorten the expiry before approving, or deny with a comment that is emailed to the requester.

More about Dependency FirewallPricing

Who works with it

Security teams
Own the baseline rules and review exception requests for every firewall on the Exception requests page.
Developers
Request an exception from the blocked install, follow it under My requests and get the decision by email.
Platform engineers
Set up a firewall per team, pipeline or agent on the baseline and keep the configuration in Git. Webhooks send request events to chat or your ticket system.

Questions

Can a team opt out of a baseline rule?

Not on a firewall that inherits it: an inherited rule cannot be deleted, edited or disabled there. Whoever creates a firewall chooses whether it inherits and from which baseline, so point package managers at firewalls that inherit it and restrict access tokens to those firewalls. A team that needs one blocked package requests an exception.

Who can approve exceptions?

The team you give permission to add exceptions, such as security. Developers keep the permission to install and to request.

Exception workflow
How do we show an auditor why a blocked package was allowed?

The log entry names the exception that let it through. The exception has a reason and an expiry, and the request behind it shows who asked, the justification, who decided and when.

Can requests reach our chat or ticket system?

Yes. Webhook events fire when a request is created, approved, denied or withdrawn, and each carries the full request.

More Dependency Firewall use cases

All use cases

Try it on one registry

Point one package manager at Dependency Firewall and check the log after the next install. The trial runs 14 days.

Start free trialBook a demo