Add Package Hunter as a product feature
Release notes
Problem to solve
Package Hunter is a dependency behavioral analysis tool that has been developed within GitLab. It's goal is to identify previously unknown malicious code dependencies through behavioral analysis of the dependency when they are installed. By identifying dependencies that exhibit suspicious behavior, such as outbound network calls or filesystem changes not related to its intended functionality, Package Hunter can such dependencies from being merged into an application.
Package Hunter currently has functionality for Javascript packages, and it is being run in the nightly GitLab pipeline. This issue is being opened to explore how we can make available it's functionality to GitLab users.
Intended users
User experience goal
The user can elect to use Package Hunter as an additional tool, along with dependency scanner to secure their application's supply-chain.
Proposal
Package Hunter in it's current form is a single job that performs active behavioral analysis on each run on a dedicated VM. This issue is being opened to opened to capture the conversation on what will be needed to take it from a POC to a product feature.
Integration Points
Package Hunters functionality could be impactful in both project pipelines as part of Secure::Composition Analysis and as part of GitLab's Package offering in Package::Package.
In Secure::Composition Analysis, Package Hunter would complement the existing dependency scanning tool. It could be a separate job or extend the existing functionality to incorporate behavioral results.
In Package::Package, Package Hunter could be used as part of the Dependency Firewall. It addition, it could be added as functionality to the dependency managers to scan new packages that are pushed to ensure they do not exhibit malicious behavior.
Scalability
In POC form Package Hunter has a dependency on a VM, which can lead to scalability issues at scale. One way that has been discussed to address this is to have Package Hunter only analyze package versions if they have not been analyzed previously with the results stored in a DB. The actual pipeline job or package manager integration could then use the database for actual results.
Further details
Permissions and Security
Documentation
Availability & Testing
Available Tier
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
This could be a cross-stage feature, as it's functionality would be useful in Secure::Composition Analysis and Package::Package.