GitLab introduced Dependency Firewall in early access at its Transcend event. It is a policy layer that blocks malicious, vulnerable and non-compliant packages before they reach a build. For CI owners, the useful part is where the check runs. Most dependency scanning reports on a package after a job has already installed it. This firewall is meant to stop the package before install, while the job still holds its credentials and nothing hostile has executed.
What shipped
Per the GitLab blog, the firewall is available to Premium and Ultimate customers on both GitLab.com and GitLab Self-Managed. It works with GitLab Artifact Central and with external registries from Sonatype Nexus Repository and JFrog Artifactory. Supported package managers at launch are npm, pip, Poetry, Maven, Gradle and Bundler, and GitLab says more are coming.
Policies can match on four things:
- malicious status, drawn from GitLab's malware advisory database
- vulnerability severity, at critical, high, medium or low
- license type, with an allow or deny list
- package age, a minimum age a package must reach before it can enter a build
Each policy runs in one of two modes. Warn mode records what the policy would have caught and lets the build continue. Block mode stops the pipeline on a match and reports the reason. A logged bypass lets a designated user or token proceed anyway, and the bypass is recorded.
Why the install step is the exposure
GitLab's own research is the case for the feature. In June 2026, its researchers found five malicious PyPI packages, four of them typosquats of Flask, Requests and NumPy. The packages ran at install time and stole CI/CD credentials.
That shapes the blast radius. A package that executes during pip install runs inside the job, with whatever tokens, cloud credentials and deploy keys that job can reach. A scanner that flags it in a report afterwards is useful for the incident timeline, but the secrets are already gone. Rotating them is the expensive part of the response, and it usually means paging someone.
GitLab also notes that AI coding agents now add open source dependencies on their own, often unreviewed. A typosquat that a human reviewer might catch in a diff can reach a merge request that nobody reads line by line.
Rolling it out without breaking main
The two modes suggest the order to work in. Start every policy in warn mode, let it run across a normal week of pipelines, and read what it would have blocked. License and severity policies are the likeliest to match dependencies you already ship, and you want to see those matches before they turn into red builds. Move the malicious-status policy to block first. That is the one with the fewest legitimate matches and the most damage if it misses.
Decide who holds the bypass before you turn on blocking. A bypass that only one person can grant will turn into a 3am bottleneck the first time a hotfix trips the age policy.
Where it will bite
The package-age policy works against urgent patches. When a critical fix lands, the version you need is by definition the newest one, and a minimum-age rule will block it. Plan for that case through the logged bypass, not by loosening the rule under pressure.
Bypass tokens are credentials. Treat them like any other secret that can push a blocked package into a build. Scope them, rotate them and review the bypass log.
Coverage is bounded twice. Malicious-status matching is only as current as GitLab's malware advisory database. Ecosystems outside the six listed package managers are not covered yet. During early access, also confirm that every job actually resolves packages through one of the supported registries. A job that installs straight from a public index is outside the gate.
How teams gate dependencies elsewhere
Pre-install gating is not new to the package-registry market. Sonatype and JFrog both sell curation products that sit in the repository manager, which is why GitLab's support for Nexus and Artifactory registries matters to teams that already run them.
Teams without a registry-level gate usually combine smaller controls. Renovate's minimumReleaseAge setting delays update pull requests until a release has aged, which is the same idea as GitLab's age policy applied at proposal time instead of at install time. Lockfiles with hashes make an install reproducible:
pip install --require-hashes -r requirements.txt
npm ci
Hash pinning stops an artifact from changing under you, but it does nothing about a malicious package that was pinned on purpose. That case still needs a reviewer, or a policy that runs before install.
Top comments (0)