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?

[goodjun]

Does this feature support GitLab?

[viceice]

yes, all supported renovate platforms

[derekmurawsky]

Is there a way to group by vulnerability severity? Or create a group with just vulnerabilities?

Example: Many places have a policy of "address critical vulnerabilities within X time period". It would be very beneficial to be able to group updates by vulnerability severity to aid in triage and prioritization.

[setchy]

You might be able to achieve this by using the vulnerabilitySeverity template field within the group name

Something like this perhaps (haven't validated personally) 🤞

{ 
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
 "extends": [ "config:base" ], 
  "osvVulnerabilityAlerts": true, 
  "vulnerabilityAlerts": { 
    "groupName": "[SECURITY-{{{vulnerabilitySeverity}}}]"
  }
} 

[DenisSlack]

Hello!
Great feature!
Is it possible to use a local copy of the OSV vulnerability database or an OSV mirror?

[Churro]

Yes, you can find the data renovate uses here: https://github.com/renovatebot/osv-offline/releases/

[DenisSlack]

Thanks for the answer!

I also wanted to know if it is possible to preload the OSV vulnerability database for further launch of the renovate image without an Internet connection

[Churro]

This was discussed lately but not taken into further consideration for now, see renovatebot/osv-offline#88

[philippe-granet]

I have a workaround, see my comment: #20542 (reply in thread)

[dubzzz]

The feature is really cool 🥳

One thing that could be interesting given many tools use this figure as a KPI would be to also support indirect dependencies for npm projects (dependabot does that). In other words, support vulnerabilities coming from indirect dependencies listed within lock files and then be able to bump whatever needed to drop that potential issue would be awesome (maybe not by default but at least provide one way to support that).

[tobias-lippert]

We've recently activated this feature for our project using maven and npm. Since we rely a lot on spring-boot-starters and usually transitive dependencies are vulnerable, it would be beneficial for us if transitive dependencies for maven are supported. Are there any plans to support this in the future?

[dubzzz]

Same need for NPM dependencies

[HonkingGoose]

These issues seem somewhat related:

• Support npmv7 (lock file v2) for transitiveRemediation #10371
• Transitive remediation: try to remove blocking parent #8976
• Transitive remediation: document when a dependency is *removed* #8975
• Transitive Remediation: capture when direct dependencies are updated #8974

[karfau]

One thing I have not yet fully understood:
According to https://docs.renovatebot.com/configuration-options/#vulnerabilityalerts we will already receive security PRs when all the GitHub options are enabled.
I don't find any information in https://docs.renovatebot.com/configuration-options/#osvvulnerabilityalerts how this is different from what is enabled by default on GitHub.

From the website it looks like there will be more security PRs?

Also I head to read this thread to find out that you can combine those two options to have more control. I think a hint about that should be part of the documentation.

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?

[rabajaj0509]

Personally, I wanted to use vulnerabilityAlerts but since that feature does not work on Gitlab, I had to use the osvVulnerabilityAlerts and it simply works fine for me. I would request maintainers to continue support for this feature, or maybe support the vulnerabilityAlerts on Gitlab :)

[neubami94]

Hello, is this correct configuration for my use case? I want gitlab merge requests to be automatically created only for major updates or vulnerability fixes.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:base"
  ],
  "packageRules": [
    {
      "description": "Disables the creation of branches/MRs for any minor/patch updates etc.",
      "matchUpdateTypes": ["minor", "patch", "pin", "digest", "rollback"],
      "enabled": false
    },
    {
      "description": "Causes the bot to create a MR whenever there is a new major dependency version",
      "matchUpdateTypes": ["major"],
      "enabled": true
    }
  ],
  "osvVulnerabilityAlerts": true,
  "vulnerabilityAlerts": {
    "enabled": true,
    "recreateClosed": false,
    "semanticCommitType": "fix",
    "commitMessageSuffix": "",
    "addLabels": ["vulnerability"]
  }
}

[Churro]

Please share a reproduction repo. The renovate config itself looks fine but without logs and the deps you expect vulnerability update PRs for, it's hard to say anything meaningful.

The OSV vulnerability feature should work regardless of the SCM you are using.

[mchccc]

I don't think I'd be able to share a whole repo, at least not within our own Azure environment, but here is our config as it's printed by the pipeline debug

"migratedConfig": {
  "platform": "azure",
  "endpoint": "https://dev.azure.com/company/",
  "token": "***********",
  "hostRules": [
    {
      "matchHost": "https://pkgs.dev.azure.com/company/company/_packaging/Default/pypi/simple",
      "token": "***********"
    },
    {
      "hostType": "nuget",
      "matchHost": "https://pkgs.dev.azure.com",
      "username": "",
      "password": "***********"
    }
  ],
  "rebaseWhen": "behind-base-branch",
  "repositories": [
    {
      "repository": "company/company.analytics.pec",
      "baseBranches": ["master", "/^test-renovate.*/"],
      "onboardingConfig": {
        "$schema": "https://docs.renovatebot.com/renovate-schema.json",
        "automerge": false,
        "platformAutomerge": true,
        "autoApprove": false,
        "separateMajorMinor": true,
        "pip_requirements": {"fileMatch": ["requirements.tests.txt"]},
        "packageRules": [
          {"matchPackagePatterns": ["*"], "enabled": false},
          {
            "groupName": "company packages",
            "matchPackagePrefixes": ["company"],
            "registryUrls": [
              "https://pkgs.dev.azure.com/company/company/_packaging/Default/pypi/simple"
            ],
            "enabled": true
          },
          {
            "matchUpdateTypes": ["minor", "patch", "pin", "digest"],
            "automerge": true,
            "autoApprove": true
          }
        ],
        "osvVulnerabilityAlerts": true,
        "vulnerabilityAlerts": {
          "enabled": true,
          "addLabels": ["vulnerability"]
        },
        "labels": ["dependencies", "rebase"],
        "reviewers": ["required:company Analytics"]
      },
      "onboardingConfigFileName": "renovate.json5"
    }
  ]
}

and these are the relevant lines for redis

{
  "depName": "redis",
  "currentValue": "==4.2.2",
  "datasource": "pypi",
  "currentVersion": "4.2.2",
  "updates": [],
  "packageName": "redis",
  "skipReason": "disabled"
},

Dependency: redis, is disabled (repository=company/company.analytics.pec, baseBranch=test-renovate-vuln)

[Churro]

As already said, nobody will be able to help you if you are unable to make your problem reproducible for others. Opening vulnerability fix PRs for redis 4.2.2 works fine using OSV as datasource: renovate-demo/20542-redis#1

[mchccc]

I created an empty test repo just like the one you linked.. I still cannot share access to it, but it does work with that minimal setup.

I am now adding back configuration items little by little to see when it stops working.

[mchccc]

Ok so the feature seems to work as discussed both here and in the other thread; my issue was updating the config file on a different branch to do some testing, and apparently that did not get picked up, despite printing the updated config in the pipeline output; updating it in the main branch got it to work.
Not sure whether that should be considered a bug, but I'd say it's at least misleading to print as debug a configuration that's not actually being used.

[gzmarstone]

We are using AWS CodeArtifact with an upstream repo of PyPI, none of the vulnerabilities are marked in our renovate pull requests (repos that directly use pypi work correctly), is there a way to tell the OSV checker to check the packages in our CodeArtifact repo against the osv database?

[gzmarstone]

Just a simple Pipfile with
[packages] requests = "==2.28.2"
does not work, but a requirements.txt file with
requests==2.28.2
will find the vulnerability.

[Churro]

I see the issue now. The fix is trivial, I'll send a PR after I probably rework the tests for pipenv first.

[gzmarstone]

Thats awesome, thanks! I might have gotten around to finding it, but it would have taken me a lot longer since I just started looking at the code.

[Churro]

@gzmarstone, you may want to try again with renovate 37.141.0. It includes PR #26769 which should fix vulnerability lookups for pipenv.

[gzmarstone]

Worked like a charm, it looks like all of the updates now show [Security] that I would have expected... Thanks for the super quick resolution...

[gbleu]

We are seeing a weird behavior with peerDependencies where the widened range is not preserved

DEBUG: Skipping vulnerability lookup for package axios due to unsupported version ^0.27.0 || ^1.0.0 (repository=local)
DEBUG: Setting allowed version 1.6.0 to fix vulnerability GHSA-wf5p-g6vw-rhxx in axios 1.5.0 (repository=local)

"depType": "devDependencies",
"depName": "axios",
"currentValue": "1.5.0",
"newValue": "1.6.0",

"depType": "peerDependencies",
"currentValue": "^0.27.0 || ^1.0.0",
"newValue": "^1.6.0 ^1.6.0",

[gbleu]

An other example with mongodb 5.7.0 -> 5.8.0 the peer "5 || 6" is replaced by "5 5"

The 6.x line is not affected by the CVE

[gbleu]

The repro repo is only affected when using renovate docker image, on GH the peers does not change.

[Churro]

@gbleu, I cannot reproduce the behavior you describe, neither with the image, nor with Github. peerDependencies remain unchanged. The PRs opened in your GH repo are based on Github vulnerability alerts, not OSV.

[gbleu]

@Churro please find the full log running with command docker run --rm -v $PWD:/usr/src/app -v /tmp:/tmp -e LOG_LEVEL=debug renovate/renovate --platform=local

log

DEBUG: Using RE2 as regex engine
DEBUG: Parsing configs
DEBUG: Checking for config file in /usr/src/app/config.js
DEBUG: No config file found on disk - skipping
DEBUG: File config
       "config": {}
DEBUG: CLI config
       "config": {"platform": "local"}
DEBUG: Env config
       "config": {"hostRules": []}
DEBUG: Combined config
       "config": {"hostRules": [], "platform": "local"}
DEBUG: Enabling forkProcessing while in non-autodiscover mode
DEBUG: Found valid git version: 2.43.0
DEBUG: Setting global hostRules
DEBUG: Using baseDir: /tmp/renovate
DEBUG: Using cacheDir: /tmp/renovate/cache
DEBUG: Using containerbaseDir: /tmp/renovate/cache/containerbase
DEBUG: Initializing Renovate internal cache into /tmp/renovate/cache/renovate/renovate-cache-v1
DEBUG: Commits limit = null
DEBUG: Setting global hostRules
DEBUG: validatePresets()
DEBUG: Reinitializing hostRules for repo
DEBUG: Clearing hostRules
 INFO: Repository started (repository=local)
       "renovateVersion": "37.149.1"
DEBUG: Using localDir: /usr/src/app (repository=local)
DEBUG: PackageFiles.clear() - Package files deleted (repository=local)
DEBUG: Resetting npmrc (repository=local)
DEBUG: Resetting npmrc (repository=local)
DEBUG: checkOnboarding() (repository=local)
DEBUG: isOnboarded() (repository=local)
DEBUG: findFile(renovate.json) (repository=local)
DEBUG: Could not get file list using git, using glob instead (repository=local)
DEBUG: Config file exists, fileName: renovate.json (repository=local)
DEBUG: Repo is onboarded (repository=local)
DEBUG: Could not get file list using git, using glob instead (repository=local)
DEBUG: Found renovate.json config file (repository=local)
DEBUG: Repository config (repository=local)
       "fileName": "renovate.json",
       "config": {
         "$schema": "https://docs.renovatebot.com/renovate-schema.json",
         "extends": ["config:recommended"],
         "osvVulnerabilityAlerts": true
       }
DEBUG: migrateAndValidate() (repository=local)
DEBUG: No config migration necessary (repository=local)
DEBUG: Setting hostRules from config (repository=local)
DEBUG: Found repo ignorePaths (repository=local)
       "ignorePaths": [
         "**/node_modules/**",
         "**/bower_components/**",
         "**/vendor/**",
         "**/examples/**",
         "**/__tests__/**",
         "**/test/**",
         "**/tests/**",
         "**/__fixtures__/**"
       ]
DEBUG: No vulnerability alerts found (repository=local)
DEBUG: No baseBranches (repository=local)
DEBUG: extract() (repository=local)
DEBUG: Could not get file list using git, using glob instead (repository=local)
DEBUG: Using file match: (^|/)tasks/[^/]+\.ya?ml$ for manager ansible (repository=local)
DEBUG: Using file match: (^|/)(galaxy|requirements)(\.ansible)?\.ya?ml$ for manager ansible-galaxy (repository=local)
DEBUG: Using file match: (^|/)\.tool-versions$ for manager asdf (repository=local)
DEBUG: Using file match: azure.*pipelines?.*\.ya?ml$ for manager azure-pipelines (repository=local)
DEBUG: Using file match: (^|/)batect(-bundle)?\.ya?ml$ for manager batect (repository=local)
DEBUG: Using file match: (^|/)batect$ for manager batect-wrapper (repository=local)
DEBUG: Using file match: (^|/)WORKSPACE(|\.bazel)$ for manager bazel (repository=local)
DEBUG: Using file match: \.bzl$ for manager bazel (repository=local)
DEBUG: Using file match: (^|/)MODULE\.bazel$ for manager bazel-module (repository=local)
DEBUG: Using file match: (^|/)\.bazelversion$ for manager bazelisk (repository=local)
DEBUG: Using file match: \.bicep$ for manager bicep (repository=local)
DEBUG: Using file match: (^|/)\.?bitbucket-pipelines\.ya?ml$ for manager bitbucket-pipelines (repository=local)
DEBUG: Using file match: buildkite\.ya?ml for manager buildkite (repository=local)
DEBUG: Using file match: \.buildkite/.+\.ya?ml$ for manager buildkite (repository=local)
DEBUG: Using file match: (^|/)bun\.lockb$ for manager bun (repository=local)
DEBUG: Using file match: (^|/)Gemfile$ for manager bundler (repository=local)
DEBUG: Using file match: \.cake$ for manager cake (repository=local)
DEBUG: Using file match: (^|/)Cargo\.toml$ for manager cargo (repository=local)
DEBUG: Using file match: (^|/)\.circleci/config\.ya?ml$ for manager circleci (repository=local)
DEBUG: Using file match: (^|/)cloudbuild\.ya?ml for manager cloudbuild (repository=local)
DEBUG: Using file match: (^|/)Podfile$ for manager cocoapods (repository=local)
DEBUG: Using file match: (^|/)([\w-]*)composer\.json$ for manager composer (repository=local)
DEBUG: Using file match: (^|/)conanfile\.(txt|py)$ for manager conan (repository=local)
DEBUG: Using file match: (^|/)cpanfile$ for manager cpanfile (repository=local)
DEBUG: Using file match: (^|/)(?:deps|bb)\.edn$ for manager deps-edn (repository=local)
DEBUG: Using file match: (^|/)(?:docker-)?compose[^/]*\.ya?ml$ for manager docker-compose (repository=local)
DEBUG: Using file match: (^|/|\.)([Dd]ocker|[Cc]ontainer)file$ for manager dockerfile (repository=local)
DEBUG: Using file match: (^|/)([Dd]ocker|[Cc]ontainer)file[^/]*$ for manager dockerfile (repository=local)
DEBUG: Using file match: (^|/)\.drone\.yml$ for manager droneci (repository=local)
DEBUG: Using file match: (^|/)fleet\.ya?ml for manager fleet (repository=local)
DEBUG: Using file match: (?:^|/)gotk-components\.ya?ml$ for manager flux (repository=local)
DEBUG: Using file match: (^|/)\.fvm/fvm_config\.json$ for manager fvm (repository=local)
DEBUG: Using file match: (^|/)\.gitmodules$ for manager git-submodules (repository=local)
DEBUG: Using file match: (^|/)(workflow-templates|\.(?:github|gitea|forgejo)/(?:workflows|actions))/.+\.ya?ml$ for manager github-actions (repository=local)
DEBUG: Using file match: (^|/)action\.ya?ml$ for manager github-actions (repository=local)
DEBUG: Using file match: \.gitlab-ci\.ya?ml$ for manager gitlabci (repository=local)
DEBUG: Using file match: \.gitlab-ci\.ya?ml$ for manager gitlabci-include (repository=local)
DEBUG: Using file match: (^|/)go\.mod$ for manager gomod (repository=local)
DEBUG: Using file match: \.gradle(\.kts)?$ for manager gradle (repository=local)
DEBUG: Using file match: (^|/)gradle\.properties$ for manager gradle (repository=local)
DEBUG: Using file match: (^|/)gradle/.+\.toml$ for manager gradle (repository=local)
DEBUG: Using file match: (^|/)buildSrc/.+\.kt$ for manager gradle (repository=local)
DEBUG: Using file match: \.versions\.toml$ for manager gradle (repository=local)
DEBUG: Using file match: (^|/)versions.props$ for manager gradle (repository=local)
DEBUG: Using file match: (^|/)versions.lock$ for manager gradle (repository=local)
DEBUG: Using file match: (^|/)gradle/wrapper/gradle-wrapper\.properties$ for manager gradle-wrapper (repository=local)
DEBUG: Using file match: (^|/)requirements\.ya?ml$ for manager helm-requirements (repository=local)
DEBUG: Using file match: (^|/)values\.ya?ml$ for manager helm-values (repository=local)
DEBUG: Using file match: (^|/)helmfile\.ya?ml(?:\.gotmpl)?$ for manager helmfile (repository=local)
DEBUG: Using file match: (^|/)Chart\.ya?ml$ for manager helmv3 (repository=local)
DEBUG: Using file match: (^|/)bin/hermit$ for manager hermit (repository=local)
DEBUG: Using file match: ^Formula/[^/]+[.]rb$ for manager homebrew (repository=local)
DEBUG: Using file match: \.html?$ for manager html (repository=local)
DEBUG: Using file match: (^|/)plugins\.(txt|ya?ml)$ for manager jenkins (repository=local)
DEBUG: Using file match: (^|/)jsonnetfile\.json$ for manager jsonnet-bundler (repository=local)
DEBUG: Using file match: ^.+\.main\.kts$ for manager kotlin-script (repository=local)
DEBUG: Using file match: (^|/)kustomization\.ya?ml$ for manager kustomize (repository=local)
DEBUG: Using file match: (^|/)project\.clj$ for manager leiningen (repository=local)
DEBUG: Using file match: (^|/|\.)pom\.xml$ for manager maven (repository=local)
DEBUG: Using file match: ^(((\.mvn)|(\.m2))/)?settings\.xml$ for manager maven (repository=local)
DEBUG: Using file match: (^|\/).mvn/wrapper/maven-wrapper.properties$ for manager maven-wrapper (repository=local)
DEBUG: Using file match: (^|/)package\.js$ for manager meteor (repository=local)
DEBUG: Using file match: (^|/)Mintfile$ for manager mint (repository=local)
DEBUG: Using file match: (^|/)mix\.exs$ for manager mix (repository=local)
DEBUG: Using file match: (^|/)flake\.nix$ for manager nix (repository=local)
DEBUG: Using file match: (^|/)\.node-version$ for manager nodenv (repository=local)
DEBUG: Using file match: (^|/)package\.json$ for manager npm (repository=local)
DEBUG: Using file match: \.(?:cs|fs|vb)proj$ for manager nuget (repository=local)
DEBUG: Using file match: \.(?:props|targets)$ for manager nuget (repository=local)
DEBUG: Using file match: (^|/)dotnet-tools\.json$ for manager nuget (repository=local)
DEBUG: Using file match: (^|/)global\.json$ for manager nuget (repository=local)
DEBUG: Using file match: (^|/)\.nvmrc$ for manager nvm (repository=local)
DEBUG: Using file match: (^|/)src/main/features/.+\.json$ for manager osgi (repository=local)
DEBUG: Using file match: (^|/)pyproject\.toml$ for manager pep621 (repository=local)
DEBUG: Using file match: (^|/)[\w-]*requirements(-\w+)?\.(txt|pip)$ for manager pip_requirements (repository=local)
DEBUG: Using file match: (^|/)setup\.py$ for manager pip_setup (repository=local)
DEBUG: Using file match: (^|/)Pipfile$ for manager pipenv (repository=local)
DEBUG: Using file match: (^|/)pyproject\.toml$ for manager poetry (repository=local)
DEBUG: Using file match: (^|/)\.pre-commit-config\.ya?ml$ for manager pre-commit (repository=local)
DEBUG: Using file match: (^|/)pubspec\.ya?ml$ for manager pub (repository=local)
DEBUG: Using file match: (^|/)Puppetfile$ for manager puppet (repository=local)
DEBUG: Using file match: (^|/)\.python-version$ for manager pyenv (repository=local)
DEBUG: Using file match: (^|/)\.ruby-version$ for manager ruby-version (repository=local)
DEBUG: Using file match: \.sbt$ for manager sbt (repository=local)
DEBUG: Using file match: project/[^/]*\.scala$ for manager sbt (repository=local)
DEBUG: Using file match: project/build\.properties$ for manager sbt (repository=local)
DEBUG: Using file match: (^|/)setup\.cfg$ for manager setup-cfg (repository=local)
DEBUG: Using file match: (^|/)Package\.swift for manager swift (repository=local)
DEBUG: Using file match: \.tf$ for manager terraform (repository=local)
DEBUG: Using file match: (^|/)\.terraform-version$ for manager terraform-version (repository=local)
DEBUG: Using file match: (^|/)terragrunt\.hcl$ for manager terragrunt (repository=local)
DEBUG: Using file match: (^|/)\.terragrunt-version$ for manager terragrunt-version (repository=local)
DEBUG: Using file match: \.tflint\.hcl$ for manager tflint-plugin (repository=local)
DEBUG: Using file match: ^\.travis\.ya?ml$ for manager travis (repository=local)
DEBUG: Using file match: (^|/)\.vela\.ya?ml$ for manager velaci (repository=local)
DEBUG: Using file match: ^\.woodpecker(?:/[^/]+)?\.ya?ml$ for manager woodpecker (repository=local)
DEBUG: Matched 1 file(s) for manager npm: package.json (repository=local)
DEBUG: npm file package.json has name "renovate-repro-osv-peer" (repository=local)
DEBUG: Detecting pnpm Workspaces (repository=local)
DEBUG: Detecting workspaces (repository=local)
DEBUG: Finding locked versions (repository=local)
DEBUG: Found pnpm lock-file (repository=local)
DEBUG: manager extract durations (ms) (repository=local)
       "managers": {"npm": 14}
DEBUG: Found npm package files (repository=local)
DEBUG: Found 1 package file(s) (repository=local)
 INFO: Dependency extraction complete (repository=local)
       "stats": {
         "managers": {"npm": {"fileCount": 1, "depCount": 4}},
         "total": {"fileCount": 1, "depCount": 4}
       }
DEBUG: fetchVulnerabilities() - osvVulnerabilityAlerts=true (repository=local)
DEBUG: Vulnerability GHSA-wf5p-g6vw-rhxx affects axios 1.5.0 (repository=local)
DEBUG: Vulnerability GHSA-vxvm-qww3-2fh7 affects mongodb 5.7.0 (repository=local)
DEBUG: Skipping vulnerability lookup for package axios due to unsupported version ^0.27.0 || ^1.0.0 (repository=local)
DEBUG: Skipping vulnerability lookup for package mongodb due to unsupported version 5 || 6 (repository=local)
DEBUG: Setting allowed version 1.6.0 to fix vulnerability GHSA-wf5p-g6vw-rhxx in axios 1.5.0 (repository=local)
DEBUG: Setting allowed version 5.8.0 to fix vulnerability GHSA-vxvm-qww3-2fh7 in mongodb 5.7.0 (repository=local)
DEBUG: PackageFiles.add() - Package file saved for base branch (repository=local)
DEBUG: Package releases lookups complete (repository=local)
DEBUG: branchifyUpgrades (repository=local)
DEBUG: detectSemanticCommits() (repository=local)
DEBUG: getCommitMessages (repository=local)
DEBUG: semanticCommits: detected "unknown" (repository=local)
DEBUG: semanticCommits: disabled (repository=local)
DEBUG: 4 flattened updates found: axios, mongodb, axios, mongodb (repository=local)
DEBUG: Returning 2 branch(es) (repository=local)
DEBUG: config.repoIsOnboarded=true (repository=local)
DEBUG: packageFiles with updates (repository=local)
       "config": {
         "npm": [
           {
             "deps": [
               {
                 "depType": "devDependencies",
                 "depName": "axios",
                 "currentValue": "1.5.0",
                 "datasource": "npm",
                 "prettyDepType": "devDependency",
                 "lockedVersion": "1.5.0",
                 "updates": [
                   {
                     "bucket": "non-major",
                     "newVersion": "1.6.0",
                     "newValue": "1.6.0",
                     "releaseTimestamp": "2023-10-26T21:15:55.685Z",
                     "newMajor": 1,
                     "newMinor": 6,
                     "updateType": "minor",
                     "branchName": "renovate/npm-axios-vulnerability"
                   }
                 ],
                 "packageName": "axios",
                 "versioning": "npm",
                 "warnings": [],
                 "sourceUrl": "https://github.com/axios/axios",
                 "registryUrl": "https://registry.npmjs.org",
                 "homepage": "https://axios-http.com",
                 "currentVersion": "1.5.0",
                 "isSingleVersion": true,
                 "fixedVersion": "1.5.0"
               },
               {
                 "depType": "devDependencies",
                 "depName": "mongodb",
                 "currentValue": "5.7.0",
                 "datasource": "npm",
                 "prettyDepType": "devDependency",
                 "lockedVersion": "5.7.0",
                 "updates": [
                   {
                     "bucket": "non-major",
                     "newVersion": "5.8.0",
                     "newValue": "5.8.0",
                     "releaseTimestamp": "2023-08-21T20:50:13.051Z",
                     "newMajor": 5,
                     "newMinor": 8,
                     "updateType": "minor",
                     "branchName": "renovate/npm-mongodb-vulnerability"
                   }
                 ],
                 "packageName": "mongodb",
                 "versioning": "npm",
                 "warnings": [],
                 "sourceUrl": "https://github.com/mongodb/node-mongodb-native",
                 "registryUrl": "https://registry.npmjs.org",
                 "currentVersion": "5.7.0",
                 "isSingleVersion": true,
                 "fixedVersion": "5.7.0"
               },
               {
                 "depType": "peerDependencies",
                 "depName": "axios",
                 "currentValue": "^0.27.0 || ^1.0.0",
                 "datasource": "npm",
                 "prettyDepType": "peerDependency",
                 "updates": [
                   {
                     "bucket": "major",
                     "newVersion": "1.6.0",
                     "newValue": "^1.6.0 ^1.6.0",
                     "releaseTimestamp": "2023-10-26T21:15:55.685Z",
                     "newMajor": 1,
                     "newMinor": 6,
                     "updateType": "major",
                     "isRange": true,
                     "isBump": true,
                     "branchName": "renovate/npm-axios-vulnerability"
                   }
                 ],
                 "packageName": "axios",
                 "versioning": "npm",
                 "warnings": [],
                 "sourceUrl": "https://github.com/axios/axios",
                 "registryUrl": "https://registry.npmjs.org",
                 "homepage": "https://axios-http.com",
                 "currentVersion": "0.27.2",
                 "isSingleVersion": false
               },
               {
                 "depType": "peerDependencies",
                 "depName": "mongodb",
                 "currentValue": "5 || 6",
                 "datasource": "npm",
                 "prettyDepType": "peerDependency",
                 "updates": [
                   {
                     "bucket": "non-major",
                     "newVersion": "5.8.0",
                     "newValue": "5 5",
                     "releaseTimestamp": "2023-08-21T20:50:13.051Z",
                     "newMajor": 5,
                     "newMinor": 8,
                     "updateType": "minor",
                     "isRange": true,
                     "isBump": true,
                     "branchName": "renovate/npm-mongodb-vulnerability"
                   }
                 ],
                 "packageName": "mongodb",
                 "versioning": "npm",
                 "warnings": [],
                 "sourceUrl": "https://github.com/mongodb/node-mongodb-native",
                 "registryUrl": "https://registry.npmjs.org",
                 "currentVersion": "5.0.0",
                 "isSingleVersion": false
               }
             ],
             "extractedConstraints": {},
             "packageFileVersion": "1.0.0",
             "managerData": {
               "packageJsonName": "renovate-repro-osv-peer",
               "hasPackageManager": false,
               "pnpmShrinkwrap": "pnpm-lock.yaml",
               "yarnZeroInstall": false
             },
             "skipInstalls": true,
             "packageFile": "package.json",
             "lockFiles": ["pnpm-lock.yaml"]
           }
         ]
       }
DEBUG: detectSemanticCommits() (repository=local)
DEBUG: semanticCommits: returning "disabled" from cache (repository=local)
DEBUG: Repository timing splits (milliseconds) (repository=local)
       "splits": {"init": 316, "extract": 169, "lookup": 1889},
       "total": 2375
DEBUG: Package cache statistics (repository=local)
       "get": {"count": 2, "totalMs": 34, "avgMs": 17, "medianMs": 11, "maxMs": 23},
       "set": {"count": 0}
DEBUG: Package lookup durations (repository=local)
       "npm": {"count": 4, "averageMs": 34, "totalMs": 136, "maximumMs": 49}
DEBUG: dns cache (repository=local)
       "hosts": []
 INFO: Repository finished (repository=local)
       "cloned": undefined,
       "durationMs": 2375
DEBUG: Checking file package cache for expired items
DEBUG: Deleted 0 of 2 file cached entries in 5ms
DEBUG: Renovate exiting

[gbleu]

Github is affected now gbleu/renovate-repro-osv-peer#5

[saibot94]

Hi, we saw that the osv alerts are integrated with maven, but they don't suggest patches for the same dependencies that are requested by gradle.

We would be willing to implement this feature, since there's already a way of updating the dependencies of gradle packages. We're thinking it's just a matter of using the mvn vulnerabilities from osv but checking the build.gradle file.

If you think it makes sense, I can create an issue. Thanks!

[jhengy]

@Churro and @saibot94 I was able to create a simple reproducer for the above issue i'm facing. It is a simple spring boot gradle project bootstrapped using https://start.spring.io/. Although spring boot 3.1.5 is known to have vulnerability according to osv.dev database, renovate seems to have problem identifying it (see the dependency report vulnerability section).

p.s. I'm using renovate runner v16.11.1 on gitlab

[jhengy]

Just tried with implementation "org.springframework:spring-web:6.1.0" as suggested by @saibot94 and it seemed that renovate was able to recognise its vulnerability through osv.dev. Why would renovate have trouble detecting vulnerability for id 'org.springframework.boot' version '3.1.5'? Does it have something to do with the usage of io.spring.dependency-management plugin?

p.s. tried with maven instead of gradle but still the same behaviour. Please advice, this seems like a significant pitfall for adopting renovate osvVulnerabilityAlerts since spring boot is central to many projects my team manages.

[Churro]

renovate searches for vulnerabilities based on the list of extracted dependencies. If you specify org.springframework:spring-web, it will look it up in the OSV database (an offline database copy) to identify vulnerabilities. As can you see here, there are quite a few associated with spring-web.

If you use the org.springframework.boot plugin in your application, by gradle convention renovate extracts it as org.springframework.boot:org.springframework.boot.gradle.plugin. Unless someone provides a security advsiory that explicitly mentions this plugin, you won't see a security fix PR. Without actively resolving the dependency tree or also extracting gradle lockfiles (which renovate currently doesn't do), it can't magically infer that using the org.springframework.boot plugin will also cause a vulnerable spring-web to be included.

[jhengy]

@Churro thanks for the explanation. I suppose the same explains why vulnerability was not detected for maven spring boot project under the same reproducer repo? i.e. renovate fails to recognise org.springframework.boot:spring-boot as a dependency since its not explicitly included in pom.xml, hence https://osv.dev/vulnerability/GHSA-jjfh-589g-3hjx was not detected as a vulnerability.

May I know if there is a workaround to resolve this problem?

p.s. btw I tried to introduce gradle depedency locking, hoping that renovate will recognise the presence of org.springframework.boot:spring-boot in gradle.lockfile, but unfortunately it did not seem to work.

[Churro]

@jhengy, yes, that's the reason why you don't get the vulnerability fix PR in your reproducer repo.

What might work as a workaround is to the spring version in a variable and set a custom manager annotation (see here) with depName pointing to the spring-web dependency. In a package rule, you'd then have to disable updates for the spring boot dependency so that you won't get twice a non-security PR and a security PR. Note that this is really just a workaround for this particular case that works under the assumption that whenever there is an update for spring-web, there is also one for spring-boot. It's also not really sustainable because next time when there's a vulnerability in spring-core and not spring-web, you'd again not see a security fix PR.

Gradle lockfiles are currently not parsed, only updated alongside regular updates. Even if renovate would identify spring-web as a transitive dependency to be vulnerable, it would still need knowledge of the full dependency tree and some logic to understand that an update is available for spring-boot and that it will also fix the vulnerability in the transitive dep spring-web. Without this tree, it's not feasible to build the link between spring-boot and spring-web to get a security fix PR for spring-web.

[gzmarstone]

I noticed another peculiarity... It seems that when a package in the Pipfile does not match the case of the package in the OSV, a security update is not created (with the [Security] in the header and a branch name with -vulnerability, just a regular update in this case)...
I am guessing that if I updated the case of the package to be pillow in all lowercase in the Pipfile it would work.
The reason I am bringing it up though is that I can see why other repos other than mine would also have the same mixed case for packages as in the documentation for Pillow it states to run python3 -m pip install --upgrade Pillow, so people following the standard recommendation would simply use that mixed case. Other packages also have similar documentation, for example SQLAlchemy has it as well.

So the Pipfile has:
Pillow = "==10.1.0"

In the log of renovate runs I see (note lowercase pillow):

DEBUG: Vulnerability GHSA-3f63-hfp8-52jq affects pillow 10.1.0 (repository=corp/myproject)
DEBUG: Setting allowed version ==10.2.0 to fix vulnerability GHSA-3f63-hfp8-52jq in pillow 10.1.0 (repository=corp/myproject)

When it outputs the json for the update it outputs this for Pillow (note depName mixedcase and no branch with -vulnerability after it):

               {
                 "depType": "packages",
                 "depName": "Pillow",
                 "managerData": {},
                 "currentValue": "==10.1.0",
                 "datasource": "pypi",
                 "currentVersion": "10.1.0",
                 "updates": [
                   {
                     "bucket": "non-major",
                     "newVersion": "10.2.0",
                     "newValue": "==10.2.0",
                     "newMajor": 10,
                     "newMinor": 2,
                     "updateType": "minor",
                     "isRange": true,
                     "branchName": "renovate/pillow-10.x"
                   }
                 ],
                 "packageName": "Pillow",
                 "versioning": "pep440",
                 "warnings": [],
                 "registryUrl": "https://[custom aws codeartifact repo]/pypi/marstone-python/simple",
                 "isSingleVersion": true,
                 "fixedVersion": "10.1.0"
               },

Let me know if I gave you enough information or if you need me to give you any more details...

Geoff

[gzmarstone]

Here is the simple repro case:
Pipfile:

[packages]
Pillow = "==10.1.0"

config.js

module.exports = {
  "platform": "local",
  "osvVulnerabilityAlerts": true,
  "vulnerabilityAlerts": {
     "enabled": true
  },
  "onboarding": false,
  "dryRun": "lookup",
  "hostRules": [
     {"hostType": "github", "matchHost": "github.com", "token": "xxxxxxxxxxxxxxxxxxxx"}
  ],
  baseDir: "./renovate",
};

You will see that the in the log it creates a regular branch not a security branch (look at branchName in the logs) :

DEBUG: Matched 1 file(s) for manager pipenv: Pipfile (repository=local)
DEBUG: manager extract durations (ms) (repository=local)
       "managers": {"pipenv": 5}
DEBUG: Found pipenv package files (repository=local)
DEBUG: Found 1 package file(s) (repository=local)
 INFO: Dependency extraction complete (repository=local)
       "stats": {
         "managers": {"pipenv": {"fileCount": 1, "depCount": 1}},
         "total": {"fileCount": 1, "depCount": 1}
       }
DEBUG: fetchVulnerabilities() - osvVulnerabilityAlerts=true (repository=local)
DEBUG: Vulnerability GHSA-3f63-hfp8-52jq affects pillow 10.1.0 (repository=local)
DEBUG: Setting allowed version ==10.2.0 to fix vulnerability GHSA-3f63-hfp8-52jq in pillow 10.1.0 (repository=local)
DEBUG: PackageFiles.add() - Package file saved for base branch (repository=local)
DEBUG: Package releases lookups complete (repository=local)
DEBUG: branchifyUpgrades (repository=local)
DEBUG: detectSemanticCommits() (repository=local)
DEBUG: getCommitMessages (repository=local)
DEBUG: semanticCommits: detected "unknown" (repository=local)
DEBUG: semanticCommits: disabled (repository=local)
DEBUG: 1 flattened updates found: Pillow (repository=local)
DEBUG: Returning 1 branch(es) (repository=local)
DEBUG: config.repoIsOnboarded=true (repository=local)
DEBUG: packageFiles with updates (repository=local)
       "config": {
         "pipenv": [
           {
             "deps": [
               {
                 "depType": "packages",
                 "depName": "Pillow",
                 "managerData": {},
                 "currentValue": "==10.1.0",
                 "datasource": "pypi",
                 "currentVersion": "10.1.0",
                 "updates": [
                   {
                     "bucket": "non-major",
                     "newVersion": "10.2.0",
                     "newValue": "==10.2.0",
                     "releaseTimestamp": "2024-01-02T09:15:01.000Z",
                     "newMajor": 10,
                     "newMinor": 2,
                     "updateType": "minor",
                     "isRange": true,
                     "branchName": "renovate/pillow-10.x"
                   }
                 ],
                 "packageName": "Pillow",
                 "versioning": "pep440",
                 "warnings": [],
                 "sourceUrl": "https://github.com/python-pillow/Pillow",
                 "registryUrl": "https://pypi.org/pypi",
                 "changelogUrl": "https://github.com/python-pillow/Pillow/blob/main/CHANGES.rst",
                 "isSingleVersion": true,
                 "fixedVersion": "10.1.0"
               }
             ],
             "extractedConstraints": {},
             "packageFile": "Pipfile"
           }
         ]
       }

If you change the Pipfile to be pillow in lowercase and re-run renovate, you see that it then creates a security vulnerability branch...

DEBUG: Matched 1 file(s) for manager pipenv: Pipfile (repository=local)
DEBUG: manager extract durations (ms) (repository=local)
       "managers": {"pipenv": 5}
DEBUG: Found pipenv package files (repository=local)
DEBUG: Found 1 package file(s) (repository=local)
 INFO: Dependency extraction complete (repository=local)
       "stats": {
         "managers": {"pipenv": {"fileCount": 1, "depCount": 1}},
         "total": {"fileCount": 1, "depCount": 1}
       }
DEBUG: fetchVulnerabilities() - osvVulnerabilityAlerts=true (repository=local)
DEBUG: Vulnerability GHSA-3f63-hfp8-52jq affects pillow 10.1.0 (repository=local)
DEBUG: Setting allowed version ==10.2.0 to fix vulnerability GHSA-3f63-hfp8-52jq in pillow 10.1.0 (repository=local)
DEBUG: PackageFiles.add() - Package file saved for base branch (repository=local)
DEBUG: Package releases lookups complete (repository=local)
DEBUG: branchifyUpgrades (repository=local)
DEBUG: detectSemanticCommits() (repository=local)
DEBUG: getCommitMessages (repository=local)
DEBUG: semanticCommits: detected "unknown" (repository=local)
DEBUG: semanticCommits: disabled (repository=local)
DEBUG: 1 flattened updates found: Pillow (repository=local)
DEBUG: Returning 1 branch(es) (repository=local)
DEBUG: config.repoIsOnboarded=true (repository=local)
DEBUG: packageFiles with updates (repository=local)
       "config": {
         "pipenv": [
           {
             "deps": [
               {
                 "depType": "packages",
                 "depName": "Pillow",
                 "managerData": {},
                 "currentValue": "==10.1.0",
                 "datasource": "pypi",
                 "currentVersion": "10.1.0",
                 "updates": [
                   {
                     "bucket": "non-major",
                     "newVersion": "10.2.0",
                     "newValue": "==10.2.0",
                     "releaseTimestamp": "2024-01-02T09:15:01.000Z",
                     "newMajor": 10,
                     "newMinor": 2,
                     "updateType": "minor",
                     "isRange": true,
                     "branchName": "renovate/pillow-10.x"
                   }
                 ],
                 "packageName": "Pillow",
                 "versioning": "pep440",
                 "warnings": [],
                 "sourceUrl": "https://github.com/python-pillow/Pillow",
                 "registryUrl": "https://pypi.org/pypi",
                 "changelogUrl": "https://github.com/python-pillow/Pillow/blob/main/CHANGES.rst",
                 "isSingleVersion": true,
                 "fixedVersion": "10.1.0"
               }
             ],
             "extractedConstraints": {},
             "packageFile": "Pipfile"
           }
         ]
       }

[Churro]

@gzmarstone, when I find some time the next few days, I'll make a PR to address this... it's an easy fix.

[setchy]

Would something like https://github.com/AppThreat/vulnerability-db positively broaden the available offline data for vulnerability analysis?

[philippe-granet]

I have created an issue for this: renovatebot/osv-offline#630
My workaround:

export RENOVATE_OSV_VULNERABILITY_ALERTS="true"
export OSV_OFFLINE_ROOT_DIR="/tmp"
export OSV_OFFLINE_DISABLE_DOWNLOAD="true"
curl https://<internal proxy>/osv-offline.zip -o ${OSV_OFFLINE_ROOT_DIR}/osv-offline.zip
unzip ${OSV_OFFLINE_ROOT_DIR}/osv-offline.zip -d ${OSV_OFFLINE_ROOT_DIR}
renovate

You can download latest osv-offline.zip file from here: https://github.com/renovatebot/osv-offline/releases/latest/download/osv-offline.zip

[OrbisK]

Hey, it's not quite clear to me from the docs whether the options under vulnerabilityAlerts (e.g. label) also affect OSV alerts. I would just try to find out by testing. Maybe you could add to the docs if necessary

[bbigras]

Is there a way to get notified when a vulnerability can't be fixed by a PR? Maybe by creating an issue.

Example: the dotenv crate was discontinued, so renovate won't create a PR.

No fixed version available for vulnerability RUSTSEC-2021-0141 in dotenv 0.15.0

I saw that I can use https://docs.renovatebot.com/configuration-options/#dependencydashboardosvvulnerabilitysummary but it would be nice to get a notification.

I'm using gitlab.