GitLab ships Dependency Firewall and Artifact Central

GitLab used its Transcend event to announce more than a dozen changes across the platform, but two of them land directly in the build path. GitLab Dependency Firewall is in early access and GitLab Artifact Central is in free beta, and together they move GitLab's argument from writing agentic code to controlling what that code pulls in.

Policy before the package lands

Dependency Firewall lets a team define what is allowed into a build before installation rather than scanning for it afterwards. Policies cover malicious status from GitLab's malware advisory database, vulnerability severity with a configurable count of allowed findings, licence type by allow or deny list, and package age so a version published minutes ago cannot be pulled in before anybody has looked at it.

Actions are block, quarantine or warn. Teams are expected to start in warn mode, where the firewall records what a policy would have caught and leaves an audit event, a dashboard entry and a line in the CI summary, and then switch to block mode, which stops the pipeline on a match and gives the reason. A logged bypass lets a named user or token push an approved package through on the record.

Policies are set at the top-level group and inherited by every project beneath it, can be enforced at the registry rather than only in pipelines, and live as code in a security policy project so changes go through a merge request. A glab CLI check tells a developer — or an agent working on their behalf — whether a package would pass before they add it, covering npm, pip, Poetry, Maven, Gradle and Bundler. GitLab cites its own June 2026 research, in which it found five malicious PyPI packages, four of them typosquats of Flask, Requests and NumPy, that ran at install time and stole CI/CD credentials.

One registry instead of hundreds

Artifact Central addresses the other half of the same problem. Retention rules, storage quotas and publish rights currently live inside each project's own package and container registry, which is workable when a person configures each one by hand and breaks down when agents are publishing across hundreds of projects. Artifact Central lifts that configuration to the organisation level, adds four dedicated artifact roles, and closes repositories by default so organisation membership alone grants nothing.

Repositories come in three shapes: hosted for your own packages and images, remote as a proxy in front of something like Docker Hub or Maven Central, and virtual as a single endpoint that checks the hosted repository first and falls back to the remote, caching the first external pull. Publishing and pulling use CI_JOB_TOKEN, the identity pipelines already carry, so an agent uses the same job token rather than a separate service account, and every artifact keeps its provenance — which pipeline built it, from which branch and commit, triggered by whom.

The rest of the Transcend stack

The wider announcement covers GitLab Orbit, the company's context graph, which GitLab says is used by more than 3,500 organisations and has run over 280,000 queries during its beta, with claims of up to 45x fewer retries and 4.5x less token use on agentic workflows. There are goal-driven flows and Custom Flows in the Duo Agent Platform, GitLab Secrets Manager for build-time credentials, the GitLab Security Standard for assessing agentic development, and GitLab Flex, a single annual commitment that covers new capabilities without re-procurement. GitLab also says Anthropic's Claude Mythos 5 and 5.1 will power new Duo Agent Platform security flows.

Artifact Central is available today in beta on GitLab.com, with self-managed availability planned for later this month and no billing during the beta. Dependency Firewall is open for early access requests and works with Artifact Central, Sonatype Nexus Repository and JFrog Artifactory.

Our opinion

The interesting thing about Dependency Firewall is the placement, not the feature list. Software composition analysis tells you what you already shipped; a firewall at the registry and the pipeline tells you what you are about to. Everyone who has cleaned up a compromised build knows those two conversations feel completely different — one is an incident, the other is a policy decision — and moving the check into the place developers already stand, including a glab command they can run before adding a dependency, is the difference between a control people tolerate and one they route around. GitLab citing its own typosquat research on Flask, Requests and NumPy is a fair bit of throat-clearing, but the four-in-five-typosquats detail is exactly why a minimum package age default is worth more than another scanner.

Artifact Central is the more ambitious bet and the harder sell. Consolidating hundreds of project registries into one governed door is the correct answer for an agent-driven workflow, and tying publish and pull to CI_JOB_TOKEN rather than bolted-on service accounts removes a category of credential sprawl that security teams have been fighting for years. The catch is migration: GitLab's answer is to add existing registries as remotes behind a virtual repository and convert them to hosted when a team is ready, which is considerate but also means the sprawl persists in the interim. Betas that promise no billing tend to end with a pricing conversation, and the organisations that move first will have shaped what they pay.

What I would watch is whether the firewall arrives where the risk is. A policy set at the top-level group and inherited downwards is tidy on paper, but a payments service and an internal prototype genuinely carry different risk, and the product's answer — override the policy further down the tree — puts the most consequential decisions at the level with the least context. If GitLab ships good defaults and a dashboard that makes the inherited policy legible, that works. If it ships an empty policy engine and a compliance dashboard, teams will simply run it in warn mode forever and call it adoption.