Snyk vulnerability range for unfixed vulnerabilities

[amotzhoshen]

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 #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]

#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]

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]

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]

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]

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
}