Self Healing Dependencies
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
This issue explains the introduction of a proactive dependency update feature. At the moment, we do not provide users/developments with automated assistance that helps them to keep their dependencies updated.
Proactive dependency updates, as opposed to reactive dependency updates (a.k.a. remediation), are not triggered by an already existing vulnerability. Instead, they are triggered by the availability of a newer (direct/top-level) dependency. Assuming that a higher version number of a dependency indicates a lower degree of faultiness, which should be the case for dependencies that rely on semantic versioning, proactive dependency updates can potentially reduce bugs (including security issues). Therefore, proactive dependency updates can be viewed as a mechanism to prevent bugs in the first place and are therefore complementary to dependency scanning (DS) for security.
While security issues can be remediated through gemnasium, we do not have a natively integrated mechanism to offer proactive dependency updates (such as Dependabot).
As a developer/user, I want my dependency tree to be up-to-date to improve the overall security posture of the software projects. Proactively notifying the developer about newly available dependency versions and provide automated assistance for dependency updates can help developers/users to get there.
Intended users.
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
- Cameron (Compliance Manager)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
- Alex (Security Operations Engineer)
- Simone (Software Engineer in Test)
User experience goal
The user should be able to specify an update policy for a software project (something along the lines of bump patch,bump minor, bump major) based on which project depedencies are updated automatically. We could then generate MRs with the updated dependency and lock file versions which could be merged in if the test suite passes.
Alternatively, we could also integrate a dependency update functionality into the Security & Compliance dependency list which could notify a user about the availability of new dependency versions; we could integrate a button that kicks-off the MR generation.
Proposal
Most package managers rely on a dependency-file (e.g., Gemfile) that includes the direct dependencies including version constraints. When running the build of a software project, the package manager fetches those dependencies that adhere to the version constraints defined in the dependency file, their transitive dependencies, and creates a lock file (Gemfile.lock) that contains all dependencies with their locked/concrete versions if it does not exist already.
As mentioned above, proactive dependency scanning is targeting direct dependencies. The package names and versions of the direct dependencies could be extracted from the lock file; this information could then be used to check whether newer versions than the ones defined in the lock file are present on the package registry.
Documentation
Availability & Testing
What does success look like, and how can we measure that?
Users can automatically update their dependencies. We can measure success by counting the number of MRs that were automatically generated and merged. Another measure of success would be the number of customers that have proactive dependency updates switched on.
What is the type of buyer?
gitlab-org/secure/vulnerability-research/awesomesauce~3207279
Links / references
Self healing dependencies live-stream by Sid - https://www.youtube.com/watch?v=yn-V8F_Sjr4
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.