Add Remediation advice to each library vuln

[benschwarz]

The no-vulnerable-libraries audit detects and lists security vulnerabilities, but is not able to be used "offline" because there is no remediation advice to go with the vulns.

This means we're not able to format lighthouse 'advice' or 'opportunities' as we do elsewhere.

Current output from no-vulnerable-libraries audit:

Information we don't have in the audit but need:

Having the semver ranges would be useful, but we'd also need to know the current released version of a given library (Snyk vuln page):

If we can have the current released version of a given library added to the snyk client API, then I think we'll be able to do everything that we want.

Ping @tkadlec

[paulirish]

Without explicit remediation advice in the JSON we can still do something similar. We can use the semver lib to interpret the affected version ranges. From that we can calculate the highest affected version.

That means we couldn't necessarily say "You need to upgrade to version 3 or higher" but we could say something like "You gotta upgrade this lib to a version over 2.6.1".

Good second/third bug here. :) @benschwarz you interested in taking this?

[benschwarz]

Yep. Leaving it on my list

[evenstensberg]

@benschwarz if you're full I can take it

[3Q5278]

good

[connorjclark]

@benschwarz @evenstensberg any takers? :)

[evenstensberg]

Could work on this in June. Wrapping up some other work first.

[evenstensberg]

I'll take it

[evenstensberg]

I've asked a guy that works at Snyk for any help regarding getting that prop from the vuln db, but what I think we could do, is to add the fixedIn property from the vulnDB and use that to figure out which actions to take. That prop is already present in the vuln db, along with semver ranges for unaffected versions.

Edit: Fixed in is our source of truth. Has a prop that indicates what we should output disregarding semver ranges.

Should I go for that?

[patrickhulce]

Sounds great to me @evenstensberg! In fact, I actually think if we don't have any fixedIn value we shouldn't surface the vuln at all to prevent cases like #8409 #8748

[evenstensberg]

Yup. @lirantal from snyk is following up on this

[lirantal]

hey fellas, @evenstensberg @patrickhulce 👋
notice that we (@aviadatsnyk) added a fixedIn field to the clientside.json file we're sending you so you should be able to use that to get more insights out in terms of available fixed version.

Notice that to get the data you probably need to tweak the pruned data here to include it https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/scripts/cleanup-vuln-snapshot.js#L56 ?