What
.github/workflows/ci.yml runs gofmt -l, go vet ./..., go test -race ./..., shellcheck scripts/*.sh and the actionmeta test. There is no dependency vulnerability scan and no static analysis beyond go vet.
Why it matters
easySFTP's direct dependencies include golang.org/x/crypto (the SSH implementation itself) and github.com/pkg/sftp. A published Go vulnerability in either would reach every user through the next release without anything in CI noticing. Dependabot updates go.mod, but only tells you a version is old, not that the version you are on is vulnerable on a code path you actually call.
govulncheck is the right tool here because it is call-graph aware: it reports only vulnerabilities the binary can actually reach, so it does not turn into noise.
Suggested direction
Add to the test job (or a small separate job):
- name: Vulnerability scan
run: |
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...Pin the @latest to a version, consistent with this repo's rule that everything pulled from outside is pinned.
Worth considering in the same pass, in decreasing order of value for a project this size:
staticcheck (catches a class of bugs go vet does not, low false-positive rate)- CodeQL for Go, which also gives GitHub's security tab something to show
actionlint for the workflow files
golangci-lint with a large default rule set would probably be more noise than value for a codebase this deliberate about style; staticcheck alone is the higher signal-to-noise choice.
What
.github/workflows/ci.ymlrunsgofmt -l,go vet ./...,go test -race ./...,shellcheck scripts/*.shand the actionmeta test. There is no dependency vulnerability scan and no static analysis beyondgo vet.Why it matters
easySFTP's direct dependencies include
golang.org/x/crypto(the SSH implementation itself) andgithub.com/pkg/sftp. A published Go vulnerability in either would reach every user through the next release without anything in CI noticing. Dependabot updatesgo.mod, but only tells you a version is old, not that the version you are on is vulnerable on a code path you actually call.govulncheckis the right tool here because it is call-graph aware: it reports only vulnerabilities the binary can actually reach, so it does not turn into noise.Suggested direction
Add to the
testjob (or a small separate job):Pin the
@latestto a version, consistent with this repo's rule that everything pulled from outside is pinned.Worth considering in the same pass, in decreasing order of value for a project this size:
staticcheck(catches a class of bugsgo vetdoes not, low false-positive rate)actionlintfor the workflow filesgolangci-lintwith a large default rule set would probably be more noise than value for a codebase this deliberate about style;staticcheckalone is the higher signal-to-noise choice.