`glab dependency-firewall`

Configure and monitor GitLab Dependency Firewall for local package managers. (BETA)

Synopsis

Commands to configure GitLab Dependency Firewall for local package managers, run local package managers with a summary of blocked or flagged packages, and view activity during the current session.

Each package manager command, like glab dependency-firewall npm, runs the package manager binary and forwards every argument to it verbatim. While the package manager runs, the command:

Starts a local proxy and routes the package manager’s HTTPS traffic through it.
Reads the name and version of each package the package manager downloads or publishes.
Asks GitLab to evaluate the package against the policies for the project in your Git remote.
Refuses blocked packages with a 403 Forbidden response, and lets allowed and warned packages through.
Records blocked and warned packages in .gitlab/df/ci-log.json and prints a summary.

When the package manager finishes, the command prints a summary of the packages that matched your policies. A ✖ marks a blocked package, and a ▲ marks a package with a warning. If no package matched, the command prints no summary. A run with at least one blocked package prints the summary to standard error. A run with only warnings prints it to standard output.

Evaluation results are cached for the length of a run, so a package that appears many times in a dependency tree is evaluated once.

If GitLab can’t evaluate a package, the command blocks it. If the Dependency Firewall isn’t evaluating the project, the command allows every package.

The command does not change your registry configuration. For the length of the run, it sets environment variables that route the package manager’s traffic through the proxy and make the package manager trust the proxy certificate. Your existing CA bundles stay trusted.

To reach package registries, the proxy uses the outbound proxy in HTTPS_PROXY, including any credentials in its URL, and connects directly to the hosts listed in NO_PROXY. The proxy setting in your glab configuration applies only to GitLab API calls.

Connections to package registries trust the system certificates, the certificate in the ca_cert setting for your GitLab host, and the CA bundles in SSL_CERT_FILE, REQUESTS_CA_BUNDLE, PIP_CERT, TWINE_CERT, NODE_EXTRA_CA_CERTS, BUNDLE_SSL_CA_CERT, and CARGO_HTTP_CAINFO. GitLab API calls trust only the system certificates and ca_cert, so if your outbound proxy uses a private certificate authority, set ca_cert to that CA to cover both. Module downloads by glab dependency-firewall go trust only the system certificates or SSL_CERT_FILE.

The command writes .gitlab/df/ci-log.json to the working directory on every run, including local runs. Add .gitlab/df/ to your .gitignore file.

To run a package manager command in a GitLab CI/CD job, set GLAB_ENABLE_CI_AUTOLOGIN to true so the command signs in with the CI/CD job token. When the firewall blocks a package, the install fails, and so does the job. For more information, see CI/CD auto-login.

yaml
install:
  variables:
    GLAB_ENABLE_CI_AUTOLOGIN: "true"
  script:
    - glab dependency-firewall npm ci

Package manager commands exit with the following codes:

Exit code	Meaning
The package manager exit code	The package manager ran and exited.
`1`	The package manager was not found on your `PATH` or could not start.
`130`	The run was interrupted or stopped, for example, with Control+C or when a CI/CD job is canceled.

This feature is in beta and might not be ready for production use. It might be unstable and breaking changes can occur outside of major releases. For more information, see https://docs.gitlab.com/policy/development_stages_support/.

Aliases

df

Options inherited from parent commands

  -h, --help   Show help for this command.

Subcommands

Was this page helpful?