feat: remediate to greater than or equal versions for github alerts

[rarkins]

Changes

Adds new field vulnerabilityFixVersion to use in place of allowedVersions for vulnerability rules.

Context

When we (currently) use allowedVersions for vulnerability fixes then it means we override/break any allowedVersions rules which users have configured.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

Another reason for this refactor was to be able to enable #31395

[rarkins]

@Churro I didn't make the changes to OSV alerts yet. This functionality is intended to work side-by-side and allow a later refactoring

[Churro]

Since matchCurrentVersion also matches version or range, for consistency I'd advocate calling the field vulnerabilityFixVersion. With vulnerabilityFix I'm somewhat lacking the "what it is"-suffix.

I tested this PR on https://github.com/renovate-demo/31393-github-alerts/pulls and the result of PRs created is basically identical to #29600 and the reproducer in https://github.com/renovate-demo/29600-github-vuln-alerts/pulls.

[Churro]

I also tested it with OSV, changing only all occurrences of allowedVersions to vulnerabilityFix. The PR output is identical to the ones raised via GitHub alerts (https://github.com/renovate-demo/31393-osv-alerts/pulls) but the log included a warning:

DEBUG: Vulnerability GHSA-g3vv-g2j5-45f2 affects github.com/ipld/go-codec-dagpb v1.3.0 (repository=renovate-demo/31393-osv-alerts)
DEBUG: Setting allowed version >= 1.3.1 to fix vulnerability GHSA-967g-cjx4-h7j6 in github.com/ipld/go-codec-dagpb v1.3.0 (repository=renovate-demo/31393-osv-alerts)

 WARN: vulnerabilityFix is not valid (repository=renovate-demo/31393-osv-alerts)
       "vulnerabilityFix": ">= 1.3.1",
       "packageName": "github.com/ipld/go-codec-dagpb"
DEBUG: Vulnerability alert found: limiting results to a single release (repository=renovate-demo/31393-osv-alerts)
       "filteredReleases": [{"version": "v1.3.1", "releaseTimestamp": "2022-03-16T09:19:38.000Z"}]

The issue is that go uses semver and semver.isValid(">= 1.3.1") is false. It worked with allowedVersions due to this fallback:

renovate/lib/workers/repository/process/lookup/filter.ts

Lines 78 to 95 in ffe2b4c

	} else if (
	config.versioning !== npmVersioning.id &&
	semver.validRange(allowedVersions)
	) {
	logger.debug(
	{ depName: config.depName },
	'Falling back to npm semver syntax for allowedVersions',
	);
	filteredReleases = filteredReleases.filter((r) =>
	semver.satisfies(
	semver.valid(r.version)
	? r.version
	: /* istanbul ignore next: not reachable, but it's safer to preserve it */ semver.coerce(
	r.version,
	)!,
	allowedVersions,
	),
	);

However, this shouldn't be an issue with GitHub alerts, as they always return a single version. Just mentioning it with regards to porting this change also to OSV. If OSV advisories use "last affected", it will inevitably result in a constraint like "> 1.2.3".

[rarkins]

@Churro regarding using OSV, can we return vulnerabilityFixVersion as a single version? The warning you describe above is due to Renovate go versioning not having the concept of range syntax plus the lack of semver fallback you already identified. The thing is that in go versioning, ">= 1.3.1" is unnecessary anyway - "1.3.1" is essentially the same thing (although technically it's like ^1.3.1 and does not go past 2.0.0).

[Churro]

@Churro regarding using OSV, can we return vulnerabilityFixVersion as a single version? The warning you describe above is due to Renovate go versioning not having the concept of range syntax plus the lack of semver fallback you already identified. The thing is that in go versioning, ">= 1.3.1" is unnecessary anyway - "1.3.1" is essentially the same thing (although technically it's like ^1.3.1 and does not go past 2.0.0).

With OSV, it depends which fix info is provided in the advisory:

• with explicit fix version -> same versioning.isGreaterThan() check will work as for first_patched_version in GH alerts. Of course, after reworking the impl to no longer build constraints like >=.
• with only a "last affected" version, there will be a constraint like > 1.3.1. Not >= but really >, which is why specifying "1.3.1" only wouldn't be enough. In that case, the same warning would show up since semver.valid("> 1.3.1") is also false.

A workaround to omit the fallback would be to use npmVersioning for go (and probably others with semver), since it also has support for ranges. Probably there are downsides to that approach that I'm not aware of.

[rarkins]

@Churro let's discuss that later on then. This PR already has more logic than it needs to work here, i.e. the support for ranges is unnecessary for the github alerts. If OSV requires special treatment then I'd prefer to do it there

[viceice]

otherwise LGTM

[viceice]

we should split to smaller functions in a follow up PR

[renovate-release]

🎉 This PR is included in version 38.88.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 38.88.0

Your semantic-release bot 📦🚀