Indirect Go dependencies vulnerability alerts

[phisco]

Tell us more.

In crossplane/crossplane we have configured Renovate to disable all PRs by default and only open the ones related to vulnerability alerts: you can see the config here.

However, we now have an indirect dependency affected by a vulnerability, which correctly being detected by Renovate:

DEBUG: alert package rules
{
  "alertPackageRules": [
    {
      "matchDatasources": [
        "go"
      ],
      "matchPackageNames": [
        "github.com/docker/distribution"
      ],
      "matchCurrentVersion": "= 2.8.1+incompatible",
      "matchFiles": [
        "go.mod"
      ],
      "allowedVersions": "2.8.2-beta.1",
      "prBodyNotes": [
        "### GitHub Vulnerability Alerts",
        "#### [CVE-2023-2253](https://github.com/distribution/distribution/security/advisories/GHSA-hqxw-f8mx-cpmw)\n\n### Impact\n\nSystems that run `distribution` built after a specific commit running on memory-restricted environments can suffer from denial of service by a crafted malicious `/v2/_catalog` API endpoint request. \n\n### Patches\n\nUpgrade to at least 2.8.2-beta.1 if you are running `v2.8.x` release. If you use the code from the main branch, update at least to the commit after [f55a6552b006a381d9167e328808565dd2bf77dc](https://github.com/distribution/distribution/commit/f55a6552b006a381d9167e328808565dd2bf77dc).\n\n### Workarounds\n\nThere is no way to work around this issue without patching. Restrict access to the affected API endpoint: see the recommendations section.\n\n### References\n\n`/v2/_catalog` endpoint accepts a parameter to control the maximum amount of records returned (query string: `n`).\n\nWhen not given the default `n=100` is used.  The server trusts that `n` has an acceptable value, however when using a \nmaliciously large value, it allocates an array/slice of `n` of strings before filling the slice with data.\n\nThis behaviour was introduced ~7yrs ago [1].\n\n### Recommendation\n\nThe `/v2/_catalog` endpoint was designed specifically to do registry syncs with search or other API systems. Such an endpoint would create a lot of load on the backend system, due to overfetch required to serve a request in certain implementations.\n\nBecause of this, we strongly recommend keeping this API endpoint behind heightened privilege and avoiding leaving it exposed to the internet.\n\n###  For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [distribution repository](https://github.com/distribution/distribution)\n* Email us at [cncf-distribution-security@lists.cncf.io](mailto:cncf-distribution-security@lists.cncf.io)\n\n[1] [faulty commit](https://github.com/distribution/distribution/blob/b7e26bac741c76cb792f8e14c41a2163b5dae8df/registry/handlers/catalog.go#L45)"
      ],
      "isVulnerabilityAlert": true,
      "force": {
        "groupName": null,
        "schedule": [],
        "dependencyDashboardApproval": false,
        "minimumReleaseAge": null,
        "rangeStrategy": "update-lockfile",
        "commitMessageSuffix": "[SECURITY]",
        "branchTopic": "{{{datasource}}}-{{{depName}}}-vulnerability",
        "prCreation": "immediate",
        "enabled": true
      }
    }
  ]
}

but is not triggering any PR being disabled by default for the gomod manager:

         {
            "managerData": {
              "lineNumber": 82,
              "multiLine": true
            },
            "depName": "github.com/docker/distribution",
            "depType": "indirect",
            "currentValue": "v2.8.1+incompatible",
            "datasource": "go",
            "enabled": false,
            "updates": [],
            "packageName": "github.com/docker/distribution",
            "warnings": [],
            "versioning": "semver",
            "sourceUrl": "https://github.com/docker/distribution",
            "currentVersion": "v2.8.1+incompatible",
            "fixedVersion": "v2.8.1+incompatible"
          },

I'm not sure whether this is due to the fact that it's not properly matching versions or we are missing some configuration to do so, but what we would like to have is Renovate being able to detect that this dependency is affected by a vulnerability and trigger the update of the direct dependencies relying on that.

Enabling indirect updates as suggested by the docs results in all the indirect dependencies being updated, which is not what we want.

@rarkins confirmed it's not possible at the moment to have direct dependencies updated if and only if either them or any of their dependencies is affected by a vulnerability, see #22487 (reply in thread), so I'm forking the original discussion as requested.

[rarkins]

Renovate today overrides a number of controls for vulnerable dependencies, such as grouping, rate limits, schedules - but it does not override disabled dependencies. Currently indirect dependencies are disabled by default so that's why they don't get rejuvenated back into life

[phisco]

So I feel like what I would need would be to enable them as dependencies, but then disable them as update type and let the vulnerability alerts section reenable them. Makes sense?

[rarkins]

Yes, that would make sense. I'm not sure today we can isolate security updates in packageRules though

[phisco]

I tried having a look at the code, but I think it's above my limited typescript skills 😞

To add to the above, I would have expected that by adding the config suggest in the docs early in the packageRules array, that would have enabled the dependency type "indirect", then disabled by the following rule and reenabled only in case of dependencies:

{
// PackageRules disabled below should be enabled in case of vulnerabilities
  "vulnerabilityalerts": {
    "enabled": true
  },
...
  "packageRules": [
// We don't want dependency updates which are not security related for
// release branches
    {
// enable indirect go dependencies
      "matchManagers": ["gomod"],
      "matchDepTypes": ["indirect"],
      "enabled": true
    }, {
// We want a single PR for all bumps to Go dependencies, but only if there are
// known vulnerabilities in the current version.
      "matchDatasources": [
        "go"
      ],
      "matchPackagePatterns": [
        "*"
      ],
      "enabled": false,
      "matchUpdateTypes": [
        "major",
        "minor",
        "patch",
        "digest"
      ],
      "groupName": "all go dependencies",
  }]
  ...
}

But even if the above configuration worked, that would have probably resulted in PRs bumping for indirect dependencies only, which is still not what we were looking for. It would be awesome if Renovate could be able to infer the direct dependencies that are causing the indirect dependency and look for updates for these depending on a bumped and fixed version of the affected indirect dependency. But, I totally get that would be complex and probably out of scope for Renovate.