Vulnerability alerts not created for packages with semver ranges when no lockfile exists

[jsonbailey]

Summary

When a repository has no lockfile (common for published library packages), Renovate detects GitHub Dependabot vulnerability alerts correctly but never opens PRs to fix them. The vulnerability lookup is skipped for every package because their versions are semver ranges (e.g. ^40.2.1) rather than exact resolved versions.

Renovate version: 44.29.5 (Mend-hosted)

Relevant log output

{"msg":"GitHub vulnerability details","alerts":{"npm/electron":{">= 40.0.0-alpha.1, < 41.10.3":"41.10.3"}}}
{"msg":"alert package rules"}
...
{"msg":"Skipping vulnerability lookup for package electron due to unsupported version ^40.2.1"}
...
{"msg":"0 flattened updates found"}

Renovate correctly fetches the Dependabot alerts and generates alertPackageRules with matchCurrentVersion: "< 41.10.3". However, the subsequent vulnerability lookup skips the package because the version string read from package.json (^40.2.1) fails versioningApi.isVersion().

Root cause

There are two affected code paths.

OSV path — lib/workers/repository/process/vulnerabilities.ts

const depVersion =
  dep.lockedVersion ?? dep.currentVersion ?? dep.currentValue!;

if (!versioningApi.isVersion(depVersion)) {
  logger.debug(
    `Skipping vulnerability lookup for package ${packageName} due to unsupported version ${depVersion}`,
  );
  return null;
}

versioningApi.isVersion for npm delegates to semver.valid(), which returns null for ranges. A value like ^40.2.1 fails the check and the package is skipped entirely.

GitHub alerts path — lib/workers/repository/init/vulnerability.ts

The generated alertPackageRules include matchCurrentVersion: "< 41.10.3". This comparison also requires an exact resolved version. Without a lockfile, currentVersion is undefined, so the rule never matches and force.enabled: true never fires.

Expected behavior

When no exact version is available and the declared value is a semver rangek to the minimum version satisfying the range as a proxy for the currentversion. For ^40.2.1 that is 40.2.1. This is the most conservative assumption: if the minimum of the range is in package may be running a vulnerable version and a PR is warranted.
---Proposed fix
semver is already a Renovate dependency and exposes semver.minVersion(rangetical minimum of a range without needing a list of published versions. TheOSV path fix is ~5 lines in vulnerabilities.ts:

const depVersion =
  dep.lockedVersion ?? dep.currentVersion ?? dep.currentValue!;

if (!versioningApi.isVersion(depVersion)) {
  const minVer = semver.minVersion(depVersion)?.version;
  if (!minVer) {
    logger.debug(
      `Skipping vulnerability lookup for package ${packageName} due to unsupported version ${depVersion}`,
    );
    return null;
  }
  logger.debug(
    `No exact version for ${packageName}, using range minimum ${minVer} as proxy for vulnerability check`,
  );
  depVersion = minVer;
}

The GitHub alerts path would need a corresponding fix in the update lookup phase so that matchCurrentVersion can evaluate against the range minimum when no lockfile is present.

Additional context

• This affects library-style repos that intentionally omit lockfiles so consumers are not forced onto pinned transitive deps
• No existing issue or discussion appears to cover this specific scenario

[jsonbailey]

I am willing to provide a PR for this if we think the approach is valid.