You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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")'
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.
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
The only concerning points I can find here:
removed
and then anadded
for the new versionExample Update that both adds and removes vulns
gh api /repos/octodemo/demo-vulnerabilities-ghas/dependency-graph/compare/c48a4c7abca9270ddac57bbf0bffcdc07cddc4d0...48fac5a62790ad358d078af647a0d53da6874ecb | jq '.[] | select(.name=="tar")'
The text was updated successfully, but these errors were encountered: