Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/vuln: govulncheck ./... takes ~36mins #54940

Closed
mattcobb opened this issue Sep 7, 2022 · 12 comments
Closed

x/vuln: govulncheck ./... takes ~36mins #54940

mattcobb opened this issue Sep 7, 2022 · 12 comments
Assignees
@zpavlinovic
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance vulncheck or vulndb Issues for the x/vuln or x/vulndb repo WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
vuln/2022

Comments

@mattcobb
Copy link

mattcobb commented Sep 7, 2022 •
edited

For our go.mod, govulncheck takes about 36mins. Is that to be expected? Would like to put this in a pull request pipeline, but that amount of time is too long.

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

$ go version
go version go1.18.2 darwin/amd64

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

yes

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/matt.cobb/Library/Caches/go-build"
GOENV="/Users/matt.cobb/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/matt.cobb/workspace/lightstep/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/matt.cobb/workspace/lightstep/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18.2"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/matt.cobb/workspace/lightstep/go/src/github.com/lightstep/go.mod"
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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/5k/c3z0khd125vdv8zbvk_3pfl00000gn/T/go-build3169633356=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

% date

Wed Sep 7 07:40:34 PDT 2022
% govulncheck ./... &> govulncheck.out
% date
Wed Sep 7 08:16:19 PDT 2022

What did you expect to see?

Expected a much shorter run time. Snyk test/monitor by example takes ~20secs or so (--prune-duplicate-dependencies is our default though). Attached is go.mod (as go.mod.txt) and go.sum (as go.sum.txt) if that helps.

What did you see instead?

It took about 36mins to get the results.

go.mod.txt
go.sum.txt
govulncheck.out.txt
@mattcobb mattcobb added the vulncheck or vulndb Issues for the x/vuln or x/vulndb repo label Sep 7, 2022
@gopherbot gopherbot added this to the Unreleased milestone Sep 7, 2022
@mknyszek mknyszek added Performance NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Sep 7, 2022
@mknyszek
Copy link
Contributor

mknyszek commented Sep 7, 2022

CC @golang/vulndb

@zpavlinovic zpavlinovic self-assigned this Sep 7, 2022
@zpavlinovic
Copy link
Contributor

zpavlinovic commented Sep 7, 2022 •
edited

govulncheck performs a call graph analysis on the source code, so that is expected to take more time than analyzing module or package import paths. However, 30+ mins sounds way too much.

Based on go.mod, is this https://github.com/lightstep/lightstep-tracer-go?

If not, any other info you can share that would help us diagnose or reproduce the issue?

@julieqiu julieqiu modified the milestones: Unreleased, vuln/2022 Sep 8, 2022
@julieqiu julieqiu added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed x/vuln labels Sep 10, 2022
@mattcobb
Copy link
Author

The go.mod attached is from the lightstep private mono-repo. What else can I gather for you?

@zpavlinovic
Copy link
Contributor

Do you know how much and why --prune-duplicate-dependencies helps when using Snyk?

@mattcobb
Copy link
Author

Without it, snyk was often timing out. I think their explanation was they were checking the commonly required packages thousands of times. The downside was that they could not identify exactly which module included a vulnerable package.

@zpavlinovic
Copy link
Contributor

govulncheck is designed not to analyze duplicate dependencies unless they are copied/cloned, so I suspect that is not the issue here.

govulncheck was tested on various projects (and all of its dependencies), some of which have size proportional to kubernetes, and in the worst case scenario the analysis took several minutes. It is quite hard to say why govulncheck is taking so much time on your project without actually running it myself.

Could it be that the project is just really big together with all of its depedencies? One measure that could help diagnose it is to see how many functions are linked by the program.

@timothy-king
Copy link
Contributor

@zpavlinovic While we are at it, is there any other debug diagnostics we could add? Like # of packages? # Lines? Time spent in each major phase? That may allow us to narrow this down a bit without revealing much private info.

@zpavlinovic
Copy link
Contributor

@timothy-king We could provide a patch that surfaces these numbers or even a verbose mode for govulncheck.

A simpler thing that we could start with is to measure the average time taken for gopackages command over several runs:

gopackages -mode=allsyntax ./...

@jaehnri
Copy link

jaehnri commented Oct 2, 2022

Hi, all!

Recently, I had a similar problem scanning ingress-nginx. It took around 17 minutes to complete.
I don't have much info about the versions aside from that I firstly downloaded govulncheck around 6 PM UTC on September 28th via

go install golang.org/x/vuln/cmd/govulncheck@latest

Yesterday (September 30th), I updated to the latest version at 23 PM UTC and it is running in under a second since. Not sure if I can provide any other relevant info, but this problem is possibly fixed. I did not change my environment or other packages that could cause this time to reduce

@zpavlinovic
Copy link
Contributor

zpavlinovic commented Oct 3, 2022 •
edited

@jaehnri Thanks for sharing this! There was a performance update for analyzing binaries, perhaps that helped in your case.

@joedian
Copy link

joedian commented Oct 10, 2022

@mattcobb did updating making a difference for you?

@zpavlinovic
Copy link
Contributor

Closing. (feel free to reopen if the issue is still present)

@golang golang locked and limited conversation to collaborators Nov 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@zpavlinovic zpavlinovic

Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance vulncheck or vulndb Issues for the x/vuln or x/vulndb repo WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
Go Security
Status: Done
Milestone
vuln/2022
Development

No branches or pull requests
8 participants
@timothy-king @zpavlinovic @mattcobb @mknyszek @julieqiu @gopherbot @joedian @jaehnri