scorecard started reducing score for vulnerabilities in unrelated packages that aren't imported

[x448]

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:

1. view score at https://securityscorecards.dev/viewer/?uri=github.com/fxamacker/cbor/v2
2. expand "Vulnerabilities" (it shows 29 vulnerabilities like GO-2022-0969 which is in net/http)
3. view imports at https://pkg.go.dev/github.com/fxamacker/cbor/v2?tab=imports
4. 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.

[spencerschrock]

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.

[spencerschrock]

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.

[x448]

@spencerschrock thanks for fast response and details! 😄

[spencerschrock]

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.