`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. For plain-HTTP registries it uses HTTP_PROXY instead, when that’s set. For npm and pnpm, HTTPS_PROXY takes precedence over HTTP_PROXY for plain-HTTP registries too, matching those tools. It connects directly to the hosts listed in NO_PROXY. The proxy setting in your glab configuration applies only to GitLab API calls.

Some package managers have proxy environment variables of their own, such as npm_config_https_proxy, YARN_HTTPS_PROXY, PIP_PROXY, and CARGO_HTTP_PROXY. The proxy reads those variables first, so for those package managers the outbound proxy can differ from HTTPS_PROXY and HTTP_PROXY. A proxy from Yarn’s or pip’s own settings also applies to hosts in NO_PROXY, as it does in those tools.

For npm, Yarn, pip, pipenv, and cargo, the proxy also reads the same settings from your user and global config files, such as ~/.npmrc, ~/.yarnrc, ~/.yarnrc.yml, pip.conf, and $CARGO_HOME/config.toml. It doesn’t read proxy settings from files inside the project, such as a .npmrc or .cargo/config.toml in the repository, or a user or global config file stored there. Outside a Git repository, the working directory and everything under it count as the project.

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. glab dependency-firewall go uses the same outbound proxy and certificates for module downloads from a module proxy. On macOS, on Windows, and when only SSL_CERT_DIR is set, go keeps its own trust for them. Modules that go fetches directly from version control use the certificate and proxy settings of go and git.

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?