GitLab Dependency Firewall blocks risky packages before they reach the build

Why GitLab is moving the check to install time

GitLab argues that the risk is growing because developers are often no longer the ones choosing dependencies. According to the company, AI coding agents now add open source dependencies on their own, often without anyone reviewing or even seeing what landed in the build. A malicious or vulnerable package can then enter a build without anyone deciding to allow it, and its code may run with the same access the pipeline has.

Software composition analysis (SCA), GitLab says, scans what has already been pulled in. By the time it flags a malicious package, a high-severity vulnerability or an unacceptable license, the dependency is installed and may have shipped in an artifact. Tracing it, removing it and rebuilding becomes unplanned work for engineering teams. Dependency Firewall instead applies policy before installation.

What the policies cover and how enforcement works

Teams can define policies for four areas:

• Malicious status: packages flagged in GitLab's malware advisory database.
• Vulnerability severity: the severity level (critical, high, medium or low) and the number of findings allowed at that level, including zero.
• License type: the licenses to allow or deny, listed by full name, and how to treat packages whose license cannot be determined.
• Package age: a minimum age before a package can enter a build, so a version published minutes ago cannot go straight in before anyone has vetted it.

GitLab recommends a gradual rollout. In warn mode, the firewall records what a policy would catch but lets the build continue, leaving an audit event, a dashboard entry and a line in the CI summary. Once teams trust their policies, they can switch to block mode, which stops the pipeline on a match and gives the reason. A logged bypass lets a designated user or token proceed when there is a real need, on the record.

Group-level policies, CLI checks and audit records

Policy can be set once at the top-level group, and every project beneath it inherits the rules. Teams can set a different policy for a group or project. Rules live as code in a security policy project, so they are reviewed and changed through a merge request. Where rules overlap, the strictest one applies, so a critical service can be held above the organization's baseline and no project drops below it.

Developers and agents can also check a package before adding it. Using GitLab CLI in the terminal or in a script, a command line check shows whether a package will pass or be blocked by the policy, without opening a separate console. GitLab says it covers npm, pip, Poetry, Maven, Gradle and Bundler, with more coming soon.

For audits, a dashboard shows activity and outcomes across the projects in scope. Every warn, block and bypass writes an audit event that records the rule that matched, the policy behind it and the package involved. GitLab describes each decision as an immutable record that can be handed to an auditor.

Availability and what it means for teams

Dependency Firewall is compatible with GitLab Artifact Central and with external registries from Sonatype Nexus Repository and JFrog Artifactory, and GitLab says it does not require a separate tool next to an existing GitLab deployment. It is in early access for GitLab.com and GitLab Self-Managed customers on the Premium or Ultimate tier, and interested customers can request access.

For organizations where AI agents add dependencies automatically, the feature is meant to keep that speed while setting policy at the point of install. According to GitLab, packages that satisfy policy requirements become part of the official build, and developers and agents do not have to wait on a manual security review. The company also claims that chasing down exposures for remediation goes from weeks to minutes with built-in governance.