Snyk vulnerability range for unfixed vulnerabilities

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]

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

[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
}