Give your feedback about the osvVulnerabilityAlerts experimental feature

[HonkingGoose]

Tell us how you like the new osvVulnerabilityAlerts experimental feature. What works for you, what doesn't work for you? Do you see anything we could improve?

Let us know what you think! 😉

[jwnmulder]

It's a really cool feature! Especially when adding a label like 'security' it gives you a nice cross repository overview.

One improvement that would be welcome is the ability to have more control over major dependency updates and the 'dependencyDashboardApproval' flag. Right now, this configuration has no effect when fixedVersion reflects a major upgrade

  "major": {
    "dependencyDashboardApproval": true
  }

Example issue: GHSA-r8f7-9pfq-mjmv

Another improvement / feature request. Would it be possible to reflect the security risk in the PR title? Something like a Low/Medium/High/Critical suffix?

[setchy]

We enabled this feature yesterday and it's really really cool!

Another improvement / feature request. Would it be possible to reflect the security risk in the PR title? Something like a Low/Medium/High/Critical suffix?

+1 - this would be an great enhancement!

[viceice]

i don't like the idea to enable approval for security updates. to easy to miss those updates.

[jwnmulder]

i don't like the idea to enable approval for security updates. to easy to miss those updates.

That does make sense thinking about it.

My first reaction was to initially disable it as some developers where surprised. Seeing the dependencyDashboardApproval parameter as documented on https://docs.renovatebot.com/configuration-options/#vulnerabilityalerts gave me the impression it was supported.

Maybe related. Could it be that custom packages rules where allowedVersions is used are ignored in case of a vulnerability? As an example, a maven package named org.codehaus.jackson:jackson-mapper-asl is being updated from 1.9.9 to 1.9.14.jdk17-redhat-00001 while our package rules exclude versions that include 'redhat'.

[Churro]

Another improvement / feature request. Would it be possible to reflect the security risk in the PR title? Something like a Low/Medium/High/Critical suffix?

Not sure about this. Depending on who reports vulns, initially they are often overrated (esp. when found via Bug Bounty programs). Over time, GHSA and other sources react on community feedback, adapt the score and renovate will silently also update the PR description. Changing the PR title would cause additional noise by renovate closing and reopeing PRs.

[rarkins]

Relevant to some of the discussions:

renovate/lib/config/options/index.ts

Lines 1653 to 1672 in e87af92

	{
	name: 'vulnerabilityAlerts',
	description:
	'Config to apply when a PR is needed due to a vulnerability in the existing package version.',
	type: 'object',
	default: {
	groupName: null,
	schedule: [],
	dependencyDashboardApproval: false,
	stabilityDays: 0,
	rangeStrategy: 'update-lockfile',
	commitMessageSuffix: '[SECURITY]',
	branchTopic: `{{{datasource}}}-{{{depName}}}-vulnerability`,
	prCreation: 'immediate',
	},
	mergeable: true,
	cli: false,
	env: false,
	supportedPlatforms: ['github'],
	},

I'm not aware of anyone modifying that in the past, but it was intended to be possible.

It says github-only there, but I think that's only used for documentation.

[rarkins]

Changing the PR title would cause additional noise by renovate closing and reopeing PRs.

Only if the first PR was closed. In this case you'd get a replacement with the new severity. Otherwise, you would see the title updated in-placed without closing/opening.

[viceice]

saw a strange security PR autoclose

[Churro]

saw a strange security PR autoclose

@viceice, you've hit an edge case that occurs with only 0.58% (83 / 14311) of OSV vulnerabilities (congrats on that 😉):

• jquery 2.2.4 is also vulnerable to GHSA-gxr4-xjj5-5px2 since version 1.2, which the advisory mistakenly lists as semver.
• While sorting OSV events to check if affected, the sortVersions method in renovate's semver versioning API is fed 1.2 and expectedly throws an exception.
• The exception causes renovate to skip post-processing of package rules, eventually resulting in allowedVersions: '3.0.0' being highest, instead of version 3.4.0 (after correct package rule sorting actually 3.5.0).
• The order in which different vulns are processed is not deterministic, so depending on what gets out of the DB first, the issue occurs sooner or later, after already having composed a few package rules with findings.

PR #20512 intends to corrects this. Note that renovate still depends on semantically valid versions for comparisons. Hence, it will still not flag GHSA-gxr4-xjj5-5px2 for jquery 2.2.4, although affected. IMHO such cases should rather be corrected in the OSV advisory itself (1.2 -> 1.2.0), rather than in renovate by trying workarounds like semver-coerced versioning.

[andrewpollock]

Hi @Churro I'm with the OSV team, is there an issue with GHSA-gxr4-xjj5-5px2 that needs to be corrected? I totally agree that we should be fixing the underlying data rather than downstream consumers doing contortions to correct for it.

[Churro]

@andrewpollock, thanks for reaching out. It seems to me there is indeed an issue with GHSA-gxr4-xjj5-5px2:

• GHSA-gxr4-xjj5-5px2 in the GitHub advisory DB lists version 1.2 with versioning ECOSYSTEM. This should be correct, as 1.2 was in fact a valid JQuery release, still before they decided to adopt semantic versioning.
• GHSA-gxr4-xjj5-5px2 in the OSV DB shows up with SEMVER, although the Introduced version 1.2 itself is not semver-compliant. My understanding is that the OSV importer infers the versioning based on the package ecosystem only, so npm -> semver
• The OSV schema foresees only actual semantic versions to be used with "type": "SEMVER". Conversely, this means the affected entry of GHSA-gxr4-xjj5-5px2 violates this constraint.

I ran a check across all OSV datasources that renovate uses and extracted all entries with versions that are listed as SEMVER but are not actually semantic versions. You can find the list here.

In some cases, the GitHub advisories can be corrected. For all others, OSV could tackle this by adding a trailing .0 or by importing versions with type ECOSYSTEM unchanged. I tend to think the former would the better option, as it would allow OSV to compile a list of affected versions. Also, assuming a package belongs to ecosystem Go and versioning is specified to be ecosystem-specific, then any OSV advisory parser would reasonably interpret the version again as semver - unless a more tolerant fallback is enforced.

[andrewpollock]

Hey @Churro you're a champion! Thanks so much for doing some of the additional legwork to identify problematic records, this directly helps us maintain a high standard of quality in OSV data.

FYI we're working on doing stricter validation at record import time as part of google/osv.dev#771 (and subsequently surfacing import issues to our data sources)

We've flagged these records with GitHub to determine the best course of action. We would much rather see OSV source data be correct (at the source) than try to paper over it by having OSV.dev do creative interpolation, as you've suggested as one of the options.

[viceice]

@Churro thanks for finding the cause ❤️ can you upstream the version fix too?

[vquie]

I really love the idea of this vulnerability alert. We also had this issue with flapping merge requests in hosted gitlab. All merge requests created by this feature were autoclosed several times. Since we have just started using renovate on that repository it didn't bother that much. I noticed it though.

Another thing I noticed was the github ratelimit in this case. We authenticate to github for the release notes already with a personal token, but it seems that toen is not used for these alert.
Error message:

"data": {
  "message": "API rate limit exceeded for xx.xx.xx.xx. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
  "documentation_url": "https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"
}

Could this be the reason for the flip flopping? If yes, how can I make renovate use the github token for these calls?

[kkom]

We've been running into this as well – currently maybe 20% of Renovate runs succeed. On balance, it's nice to get vulnerability notifications, but it would be better if Renovate went back to running regularly (when the API rate limit is exceeded, Renovate doesn't do anything - no creating or rebasing of PRs either I believe).

[Churro]

Did you define a Github token (see here)? Vulnerability alerts now also use that token, so that you don't hit the rate limit as fast as before but it may still happen, of course ...

[kkom]

Sorry for the slow response @Churro – I am travelling at the moment.

I didn't read the original thread carefully. I am actually on GitHub.com and I'm using the cloud-hosted renovate through Mend.io – I see frequent (~90% of attempts) errors both for personal repositories under @kkom and for work ones under @isometric.

[Churro]

This may be related to #22502 then.

[Churro]

@vquie, flapping PRs are most likely related to hitting the API limit. This has been addressed with renovatebot/osv-offline#230, which found its way into renovate 34.142.0. Can you please check if the issue is gone after updating renovate?

[vquie]

Thanks @Churro . I just updated to the latest helm release and will monitor it.

[Churro]

Currently, renovate raises no vulnerability fix PRs for dependencies that are disabled explicitly or by using a preset like:disableMajorUpdates. If a security fix is only provided via major update (take guava as an example), users would never take notice of using a vulnerable dependency.

Proposition: Add an opt-in config flag (= disabled by default) to vulnerabilityAlerts named vulnerabilityAlertsForDisabled (better naming proposals welcome) that raises vulnerability fix PRs even for disabled deps.

Any thoughts on that? Let me know if this is something you'd also find useful 👍 or not 👎

[Churro]

Update: Found out that this already possible, even without adding a new config option. Just specify:

"osvVulnerabilityAlerts": true,
"vulnerabilityAlerts": {
  "enabled": true
}

The "enabled": true option force-enables dependencies in case if disabled but vulnerabilities are found.

[gaeljw]

Not sure if it's really an issue but I've observed the following message in logs for a project with NPM manager:

Skipping vulnerability lookup for package lodash due to unsupported version ^4.17.21

Is the unsupported version because of the ^ character and the fact the version is not fixed?

[Churro]

Correct, the ^ leaves it open which minor or patch version is used. The version in use can but doesn't necessarily need to be 4.17.21. Most likely to happen if no package-lock.json file is committed.

[gaeljw]

Pretty sure it happened on a project with a package-lock.json file.

[mdesanti]

What would be the correct way of making renovate still open an MR even if the version is pinned with ^?

I have a project which uses "xlsx": "^0.18.5" and in the revovate logs I see Skipping vulnerability lookup for package xlsx due to unsupported version ^0.18.5

@gaeljw did you manage to solve this?

[samuelstadler]

When using osvVulnerabilityAlerts we notice that indirect go dependencies are updated. However the documentation states that only direct dependencies will get vulnerability alerts.

For example we have this renovate config:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "osvVulnerabilityAlerts": true,
  "vulnerabilityAlerts": {
      "enabled": true
  }
}

a GitHub Token and a go.mod file like

module example.com/m

go 1.21

require (
  github.com/argoproj/argo-cd/v2 v2.3.17
  k8s.io/kubernetes v1.24.2 // indirect
)

If we now run renovate we get security updates for k8s.io/kubernetes but since it is an indirect dependency that should not happen. When we set osvVulnerabilityAlerts to false we do not get the PR.

[rarkins]

This sounds like a feature, not a bug

[wolf-michl]

This sounds like a feature, not a bug

The doumentation states though:

You will only get OSV-based vulnerability alerts for direct dependencies.

It still creates updates for indirect dependencies, even if no direct dependency is being updated, which would lead to an update of the indirect dependency.

This leads to unwanted behaviour:
We get updates of indirect dependencies, even if the direct dependency leading to the indirect dependency is not being updated. This could then introduce breaking behaviour.

The default of not updating indirect dependencies is not being taken into account here, which seems to be the root cause for this issue.

[rarkins]

The documentation can be updated/fixed, and you are welcome to submit a PR if it's urgent to you.

The gomod manager is an exception within Renovate where Renovate supports updating of indirect dependencies too, including for Remediations. In Go, dependencies to not pin exact version of indirect dependencies and must be able to work with any future version of the dependency in the same major release too. Any reference in a go.mod such as "1.1.0" implicitly means ">=1.1.0 <2.0.0" and newer versions of 1.x must be backwards compatible to prevent breaking behavior.

Please separate this topic off into a new config help discussion with a reproduction repo demonstrating the remediation of an indirect dependency. It's possible that remediation of indirect dependencies can be disabled via existing config options.

[samuelstadler]

Sorry for the late response but in the logs we see this:

{
    "datasource": "go",
    "depType": "indirect",
    "depName": "k8s.io/kubernetes",
    "currentValue": "v1.24.2",
    "enabled": false,
    "managerData": {
        "multiLine": true,
        "lineNumber": 199
    },
    "updates": [
        {
            "bucket": "non-major",
            "newVersion": "v1.27.16",
            "newValue": "v1.27.16",
            "releaseTimestamp": "2024-07-17T01:44:24.000Z",
            "newMajor": 1,
            "newMinor": 27,
            "newPatch": 16,
            "updateType": "minor",
            "branchName": "renovate/go-k8s.io-kubernetes-vulnerability"
        }
    ],
    "packageName": "k8s.io/kubernetes",
    "versioning": "semver",
    "warnings": [],
    "sourceUrl": "https://github.com/kubernetes/kubernetes",
    "currentVersion": "v1.24.2",
    "currentVersionTimestamp": "2022-06-15T14:14:10.000Z",
    "isSingleVersion": true,
    "fixedVersion": "v1.24.2"
}

so "enabled": false and we still get the a PR because of osvVulnerabilityAlerts is enabled. Just for our understanding if osvVulnerabilityAlerts is enabled then the enabled flag is ignored? If not than I can create a config help discussion 🙂

[rarkins]

If you disable a dependency by config then it's not intended that package alerts would reenable it. If you can reproduce it in a public repo then please create a new discussion

[aarongoldenthal]

Is there a way to set rangeStrategy to something other than update-lockfile for OSV vulnerabilities? It appears not, for example with config:

  "packageRules": [
    {
      "matchManagers": ["npm"],
      "rangeStrategy": "bump",
      "osvVulnerabilityAlerts": true
    }
  ]

...and a package with "dependencies": { "axios": "^1.7.3" }, the lockfile is updated first for the vulnerability, then the next pass renovate applies the rangeStrategy and updates the package to "dependencies": { "axios": "^1.7.4" }. It works, but would be helpful if the rangeStrategy were respected initially so it didn't have to be a two step process.

[rarkins]

@aarongoldenthal please raise that as a separate "suggest an idea" discussion

[aarongoldenthal]

@aarongoldenthal please raise that as a separate "suggest an idea" discussion

Raised the proposal at #30854

[Goltergaul]

I like the feature but we are running into issues in our setup. We use bundle-audit in our CI to check if the dependencies include known vulnerabilities. This is for ruby btw. Bundle-audit checks also indirect dependencies, which totally makes sense. Unfortunately renovate does not create prs for these. According to the documentation this is on purpose. However it would be nice if it would also update indirect dependencies, as those are equally dangerous imo.

Using bundler those can be updated also if they are not part of the Gemfile. However you cannot specify a specific target version. but e.g. renovate could try to run bundle update <indirect-dependency> This might actually update something or not. In case this does not update anything, renovate could add the gem to the gemfile maybe, even though bundle update will then probably fail. But as a dev i would then at least have a pr that i can fix and would be aware of the issue.

Edit: Thinking about it more I think this could create kind of a loop or prs that update something but not fix the vulnerability. renovate would need to extract the version of the indirect dependenc from the Gemfile.lock to actually verify that a safe version is used. Not sure how straight forward that is

[s00hyun]

Hi, I would like to propose a feature request.
As a Gerrit user, osvVulnerabilityAlerts is really useful to get notified of security updates. However, it would be great if Renovate can open only certain level(s) of security updates by configuration, probably by CVSS Severity Level (Low/Medium/High/Critical).
A similar idea was already mentioned before at #20542 (comment).

On the feature side I think it would be really benefitial to be able to filter out certain "levels" but it looks like there is no such thing in the OSV schema, so maybe that's why it's not possible?

[marcelser]

Actually the 'severity' field is part of the schema, but it's often not set. The question is how should renovate handle the ones without 'severity' rating. There's even an option to set different severities for different versions and then the toplevel 'severity' should not be set. Not too easy to automate it.

[ggjulio]

Works fine so far for us.

For critical cve we need to back port on older versions.
It would be nice to open PRs on a list of maintained branches without actually enabling renovate on theses branches.
Maybe when the score >= N to avoid noise.

Don't know if we can already do that with some workaround in the config.

[HonkingGoose]

Hi @ggjulio, 👋

I created a config that I think will do what you want. Please read (and subscribe) to this discsusion:

• Security updates for `backport` branches, and normal behavior for "default" branch #31943

[adam-moss]

We've been using this for over a year now and get a lot of value from it.

One additional thing we'd like to be able to do is add the vuln id's as labels to the MRs. Does anyone know if this is possible?

[highlandcowfun1122]

"Great feature! The osvVulnerabilityAlerts provide valuable insights, but it would be helpful to have more detailed filtering options for different severity levels. Also, integrating notifications for high-priority alerts could make it even more useful. Keep up the good work!"
https://highlandcowfun.com/how-much-land-do-highland-mini-cows-need/

[felipecrs]

It looks like security updates disregard groups. Is this by design? I don't see how this would be a good thing.

[rarkins]

Yes, it's by design. It's not ideal, but grouping caused more problems

[felipecrs]

I see. Maybe an option to control that behavior would be nice. This is the biggest reason why I disabled osvVulnerabilityAlerts.

[MTRNord]

Hi we are currently setting this up and are wondering: Is this affected by minimumReleaseAge?

  npm: {
    minimumReleaseAge: '14 days',
  },

This is what he have set at top level and the idea is to delay the "normal" updates but we would like CVE updates to skip the waiting list so I wonder how these options interact. I didnt find the code path sadly for this so I wasnt able to figure it out myself.

[Marcel-Nordeck]

Further investigating I assume

renovate/lib/workers/repository/update/branch/index.ts

Lines 358 to 365 in 4be24ab

	if (
	config.upgrades.some(
	(upgrade) =>
	(is.nonEmptyString(upgrade.minimumReleaseAge) &&
	is.nonEmptyString(upgrade.releaseTimestamp)) ||
	isActiveConfidenceLevel(upgrade.minimumConfidence!),
	)
	) {

is the check for this time but it doesnt except the security updates via isVulnerabilityAlert like it does in other parts of that logic.

I am guessing this means that security updates also have to wait?

[Davidvaquer]

It's a very cool feature!

[wurstbrot]

Feature Request: SBOM-based Container Vulnerability Scanning

Problem Statement

Currently, Renovate's osvVulnerabilityAlerts feature only supports specific datasources (npm, maven, pypi, etc.) but excludes the docker datasource. This creates a significant gap for teams managing container-based applications, as they cannot leverage Renovate's vulnerability intelligence for third-party container images - precisely where many critical vulnerabilities exist.

Proposed Solution: SBOM Integration

Core Concept: Enable Renovate to consume Software Bills of Materials (SBOMs) (for container images, but not limited to containers), treating them as dependency manifests similar to pom.xml or requirements.txt.
This is slight different then for package managers, as renovate normally just updates the package manager file. In this case, renovate would need to create a separate PR if a vulnerability is found, but for the original package (e.g. kustomize, Dockerfile, helm) manager and not within the SBOM.
Maybe there are also even better ideas how to do it.

Implementation Phases

Phase 1: Repository-based SBOMs (MVP)

• File Convention: sboms/{image-name}-{version}.{format}.json

  • Example: sboms/nginx-1.25.3.cyclonedx.json
  • Example: sboms/postgres-15.4.spdx.json

• Supported Formats: CycloneDX, SPDX

• Discovery: Renovate scans for SBOM in the folder sboms (configureable) files when processing Dockerfiles

• Integration: Parse SBOM packages and query OSV database

Phase 2: External SBOM Sources

To be defined

Configuration Example

{
  "osvVulnerabilityAlerts": true,
  "sbom": {
    "enabled": true,
    "sources": [
      {
        "type": "repository",
        "path": "sboms/"
      }
    ]
  }
}

[andreilgeorgescu]

Is this redundant/conflicting with vulnerabilityAlerts?

[mikaello]

It may seem like vulnerabilityAlerts is a GitHub-specific feature (using Dependabot alerts from the dependency graph), while osvVulnerabilityAlerts is platform-independent and works on any git host by querying the OSV database (through the renovatebot/osv-offline project).

But yes, this distinction should be better documented, as it's currently a bit unclear and open to interpretation. And it is unclear how they operate when both are enabled.

[mxey]

The documentation for this feature says:

You will only get OSV-based vulnerability alerts for direct dependencies.

However, from my Renovate debug output, it looks like it does indeed trigger the config effects of vulnerabilityAlerts for this indirect go.mod dependency:

 {
   "datasource": "go",
   "depType": "indirect",
   "depName": "github.com/docker/docker",
   "currentValue": "v27.5.1+incompatible",
   "enabled": false,
   "managerData": {"multiLine": true, "lineNumber": 17},
   "updates": [
     {
       "bucket": "major",
       "newVersion": "v28.0.0+incompatible",
       "newValue": "v28.0.0+incompatible",
       "releaseTimestamp": "2025-02-19T21:53:46.000Z",
       "newVersionAgeInDays": 281,
       "newMajor": 28,
       "newMinor": 0,
       "newPatch": 0,
       "updateType": "major",
       "isBreaking": true,
       "libYears": 0.07923693556570269,
       "branchName": "renovate/go-github.com-docker-docker-vulnerability"
     }
   ],
   "packageName": "github.com/docker/docker",
   "versioning": "semver",
   "warnings": [],
   "sourceUrl": "https://github.com/docker/docker",
   "currentVersion": "v27.5.1+incompatible",
   "currentVersionTimestamp": "2025-01-21T23:46:50.000Z",
   "currentVersionAgeInDays": 310,
   "isSingleVersion": true,
   "fixedVersion": "v27.5.1+incompatible"
 },

You can see that branchName contains vulnerability here. So is the documentation simply incorrect/outdated?

[mueslo]

Is there some possibility for more fine-grained control of automerge for vulnerabilityAlerts? E.g. automerge only on patch-level updateType? I have not managed to find any sort of packageRule with thich I could determine if an update is related to a vulnerabilityAlert.

Am I missing something? Or maybe it's possible via matchJsonata? But then it's unclear what the object that I'm matching against even contains. Any ideas?

[is-ahmed]

Hi, does anyone know if it's possible to configure Renovate to only make security PRs, but only for minor or patch updates? I tried using both the security:only-security-updates and :disableMajorUpdates presets, but it still seems to open PRs for major updates.

EDIT: Sorry forgot to mention, but I'm using self-hosted GitLab community edition, not GitHub.