Lighthouse: Add Remediation advice to each library vuln
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
benschwarz
All 11 comments
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?
paulirish
on 13 Oct 2017
Yep. Leaving it on my list
benschwarz
on 17 Oct 2017
@benschwarz if you're full I can take it
evenstensberg
on 31 Oct 2018
good
3Q5278
on 23 Feb 2019
@benschwarz @evenstensberg any takers? :)
connorjclark
on 20 May 2019
Could work on this in June. Wrapping up some other work first.
evenstensberg
on 21 May 2019
I'll take it
evenstensberg
on 27 May 2019
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?
evenstensberg
on 27 May 2019
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
patrickhulce
on 27 May 2019
Yup. @lirantal from snyk is following up on this
evenstensberg
on 28 May 2019
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 ?
lirantal
on 16 Sep 2019
Related issues
devrsi0n
·
3Comments
codepodu
·
3Comments
workjalexanderfox
·
3Comments
etelai
·
3Comments
timj2
·
3Comments
Most helpful comment
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
fixedInproperty 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?