Optimize order of auto-remediations for Dependency Scanning
Release notes
Problem to solve
As a user of Auto-Remediation for Dependency Scanning, and in a context where finding remediations is time consuming, I want Dependency Scanning to first explore remediations that have the greater value:
- greater impact on the security of the project being scanned
- lower risk of making the scanned project break
If the long-running auto-remediation process is aborted because of a timeout, I want Dependency Scanning to return the remediations that have more value.
Intended users
User experience goal
Proposal
Before finding remediations, first order candidate remediations based on these criteria:
- Severity (S): remediations for more severe vulnerabilities should be explored first
- Magnitude of change (C): remediations that introduce a smaller change should be explored first
The severity directly comes from the security advisory stored in the Vulnerability Database.
The magnitude of change (C) can based on the difference between the affected version and the closest fixed version. The assumption is that upgrading a dependency to a version that's close to the current one is less likely to make the tests fail or to introduce a regression, compare to upgrading to a version that's far ahead.
For instance, upgrading a dependency to the next MINOR version is a bigger change compared to upgrading to the next PATCH version. It's assumed that the libraries the project depends on make good use of SemVer.
Also, C should take into account the distance between the affected and fixed PATCH versions (if MAJOR and MINOR are the same) or between the affected and fixed MINOR version (if MAJOR is the same). For instance, upgrading from X.Y.Z to X.Y.Z+3 is a bigger change to compared to upgrading to X.Y.Z+1.
Finally, C could take into account the depth of the dependency in the dependency graph, and give higher score to higher dependencies compare to more nested ones.