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]

👍

[hiteshb-asurion]

+1

[mfulton26]

As a workaround, npm audit (or similar commands for an ecosystem) can be run locally and also run in PR checks along with other checks (build, typecheck, lint, test, etc.).

[github-actions[bot]]

👋 This issue has been marked as stale because it has been open with no activity for 180 days. You can: comment on the issue or remove the stale label to hold stalebot off for a while, add the Keep label to hold stale off permanently, or do nothing. If you do nothing, this issue will be closed eventually by the stalebot. Please see CONTRIBUTING.md for more policy details.

[ebickle]

This is an important issue for us. If someone at GitHub can make the API changes happen, I'm willing to help out with the updates to the action.

(also - commenting to keep this alive from the stale-bot)

[github-actions[bot]]

👋 This issue has been marked as stale because it has been open with no activity for 180 days. You can: comment on the issue or remove the stale label to hold stalebot off for a while, add the Keep label to hold stale off permanently, or do nothing. If you do nothing, this issue will be closed eventually by the stalebot. Please see CONTRIBUTING.md for more policy details.

[david-wiggs]

@ebickle I know this does not involve the API changes as discussed, but it does seem to be working as desired. Please feel free to test / contribute