scorecard started reducing score for vulnerabilities in unrelated packages that aren't imported
x448 opened this issue · comments
Describe the bug
Scorecard used to show 0 vulnerabilities but it suddenly started showing 29 vulnerabilities (e.g. in packages that are not imported directly or indirectly). This reduces the score by 10 points under "Vulnerabilities".
For example, a CBOR codec library isn't using any networking packages. However, scorecard is showing it as being affected by issues innet/http
such as GO-2022-0969.
Warn: Project is vulnerable to: GO-2022-0969
GO-2022-0969 is a bug in net/http
, which isn't directly or indirectly imported by the CBOR codec.
Reproduction steps
Steps to reproduce the behavior:
- view score at https://securityscorecards.dev/viewer/?uri=github.com/fxamacker/cbor/v2
- expand "Vulnerabilities" (it shows 29 vulnerabilities like GO-2022-0969 which is in
net/http
) - view imports at https://pkg.go.dev/github.com/fxamacker/cbor/v2?tab=imports
- notice that
net/http
is not imported by fxamacker/cbor or fxamacker/cbor/v2
Expected behavior
Report 0 vulnerabilities from net/http
for projects that don't use or import anything that uses net/http
.
Additional context
Screenshot
I didn't investigate remaining vulnerabilities after seeing the first one is a false alarm.
Thanks for the issue. We use osv-scanner as a library for vulnerability detection. Luckily they support call analysis for Go, so we should be able to ignore these uncalled vulnerabilities.
My hope is to have #3893 merged soon. There was an upstream issue that needed to be fixed. Based on the currently implementation, the output when running on the above CBOR library would be:
{
"details": [
"Warn: Project is vulnerable to: GO-2023-1840"
],
"score": 9,
"reason": "1 existing vulnerabilities detected",
"name": "Vulnerabilities",
"documentation": {
"url": "https://github.com/ossf/scorecard/blob/main/docs/checks.md#vulnerabilities",
"short": "Determines if the project has open, known unfixed vulnerabilities."
}
}
Where GO-2023-1840 affects:
- before go1.19.10
- from go1.20.0-0 before go1.20.5
Since your Go directive specifies 1.17 as the minimum required Go version, #3893 would still penalize it. I realize this isn't a 100% fair/accurate outcome for a library, compared to an application, but Scorecard doesn't have any way of handling the distinction currently.
@spencerschrock thanks for fast response and details! 😄
A slightly different fix was used, for now we are filtering all Go stdlib vulns, in part due to the issues I mentioned above the go directive being a minimum version, not the version a binary will eventually use.
Note: this will still take some time (~10 days) for the change to propagate to the API/badge.