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
- Rules that are
warnonly can leverage a background job. Rules thatfailneed to be handled by the web request. - 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.
- 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.
