x/vuln: govulncheck reports no vulnerabilities while deps.dev reports two vulns

[thediveo]

What version of Go are you using (go version)?

$ go version
go version go1.19 linux/amd64

Does this issue reproduce at the latest version of golang.org/x/vuln?

Yes: v0.0.0-20220908210932-64dbbd7bba4f

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/xxx/.cache/go-build"
GOENV="/home/xxx/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/xxx/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/xxx/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/snap/go/9951"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/snap/go/9951/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1004740596=/tmp/go-build -gno-record-gcc-switches"

What did you do?

1. go install golang.org/x/vuln/cmd/govulncheck@latest
2. git clone https://github.com/thediveo/sealwatcher
3. cd sealwatcher
4. govulncheck ./...
5. Navigate to https://deps.dev/go/github.com%2Fthediveo%2Fsealwatcher/v0.8.1

What did you expect to see?

The reports of running govulncheck and https://deps.dev/go/github.com%2Fthediveo%2Fsealwatcher/v0.8.1 to match each other.

What did you see instead?

• govolncheck reports No vulnerabilities found.
• https://deps.dev/go/github.com%2Fthediveo%2Fsealwatcher/v0.8.1 reports GHSA-c3g4-w6cv-6v7h and GO-2022-0417.

[mknyszek]

CC @golang/vulndb

[zpavlinovic]

Thank you for reporting this! We can see that the module github.com/containers/buildah has been imported at a version where some vulnerabilities exist, which is why perhaps deps.dev is reporting it.

It seems however that govulncheck was not able to conclude that any of these vulnerabilities are in fact exercised by sealwatcher.

I can see by a manual inspection that a vulnerability can be exercised when the exported Builder.Run method of github.com/containers/buildah is called, but sealwatcher seems to only transitively call members of github.com/containers/buildah/define package, which seems is not calling Builder.Run.

This manual analysis could be wrong as we are not that familiar with the sealwatcher code. Is your understanding perhaps different?

[thediveo]

@zpavlinovic your reason is 100% correct. There are no calls to Builder.Run; sealwatcher is only watching. Unit tests only use the REST API client calls, so no call path here either.

[thediveo]

What are the expectations regarding the CLI govulncheck versus the deps site? Are they expected to do different reasoning? If so, is this documented somewhere, so devs are aware of different targets?

[seankhliao]

From both the announcement blogpost:

Govulncheck analyzes your codebase and only surfaces vulnerabilities that actually affect you, based on which functions in your code are transitively calling vulnerable functions

and package docs:

Govulncheck reports known vulnerabilities that affect Go code. It uses static analysis of source code or a binary's symbol table to narrow down reports to only those that could affect the application.

[zpavlinovic]

I am personally not aware of the inner-workings of the deps.dev site but some information is provided at the bottom of https://deps.dev/.

Regarding govulncheck, I can only reiterate what @seankhliao has referenced: govulncheck is using call graph reasoning to figure out if vulnerabilities are actually called by your code. Thanks @seankhliao!

[seankhliao]

deps.dev on dependency

The Insights project provides the package owner view, the complete dependency graph someone maintaining the package would need. At the moment there is no ability to control which classes of dependencies are included.

They include everything from the module graph.

I think this can be closed as working as intended.