Creating a firewall registry

Work with a firewall registry to centralize security

A firewall registry allows you to centralize security policies, delegate responsibilities and simplify administration. Your policies will automatically be enforced before packages reach downstream registries using the firewall.

Visit Dependency Firewall for general information on what a Dependency firewall is and how these features are crucial when you require the next level of protection for your organization.

Working with firewall registries

Working with firewall registries is just as easy as working with package registries. The added functionality of firewall registries is described below.

When a package is quarantined by a firewall, either manually or by automation, the affected package will also be quarantined in all downstream registries containing the package.

When a quarantined package is deleted from a firewall registry, the package will also be deleted from all downstream registries.

Steps

1. Click on the button Create firewall under Registries in the menu.

Create a firewall button

2. Select firewall type. npm, nuget, maven or PyPI.

3. Enter the name of your new firewall and optionally add a description.

4. Optionally add an upstream by clicking the checkbox “I want to link the registry to an upstream”. For example if you want to proxy and secure packages from the public npm registry.

5. Click on the Create firewall button to add your new firewall.

Create a firewall page

After creating a new firewall registry you can add upstreams at any time (e.g. for public open source dependencies) and configure additional plugins/policies. By default the vulnerability scanner and license compliance plugins are enabled for new firewall registries.

New firewalls are internal by default, which means your packages will be marked as internal and protected from dependency confusion attacks.

More info

Different firewall setups

In its core Bytesafe acts as a secure proxy to the insecure world of public open source packages. Each package added to Bytesafe will be scanned for vulnerability and open source license compliance issues.

With firewall and package registries you can define your own hierarchy of policies to match your use case and requirements. Each individual firewall and registry can have its own set of policies, and are applied in order as packages flow through the hierarchy.

Working with firewalls and registries is very flexible. Below are a few examples to get inspiration from.

Basic setup with a secure perimeter

For a basic setup an organization might only use a firewall registry, as it can also contain packages. This example shows two development teams and a CI/CD environment using a common firewall registry. In this case the firewall registry is also used as the main source for all the dependencies required.

graph TD
A(External registry) --> |  Insecure packages | B{Firewall registry};
B --> | Secure packages | C[fa:fa-user Team A];
B --> | Secure packages | D[fa:fa-user Team B];
B --> | Secure packages | E[fa:fa-server CI/CD];
style B fill:#b91c1c,color:#fff

Larger organizations with different security needs for different teams

In the case where different teams or products require different sets of restrictions it might be necessary to use more than one level of registries. Bytesafe supports this by connecting of firewall and package registries into hierarchies.

With this setup the organization can centralize security policies in the firewall registry and have unique configuration on the package registry level. This is a common setup when you have different compliance requirements for different applications.

graph TD
A(External registry) --> |  Insecure packages | B{Firewall registry};
B --> |  Secure packages | C{Registry A};
B --> |  Secure packages | D{Registry B};
C --> | install | E[fa:fa-user Team A];
C --> | install | F[fa:fa-user Team B];
D --> | install | G[fa:fa-user Team C];
D --> | install | H[fa:fa-server CI / CD];
style B fill:#b91c1c,color:#fff

Enterprise setup with separate integration and patch registries

Here’s another example with multiple teams and applications

  • Dedicated firewall registry
    • Configure external upstreams, for example Npmjs
    • Additional rules
  • Dedicated registry for patching external packages
  • Dedicated registry for sharing internal packages between teams
graph TD
    RA --> A(fa:fa-user Team A)
    RA --> B(fa:fa-user Team B)
    RA --> C(fa:fa-server CI/CD)
    RC --> D(fa:fa-user Team C)
    RC --> E(fa:fa-server CI/CD)
    I[Integration] --> RA[Registry A] &  RC[Registry B]
    P[Patches] --> RA[Registry A] &  RC[Registry B]
    F{Firewall registry} --> RA & RC
    OSS[External registry] --> F
    OSS2[External registry] --> F
    style F fill:#b91c1c,color:#fff