Use GitHub SecurityVulnerabilities regardless of platform

[JamieMagee]

What would you like Renovate to be able to do? Currently Renovate uses the RepositoryVulnerabilityAlert API to retrieve vulnerability alerts. However, this requires a repository to be hosted on GitHub. Instead, we could use the SecurityAdvisory API to retrieve vulnerability alerts. This would be portable to other platforms (GitLab, Azure DevOps, Gitea, etc.) as long as a GitHub token is available. Similar to how changelog retrieval works today.

Describe the solution you'd like Regardless of which platform I'm using, I would like to be able to consume GitHub security vulnerability alerts.

Here's a sample request and response.

Example GraphQL request

{
  securityVulnerabilities(first: 10, package: "axios", ecosystem: NPM, orderBy: {field: UPDATED_AT, direction: DESC}) {
    totalCount
    edges {
      node {
        advisory {
          ghsaId
          publishedAt
          summary
          references {
            url
          }
        }
        firstPatchedVersion {
          identifier
        }
        package {
          ecosystem
          name
        }
        severity
        updatedAt
        vulnerableVersionRange
      }
    }
  }
}

Example GraphQL response

{
  "data": {
    "securityVulnerabilities": {
      "totalCount": 1,
      "edges": [
        {
          "node": {
            "advisory": {
              "ghsaId": "GHSA-42xw-2xvc-qx8m",
              "publishedAt": "2019-05-29T18:04:45Z",
              "summary": "High severity vulnerability that affects axios",
              "references": [
                {
                  "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10742"
                },
                {
                  "url": "https://github.com/advisories/GHSA-42xw-2xvc-qx8m"
                }
              ]
            },
            "firstPatchedVersion": {
              "identifier": "0.18.1"
            },
            "package": {
              "ecosystem": "NPM",
              "name": "axios"
            },
            "severity": "HIGH",
            "updatedAt": "2019-06-05T16:22:11Z",
            "vulnerableVersionRange": "<= 0.18.0"
          }
        }
      ]
    }
  }
}

Describe alternatives you've considered Use each platform's specific API for being notified of security vulnerabilities in dependencies. For example, GitLab has the Security Findings API. However, this is an alpha API, and only available in GitLab Ultimate. Also, other platforms (Azure DevOps, Gitea, BitBucket) don't provide a similar API.

Additional context

[xens]

@rarkins as suggested in #8126:

I wanted to give this feature a try, first I wanted to evaluate if that was easy to implement or not as I wasn't familiar at all with the Renovate code / workflow.

The way it works currently is (as I understand it):

1. for each repository that is hosted in GitHub, Renovate starts to fetch all the known Vulnerabilities that are associated with it using the RepositoryVulnerabilityAlert and stores the result inside the repository configuration (inside the packageRules array (linked to the packageManager and the package)). So this process is currently completely decoupled from the dependencies-extraction process, it'll happen all the time, packages to upgrade or not.

2. Renovate does some grooming with these vulnerabilities:

• checks is alerts for security vulnerabilities are not disabled
• checks if alert has a firstPatchedVersion defined
• ...

2. Renovate extracts all the dependencies for all the packages it finds in the repo

3. Renovate consolidates the info from the repository-configuration and the info coming from the dependencies extraction by flattening prBodyNotes[] and pushes everything inside a PR.

Proposal

An option would be to add the ability to configure a vulnerability-source that is not tightly coupled with a platform like it's the case today with GitHub. Platform-specific solution would still be available (GitLab can be added in the future for paying customers as their APIs are not available for free plans) but we'd have the the ability to add a source that is platform-agnostic like.

• Github SecurityAdvisory API
• Snyk API (for paying customers only)
• ...

The avoid putting too much pressure on the vulnerability-source-API, the call would only happen at the end of the dependencies-extraction process for each package that needs to be updated (after all the constraints are applied).

Limitations

• Solution might not be scalable if there's 100's of packages to upgrade (putting pressure on the vuln-source-API)
• There might be some legal limitation, ex using GitHub API to maintain your code that is hosted on Gitlab (/not hosted on GitHub) https://docs.github.com/en/free-pro-team@latest/github/site-policy/github-terms-of-service#h-api-terms

Let me know if you have a better idea on how to implement that.

[xens]

After thinking a bit about this, with my current Renovate setup in mind (self-hosted, 50 repo, multiple languages); I don't think that doing and extra call per dependency to upgrade, and only for the supported package ecosystems would be considered abusing that much Github's APIs.

What do you think @rarkins and @JamieMagee did you had anything else in mind ?

[rarkins]

Sorry, but I prefer still not to integrate this approach directly into Renovate.

If you only take direct dependencies into account as is suggested (i.e. those which Renovate currently extracts) then you're going to miss the 80-90% of vulnerabilities that are transitive. Before too long someone would claim this is a design fault and want to merge a PR which also checks transitive dependencies, and at that point you'd need up to 10x the API queries to provide the equivalent of what you get with GitHub's native vulnerability scanning.

An additional point: Renovate is already the biggest external consumer of the GitHub API, yet the API team have been great about it. If we were to increase our API consumption directly for the purposes of letting people on competing platforms utilize GitHub's vulnerability list, I think it would stretch the friendship too far.

Until/unless GitHub add an API allowing for the bulk scanning of dependencies and it's clear that utilizing this for competing platforms is ok, I think we should defer this.

[JamieMagee]

Here's an npm library I started writing to solve this issue. I haven't gotten around to integrating it with Renovate yet: https://github.com/JamieMagee/ghsa-offline

[xens]

@JamieMagee any plans to do it ? Or looking for help ?

[JamieMagee]

@xens I would like to do it, but I don't have time right now. If you're interested in implementing it soon, I can provide support.

[JamieMagee]

Yesterday's announcement makes this much easier to do now: https://github.blog/2022-02-22-github-advisory-database-now-open-to-community-contributions/

[MShekow]

CVE support based on GitHub's advisory database would indeed be amazing :)

[JamieMagee]

After some further investigation, I am going to use Open Source Vulnerabilities' API instead. It's supported by Google and the Open Source Security Foundation, and collates vulnerability information from GitHub's security advisory database (as well as many other sources).

The API is rate limited to 100 requests/minute (per IP address), but the data is updated once per day, so we can heavily cache it.

Sources:

• https://osv.dev/
• https://github.com/google/osv
• https://github.com/ossf/osv-schema

[rarkins]

Are you sure? I'd thought that cloning and parsing the GitHub repo at start of a global run would have worked pretty well

[JamieMagee]

I wanted to go with Open Source Vulnerabilities (OSV) over GitHub Security Advisories (GHSA) because OSV is a superset of GHSA.

Mapping the OSV schema to a relational database doesn't really make sense. SQLite can do document database-style queries, but not easily. Deferring all this to the OSV API makes this easier, at the cost of more API calls.

I'll prototype an API client for now, and come back to using SQLite as a document database if it doesn't scale well.

[JamieMagee]

I found an offline document database^1, with a mongo-like interface that I've based my experiment around. I've renamed my ghsa-offline project to osv-offline^2, and I'm ready to start initial integration with Renovate.

To anyone following this issue, this will not be a straightforward or quick change, because our current vulnerabilities implementation is very tightly coupled to the GitHub API. My approach will be to feature flag the functionality behind a (hidden) configuration value so I can work in parallel and not break any existing functionality.

[oliverchang]

@JamieMagee any updates here? We're very interested in this -- is there any other ways we can help here (besides https://github.com/google/osv/issues/321 which is wrapping up)?

[JamieMagee]

Thanks @oliverchang. I was out sick last week, so haven't had a chance to check out your new bulk API yet, but will do soon.

[tobias-lippert]

@JamieMagee Any updates regarding this feature? Will it be possible to receive vulnerability alerts on a self-hosted GitLab instance in a similar way as it is possible today on GitHub once this feature is merged?

[JamieMagee]

Unfortunately, no meaningful update yet. I've been busy with other things and haven't had time to dedicate to the open PR recently. The intention is to bring vulnerability alerts to GitLab, similar to GitHub though.

[YohanSciubukgian]

Could you consider adding SecurityVulnerabilities alerts for Azure DevOps GIT repositories please ? As they are both owned by the same Microsoft company, they might consider the GitHub API usage to promote security to all their platforms.

[Lowaiz]

Hi @JamieMagee

I don't know if it could be used inside Renovate, but Google released a tool called osv-scanner that basically do most of the parts of this feature, by taking a package file and scanning it based on https://osv.dev

And, by the way, as me and my company are interested in this feature, if you need help, I can take a look and try to help :D

[philippe-granet]

@Lowaiz Jamie have implement use of OSV in this PR: https://github.com/renovatebot/renovate/pull/15159 @JamieMagee any news about this PR?

[JamieMagee]

Resolved in #20226