Blog Security Coming soon: GitLab dependency firewall
Published on: March 26, 2024
3 min read

Coming soon: GitLab dependency firewall

Learn how this new feature will help organizations avoid supply chain software attacks by warning them or blocking the download based on a project's policy.

built-in-security.jpeg

The Maven dependency proxy was released in GitLab 16.8. This new feature allows organizations to proxy and cache packages from one upstream repository to a GitLab project, which can help reduce reliance on external sources.

However, with this added efficiency there is an added security risk of software supply chain attacks like typosquatting and other dependency confusion attacks. Supply chain attacks are when attackers try to get developers and CI/CD pipelines to include malicious packages to increase the surface area of the attack.

The dependency firewall, planned for the second half of 2024, will help organizations avoid these attacks by warning them or blocking the download based on their project's policy.

What is the dependency firewall?

The dependency firewall is the first line of defense when downloading packages from the internet.

At a high level, GitLab wants to build the following capabilities into the dependency firewall:

  • prevent malicious packages from entering the software supply chain
  • check each new package against GitLab policy
  • quarantine packages for review before they are available
  • manage quarantined packages
  • report package usage

What does a dependency firewall policy do?

The planned dependency firewall policy will do two things: warn and fail. You will be able to create a dependency firewall policy that warns your organization when certain conditions are met or quarantines the package. For example, you can create a policy that prevents the package from being downloaded if it has any known critical vulnerabilities. Or you can simply add a warning for packages with known, but less severe, vulnerabilities.

Note: The warnings can be limited to the log files for the minimal viable change (MVC).

The first rule we'll support will be as follows:

1. When `Security scan`
2. Select "Scanners" (dependency scanning)
3. With `No exceptions` that finds `Any` vulnerabilities matching
4. `Critical` severity

For the MVC, we will focus on adding a warning when a package downloaded through the dependency proxy has any known critical vulnerabilities.

Beyond the MVC, we will add support for the following:

  • lower severity vulnerabilities
  • warnings in the package registry UI list view
  • rules to quarantine packages
  • the ability to review and update the quarantine
  • the ability to add a warning to the security vulnerability report

More about rules

  1. Rules that are warn only can leverage a background job. Rules that fail need to be handled by the web request.
  2. Rules handled by a background job can have an extended scope. For example, we can inspect the package information and open the archive to get the metadata, inspect it, and provide more robust rules and conditions.
  3. Rules handled within the web request must be fast and scalable. This will limit what we can do in these cases.

Next steps

To learn more or contribute to the dependency firewall, please visit our dependency firewall epic.

Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert