feat(vulnerabilities): add feature-flagged support for OSV

[Churro]

Changes

Adds integration for vulnerability alerts based on data renovate finds in the osv.dev database. This PR continues the work @JamieMagee initiated in #15159 and further augments it by addressing previous TODOs, test coverage and support for a larger set of ecosystems and versioning schemes.

There are 3 building blocks realized in this PR:

• Check if packages are affected by vulnerabilities
  • Done by implementing the evaluation algorithm, as included in the OSV schema
    • The intention here is also to make it easier maintainable in renovate in case of future changes
    • Side-note: The check for limit is missing on purpose, as it is only used with "versions" that are Git hashes
• If vulnerable, find a version that remediates the vulnerability
• Create a package rule that introduces version constraints and vulnerability information in PR notes
  • As OSV entries describe the severity only using the CVSS vector, vuln-vects is used to infer the CVSS base score.

Inline with #15159, the feature is opt-in and needs to be enabled using the osvVulnerabilityAlerts config flag.

Context

• Use GitHub SecurityVulnerabilities regardless of platform #6562
• feat(vulnerabilities): add feature-flagged support for osv #15159

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

Test repos (split because GH enforces secondary rate limits when creating > 10 PRs):

• https://github.com/renovate-demo/6562-vulndemo/pulls
  • enabledManagers: ['bundler', 'cargo', 'composer', 'gomod', 'gradle', 'maven']
• https://github.com/renovate-demo/6562-vulndemo2/pulls
  • enabledManagers: ['mix', 'npm', 'nuget', 'pip_requirements', 'poetry']

[secustor]

Really like to see this implemented.

[JamieMagee]

Thanks for getting this across the line 🎉 Can't wait to see this in Renovate.

[viceice]

otherwise LGTM.

[renovate-release]

🎉 This PR is included in version 34.129.0 🎉

The release is available on:

• GitHub release
• 34.129.0

Your semantic-release bot 📦🚀

[icanhazstring]

@JamieMagee @Churro

You mentioned testing it with composer.
The documentation however states only the following:

crate
go
hex
maven
npm
nuget
packagist
pypi
rubygems

So, is it even getting information for composer now?

[viceice]

packagist is the composer datasource 😉

[icanhazstring]

packagist is the composer datasource 😉

Haha lol. Yes ofc. I totally overlooked that one. Nevermind. Maybe my brain was not functioning well at the time 😂🙈

[HonkingGoose]

@rarkins and @JamieMagee

The docs for osvVulnerabilityAlerts has this admonition:

This feature is flagged as experimental
Experimental features might be changed or even removed at any time.
To track this feature visit the following GitHub issue #6562.

The admonition links to this issue, which we resolved. The source for the admonition:

renovate/lib/config/options/index.ts

Lines 1673 to 1680 in 3eb96c9

	{
	name: 'osvVulnerabilityAlerts',
	description: 'Use vulnerability alerts from `osv.dev`.',
	type: 'boolean',
	default: false,
	experimental: true,
	experimentalIssues: [6562],
	},

Should we drop these lines?

-    experimental: true,
-    experimentalIssues: [6562],

[JamieMagee]

@HonkingGoose I'd still consider the feature experimental for a little while, and would like to keep the feature flag. What about opening a new issue to centralise feedback collection?

[icanhazstring]

@JamieMagee If you mean "feature flag". Does it mean it has to be set to true while vulnerabilityAlerts have to be enabled as well?

Because I can't figure that out from the docs.

[JamieMagee]

@icanhazstring this feature only requires osvVulnerabilityAlerts to be set to true. The vulnerabilityAlerts option controls GitHub-only vulnerability alerts. I expect we'll merge them both under the vulnerabilityAlerts option in the near future.

[HonkingGoose]

@JamieMagee If you mean "feature flag". Does it mean it has to be set to true while vulnerabilityAlerts have to be enabled as well?

The "feature flag" comment means this experimental: true flag in our code:

 { 
   name: 'osvVulnerabilityAlerts', 
   description: 'Use vulnerability alerts from `osv.dev`.', 
   type: 'boolean', 
   default: false, 
   experimental: true, // <--- This is the "feature flag"
   experimentalIssues: [6562],
 }, 

We look for the experimental: true flag in our docs generating code to generate the warning message that the feature is "flagged as experimental". This way the code and the docs always match.