False positives on multiple Golang libraries

[Terr]

In my trials of scanning some Go-based projects I noticed that I'm getting many false positives for Go packages that aren't about the packages themselves, but about the servers they are a client package for.

I can't share the projects or their go.mod/go.sum files, but I did set up an example repository with three dependencies that shows the kind of reports I'm getting: https://github.com/Terr/dependencycheck-golang-false-positives

In each of these three example cases the client libraries are matched to a CPE of the servers they're a client library for:

go-sql-driver/mysql

<identifiers>
  <package confidence="HIGHEST">
    <id>pkg:golang/github.com/go-sql-driver/mysql@1.6.0</id>
    <url>https://ossindex.sonatype.org/component/pkg:golang/github.com/go-sql-driver/mysql@1.6.0?utm_source=dependency-check&amp;utm_medium=integration&amp;utm_content=6.4.1</url>
  </package>
  <vulnerabilityIds confidence="HIGH">
    <id>cpe:2.3:a:mysql:mysql:1.6.0:*:*:*:*:*:*:*</id>
    <url>https://nvd.nist.gov/vuln/search/results?form_type=Advanced&amp;results_type=overview&amp;search_type=all&amp;cpe_vendor=cpe%3A%2F%3Amysql&amp;cpe_product=cpe%3A%2F%3Amysql%3Amysql&amp;cpe_version=cpe%3A%2F%3Amysql%3Amysql%3A1.6.0</url>
  </vulnerabilityIds>
</identifiers>

Vulnerabilities are about MySQL server.

prometheus/client_golang

<identifiers>
  <package confidence="HIGHEST">
    <id>pkg:golang/github.com/prometheus/client_golang@1.11.0</id>
    <url>https://ossindex.sonatype.org/component/pkg:golang/github.com/prometheus/client_golang@1.11.0?utm_source=dependency-check&amp;utm_medium=integration&amp;utm_content=6.4.1</url>
  </package>
  <vulnerabilityIds confidence="LOW">
    <id>cpe:2.3:a:prometheus:prometheus:1.11.0:*:*:*:*:*:*:*</id>
  </vulnerabilityIds>
</identifiers>

Vulnerabilities are about Prometheus server.

minio/minio-go/v7

<identifiers>
  <package confidence="HIGHEST">
    <id>pkg:golang/github.com/minio/minio-go/v7@7.0.15</id>
    <url>https://ossindex.sonatype.org/component/pkg:golang/github.com/minio/minio-go/v7@7.0.15?utm_source=dependency-check&amp;utm_medium=integration&amp;utm_content=6.4.1</url>
  </package>
  <vulnerabilityIds confidence="LOW">
    <id>cpe:2.3:a:minio:minio:7.0.15:*:*:*:*:*:*:*</id>
  </vulnerabilityIds>
</identifiers>

Vulnerabilies are about "Minio S3 server"

I'm wondering if there is a bug at play here instead of just some false positives, since I'm getting more similar cases in the "real" projects that I'm scanning. With other languages (Python, PHP) this doesn't seem to happen.

[Terr]

Tried the scan again with version 6.5.0, same results

Command line that I used: docker run --rm -v ~/out:/out -v ~/dependencycheck-golang-false-positives:/src owasp/dependency-check:6.5.0 -o /out -s /src --enableExperimental -f HTML -f JSON --prettyPrint -f XML

[Terr]

Tested it again with 6.5.1, same results

[Terr]

Unchanged in 6.5.2

[jeremylong]

@Terr you can always include a suppression file yourself or even submit a PR.

https://jeremylong.github.io/DependencyCheck/general/suppression.html

[Terr]

The thing is, it seems to be triggering on almost all Go dependencies that share a name with a server or client application, even if those aren't written in Go (e.g. MySQL). It seems a bit too much if I have to suppress all those things.

Maybe I should've classified this issue as a possible bug?

[jeremylong]

Nope - these would be false positives. Read up on how dependency-check works: https://jeremylong.github.io/DependencyCheck/general/internals.html

Also - the go analyzer is still experimental and one of the main reasons is the number of FP.

With other tech stacks we've been able to generate a sufficient amount of base suppression rules and modifications to the data collected to make the process more accurate - we just haven't done this for go yet.

[ncole]

I would highly recommend allowing to specify the binary for golang testing. If it's compiled, you can run go tool nm <binary> and will list the specific libraries that are linked (and therefore, require actual scanning). You can then correlate that to the static go.mod analysis you're doing now. Otherwise you'll see HUNDREDS of false positives.