search

GoogleChrome / lighthouse

Automated auditing, performance metrics, and best practices for the web.
https://developer.chrome.com/docs/lighthouse/overview/
Apache License 2.0
28.31k stars 9.36k forks source link

Snyk vulnerability range for unfixed vulnerabilities #14168

Closed amotzhoshen closed 2 years ago

amotzhoshen commented 2 years ago

Summary

Hi 👋 My name is Amotz, working for Snyk. I wanted to update you that we are revisiting our current method for providing ranges for unfixed vulnerabilities, as part of a standardization effort we are doing in this area. See https://github.com/GoogleChrome/lighthouse/issues/8748 for context. In cases of unfixed vulnerabilities, we'd like to provide * as the range, and, if necessary, have it resolved on LH side to a specific version range (e.g. <=x.y.z), instead of resolving it on our side. We still don't have clear timeline for this, but wanted to give you heads up and start a discussion.

connorjclark commented 2 years ago

9308 (more direct link to context)

We wouldn't be able to confidently determine the correct "latest version" that snyk is considering ourselves in any post process step... (assumption: there is significant delay between the calculation of these constraints, the opening of PRs, and any post processing we might do as a result). Maybe if we are provided a timestamp for when a synk database was made we could use npm view <package> time to match to the correct verison?

Any way "latest package version as of this snyk db snapshot" could be kept as extra data in a new field?

connorjclark commented 2 years ago

For us to discuss: As far as not being able to use a live-snapshot of snyk, that is still a constraint we have (certainly in DevTools and PSI), but perhaps we could be more flexible in CLI?

connorjclark commented 2 years ago

We still don't have clear timeline for this, but wanted to give you heads up and start a discussion.

Looking at the latest snyk PR, it seems this has already taken effect? https://github.com/GoogleChrome/lighthouse/pull/14169/files#diff-2748424e6850e5ce49d2339a9d6e7d96a5f286e3c404618e0ef54e5c89d62055R7

amotzhoshen commented 2 years ago

Looking at the latest snyk PR, it seems this has already taken effect?

We haven't made any change yet in this area. Our current post-processing logic only handles * ranges, so it looks like there's already an existing gap here.

amotzhoshen commented 2 years ago

Maybe if we are provided a timestamp for when a synk database was made we could use npm view <package> time to match to the correct verison?

This is something we could do. We can add another metadata file to the PR, and have something like this:

{
   "snapshot_timestamp" : "2020-07-21T16:54:45.522247Z",
   "md5_hash" :"some_md5_hash"  # can be used to verify the correct snapshot is used in post processing
}