Add list of resolved vulnerabilities to the PR Comment / Logs

[felickz]

Not all here is a negative outcome, give developers a pat on the back when they are removing vulnerabilities by upgrading or removing packages (or their transitive dependencies). Consider adding to the PR summary and workflow logs the list of vulnerabilities that have been removed. This will be a great view to show when there are no outstanding open vulnerabilities and just a list of removed - the workflow we would expect most to take when iterating through resolving the issues that dependency-review-action highlights on a PR 🎉 !

The dependency review api will return the list of vulnerabilities on removed packages, so we should have this data

{
  "change_type": "removed",
  "manifest": "docs/package-lock.json",
  "ecosystem": "npm",
  "name": "tough-cookie",
  "version": "2.4.3",
  "package_url": "pkg:npm/[email protected]",
  "license": "BSD-3-Clause",
  "source_repository_url": "https://github.com/salesforce/tough-cookie",
  "scope": "development",
  "vulnerabilities": [
    {
      "severity": "moderate",
      "advisory_ghsa_id": "GHSA-72xf-g2v4-qvf3",
      "advisory_summary": "tough-cookie Prototype Pollution vulnerability",
      "advisory_url": "https://github.com/advisories/GHSA-72xf-g2v4-qvf3"
    }
  ]
}

The only concerning points I can find here:

• if there is still usage of this package/vulnerability elsewhere in another manifest- the per package vulnerability view might give a false sense of removing the vulnerability across the entire repo. If we show them grouped per package as the pr comment/logs already do, then this should be a minor concern.
• Updating a package to a new version might resolve a vulnerability but pull in new ones - this is shown as a removed and then an added for the new version

Example Update that both adds and removes vulns

gh api /repos/octodemo/demo-vulnerabilities-ghas/dependency-graph/compare/c48a4c7abca9270ddac57bbf0bffcdc07cddc4d0...48fac5a62790ad358d078af647a0d53da6874ecb | jq '.[] | select(.name=="tar")'

{
  "change_type": "added",
  "manifest": "docs/package-lock.json",
  "ecosystem": "npm",
  "name": "tar",
  "version": "2.2.2",
  "package_url": "pkg:npm/[email protected]",
  "license": "ISC",
  "source_repository_url": "https://github.com/isaacs/node-tar",
  "scope": "development",
  "vulnerabilities": [
    {
      "severity": "high",
      "advisory_ghsa_id": "GHSA-3jfq-g458-7qm9",
      "advisory_summary": "Arbitrary File Creation/Overwrite due to insufficient absolute path sanitization",
      "advisory_url": "https://github.com/advisories/GHSA-3jfq-g458-7qm9"
    },
    {
      "severity": "high",
      "advisory_ghsa_id": "GHSA-5955-9wpr-37jh",
      "advisory_summary": "Arbitrary File Creation/Overwrite on Windows via insufficient relative path sanitization",
      "advisory_url": "https://github.com/advisories/GHSA-5955-9wpr-37jh"
    }
  ]
}
{
  "change_type": "removed",
  "manifest": "docs/package-lock.json",
  "ecosystem": "npm",
  "name": "tar",
  "version": "2.2.1",
  "package_url": "pkg:npm/[email protected]",
  "license": "ISC",
  "source_repository_url": "https://github.com/isaacs/node-tar",
  "scope": "development",
  "vulnerabilities": [
    {
      "severity": "high",
      "advisory_ghsa_id": "GHSA-j44m-qm6p-hp7m",
      "advisory_summary": "Arbitrary File Overwrite in tar",
      "advisory_url": "https://github.com/advisories/GHSA-j44m-qm6p-hp7m"
    },
    {
      "severity": "high",
      "advisory_ghsa_id": "GHSA-3jfq-g458-7qm9",
      "advisory_summary": "Arbitrary File Creation/Overwrite due to insufficient absolute path sanitization",
      "advisory_url": "https://github.com/advisories/GHSA-3jfq-g458-7qm9"
    },
    {
      "severity": "high",
      "advisory_ghsa_id": "GHSA-5955-9wpr-37jh",
      "advisory_summary": "Arbitrary File Creation/Overwrite on Windows via insufficient relative path sanitization",
      "advisory_url": "https://github.com/advisories/GHSA-5955-9wpr-37jh"
    }
  ]
}

[david-wiggs]

Documenting my support of this 👍

[ebickle]

Our developers frequently request this functionality as well. Many build tools, particularly in the Java ecosystem, make it difficult for developers to know locally if they've fixed a vulnerability or not. They'd like to be able to open a PR (e.g. a draft PR) and have Dependabot be able to inform them whether or not a vulnerability alert will be resolved when the PR merges.

As @felickz noted above, to enable this the dependency diff API needs to report on resolved vulnerabilities.

My proposal is similar but a little different - instead of using the same vulnerabilities field, I propose that a new resolved_vulnerabilities or similar be added to the payload. It would basically be the exact opposite "diff" as today - showing vulnerabilities in the source that no longer exist in the target.

If GitHub can update the REST API, it's easy enough for the community to do a PR on this action to enable support for this.

[sead-asurion]

Every month or so I will raise a PR, and after merging, waiting 30-60 minutes for the pipeline to complete (depending on the application/service I'm working on) I find out that either 1. My PR didn't fix the Dependabot vulnerability that I intended to fix or 2. My PR introduced a new Dependabot vulnerability.

It would be a big time saver if the PR notified the developer of any vulnerabilities that were closed or created by the PR before merging.

[masonembry]

👍