What upper vulnerable version should be set in reports?

In reports that we triage, we have had it as a standard so far to specify the latest version that exists at the time of the report as the upper bound.

So if library coolmodule had a report for affecting versions <= 1.0.0 and its current latest release is 1.0.0, we’d set in the report:

vulnerable_versions: '<= 1.0.0'

Pros

forgiving approach which sets an upper limit to what the report has triaged

Cons

newer versions coming out won’t be considered vulnerable even though this might actually be the case

See example use-case https://github.com/nodejs/security-wg/pull/513/files where harp is triaged for vulnerable_versions <=0.29.0 but soon after the report was triaged, versions 0.30.0 released, and is probably still vulnerable.

What should we do?

1. We can specify a vulnerable_versions: '*' to account for everything when no fixes that we know of are applied.
2. Keep the existing forgiving upper limit
3. ?

[sam-github]

I find option 1 attractive. It puts the onus on us to do the initial eval, but once the report is accepted, we shouldn’t have to do a polling loop on every package with an open vuln, checking if a more recent one exists, and updating the vuln DB if it is still vulnerable. Setting an open-ended max puts the onus back on the package maintainers to notify us when a fix is made, preferably with a PR that updates the DB.

@lirantal do you have a preference among your options?

[sam-github]

Discussed at #541 , removing from agenda (but please add back if it should be discussed again).