anchore
False positive: GHSA-cxww-7g56-2vh6 detected even when using suggested fix
What happened:
Scanned repository with a github workflow that is using actions/download-artifact@v4 and got flagged for GHSA-cxww-7g56-2vh6:
NAME INSTALLED FIXED IN TYPE VULNERABILITY SEVERITY EPSS RISK
actions/download-artifact v4 4.1.3 github-action GHSA-cxww-7g56-2vh6 High N/A N/A
even though GHSA-cxww-7g56-2vh6 explicitly says:
Alternatively use 'v4' tag which points to the latest and secure version.
What you expected to happen: Issue GHSA-cxww-7g56-2vh6 should be detected there.
How to reproduce it (as minimally and precisely as possible): Scan any repository that is using it: https://github.com/search?q=uses%3A+actions%2Fdownload-artifact%40v4&type=code
Anything else we need to know?:
Environment:
- Output of
grype version: 0.95.0 - OS (e.g:
cat /etc/os-releaseor similar):
There's two ways to look at this:
- previous invocations of the action
- future invocations of the action
Given we don't have the specific version of the artifact, if you're interested in vulnerabilities in case 1, we should show the match against this GHSA since it is possible that you were running an earlier version.
However, if you're interested only in case 2, then we should not show this match since any future invocation will be the latest released version of the action (and there is a fix listed within this major version).
So it depends what the end user is using grype for ("were we ever vulnerable" vs "are we vulnerable now"), which makes me hesitant to make a specific change that would not show matches for case 1.
To answer "were we ever vulnerable" Grype would have to run against all previous revisions in git (or other VCS) and scan that, paying special attention to release dates of such loosely pinned dependancies (eg v4 meant vulnerable version only in a certain time period).
And even if the version is pinned precisely and the dependancy was upgraded immediately AFTER the vulnerability was known, Grype would have to report the period between release time and fixing upgrade as vulnerable and project possibly compromised, to be investigated further (in execution logs if available, rotating keys...).
If there is no time component in the vulnerability databases, only release numbers, then security scanners can only scan current state of vulnerability.
I am experiencing the same issue and I’m wondering what I’m expected to do to resolve it. Explicitly pinning actions/download-artifact to a specific version, such as actions/[email protected], does fix the problem. However, I’d prefer to keep using v4 so that I always get the latest major version. If I continue using v4, does this mean that Grype will always report this vulnerability to satisfy case 1 above? Is there a way to stop this from being reported while still using v4?
