Automated/guided remediation

[oliverchang]

Tracking issue for building a guided remediation feature as part of OSV-Scanner.

Some ideas:

• Suggesting direct dependency updates to remediate transitive vulns.
• Ways to prioritize vulnerabilities based on things like dependency depth, severity, whether if it's dev-only etc.
• Minimal re-locks to avoid known vulnerabilities in dependencies.
• Automating upgrades with unit tests in a feedback loop.
• Graph visualisations.

Current roadmap:

• Q1 2024 for release of feature for npm.

Check out #352 (comment) for a walkthrough of what we've been building.

[abhisek]

@oliverchang This will be a VERY useful feature. I have some thoughts here:

Suggest minimal number of direct dependencies to upgrade to specific version to remediate maximum risk.

There is ofcourse a lot of detail to be considered here like how to measure aggregated risk. But it will be very useful in driving remediation, which many a times is not feasible due to too many findings or version conflicts in transitive dependencies when one or more direct dependency is updated.

Also another relatively simpler but valuable feature would be to have the ability to identify direct dependency upgrade to specific version to remediate vulnerabilities in transitive dependencies. I think you already suggested that. I am not sure if it is possible to build a graph by parsing flat lockfiles like gradle.lockfile or requirements.txt

In fact, just by having a dependency graph representation instead of a list will enable a lot of mitigation related analysis capability. I am not sure if its already done, but it may be feasible to build a usable graph based on data from deps.dev API.

Is there any plan to combine OSV and deps.dev data in future to perform both vulnerability detection and effective remediation?

[oliverchang]

Thanks for the feedback @abhisek ! We are definitely looking at ways to make the mechanisms flexible enough for users to decide on what they want to prioritise. Please stay tuned here for once we have some things ready to try.

We are working closely with the deps.dev team here.

[agmond]

Hi @oliverchang,
Will the remediation feature include a command that automatically updates the manifest file and the lock file (like npm audit fix), or will it only have the guidelines for a manual upgrade?

[oliverchang]

@agmond yes: this tool will give you the changed manifest and lockfile at the end of of the guided remediation.

[agmond]

Hi @oliverchang, I have another question here.
Will I be able to remediate only a single vulnerability at a time?
For example, let's say I have several issues in my dependencies file, but I want to fix them one by one (and not all of them at once).
Will this be possible?

[abhisek]

@oliverchang Just checking if someone is already working on this. I need the ability to build dependency graph (instead of list) by parsing lockfiles. I am willing to work on this feature and contribute to osv-scanner but I am guessing its not a trivial change so would like some input on possible approach and challenges that the team foresee.

My approach for this would be in following iterations:

1. Refactor PackageDetailParser to support graph APIs
2. Use deps.dev API to resolve dependencies for a package and add relationship to the graph
3. Use code analysis to identify direct dependencies

What do you think?

[oliverchang]

Hi @oliverchang, I have another question here. Will I be able to remediate only a single vulnerability at a time? For example, let's say I have several issues in my dependencies file, but I want to fix them one by one (and not all of them at once). Will this be possible?

Yes, this tool will be completely configurable.

@abhisek: which ecosystems are you interested in? I suspect the amount of effort would vary largely depending on the ecosystem.

@michaelkedar is already working on this for npm. I believe it's possible to recreate the graph from the existing package-lock.json without any additional API calls -- @michaelkedar can you please confirm?