glab dependency-firewall

Check package URLs, run supported package managers through GitLab Dependency Firewall, and inspect recorded activity. This command group is beta. Confirm availability before relying on it in durable automation.

Go support and network safety

glab dependency-firewall go (also glab df go) runs go through a temporary loopback module proxy on 127.0.0.1. Inspect it with glab help dependency-firewall go; arguments after the wrapper name are forwarded to go. package also accepts versioned golang PURLs and preserves module-path case, including github.com/BurntSushi/toml.

The wrapper accepts the default GOPROXY=https://proxy.golang.org,direct or preserves GOPROXY=off; other effective values stop the run before the requested Go task starts. During a proxied run it sets GOPROXY to the local proxy, GONOPROXY=none, and GO111MODULE=on. Private modules matched by GOPRIVATE are checked, then fetched according to the existing Go configuration. It does not persistently rewrite that configuration or the system trust store.

Only modules downloaded during the run are checked. Cached modules, vendored code, and local-path replace targets are not checked. An approved CI run can use an empty GOMODCACHE to include all downloaded dependencies; do not delete a shared cache merely to force coverage. Go toolchain downloads are outside policy checks and use Go checksum-database verification. Preserve checksum settings. A no-download run, including GOPROXY=off, does not prove dependencies passed policy.

Module paths and versions, including private ones, reach the policy API and can be written to .gitlab/df/ci-log.json; publishing that log as a CI artifact exposes those coordinates. Approve that data scope along with downloads and task execution. The module proxy itself uses no certificate, but the wrapper's process environment can still break HTTPS certificate checks in networked tests. Separate an approved dependency-download step from networked tests when needed; do not rerun blocked downloads outside the wrapper.

Package checks contact GitLab; wrappers also launch package-manager processes that can download, install, execute build scripts, or upload packages. Approve the target repository, network destinations, and underlying operation before invoking a wrapper. Help is not authorization to install or publish packages. Keep integrity checks enabled and use the glab help dependency-firewall <wrapper> discovery path.

For wrappers, policy transport errors, including a nonresponsive API reaching the 60-second evaluation deadline, become blocked results rather than allowing downloads. The standalone package check reports transport failure as exit 1. Failed checks remain retryable within the run. There is a distinct exception: the API's not-evaluating result (HTTP 404 when the feature is off or the project is inaccessible, or HTTP 422 when policy is not enforced) is logged and allows that project for the rest of the run. An allowed run therefore does not prove enforcement was enabled. Confirm project access and policy enforcement; do not bypass a block or mistake a not-evaluating message for a policy approval.

The Yarn wrapper supports Classic 1.x and Yarn 3.2 or later, and rejects 2.x through 3.1. For Berry, a temporary injected plugin clears merged per-host networkSettings from every rc-file tier (project, ancestors, and home) before requests, keeping traffic on the firewall proxy. Existing registry configuration is retained, but per-host proxy/CA/network overrides are ignored during the run. Review compatibility before starting the approved install; this does not persistently rewrite rc files.