Vulnerability Management for Go
go.dev
go.dev
This is huge! Every existing vulnerability scanner that I've worked with have just looked at go.sum, which ends up reporting a lot of vulnerabilities that you don't actually care about because your code isn't actually linking to the optional transitive dependency that has the vulnerability in it.
Thank you, Go team!
Right now veracode is stuck at go 1.17 support - maybe this will also help being up to date for such vendors more easily
Reinventing supply chain and vulnerability management for each language... not a good use of our time.
In a nutshell, you perform NN operations on the nodes and edges of the graph and then send updates across the graph
Just like every Linux distribution does distributes packages and manages security in a language-agnostic way. Nothing new.
Amazing how people here dismissed my point by downvoting and providing no reasoning.
I guess it sounded like you meant a general solution that wasn’t language specific. I’m still not sure if there’s an abstraction you could use to make language aspects marked as vulnerable - the semantics between languages are just so varied.
Anyway we need the language specific ones first.
No, we have language-agnostic vuln management since decades and a good tool could use a fall back to the traditional method when a language-specific backend is not available.
Every "generic" vulnerability scanner still needs some language specific knowledge for how to determine what is an included dependency. The better you want to suppress false positives, the more in-depth knowledge the tool will need about each language/runtime.
The end result of this is that all the existing generic scanners just use least common denominator heuristics for determining vulnerable dependencies (i.e. just look at the lock file).
For large teams, this can be a huge waste of time patching vulnerabilities that don't actually apply to your code just because the scanning tool is too stupid to know better.
I'll take Govulncheck (and similar tools for other languages) any day over the mediocre generic tools.
Wrong. You can have specialized backends and language-agnostic everything-else.
I have a bit of a bone to pick with this space: I've been working on this problem for a few months now (link to repo[0] and blog[1]).
My background is Application Security and, as is often the case with devs, rage fuels me in my desire to fix this space. Well, Log4Shell helped too.
As another comment said, doing this in a language agnostic way is a big PITA and we haven't fully built it yet. We are using SemGrep to do very basic static analysis (see if vulnerable function is ever imported + called). But we're not doing fancy Inter-process taint analysis like CodeQL can.
(We have a big Merkle tree that represents the dependency tree and that's how we are able to make the CI/CD check take only a few seconds because we can pre-compute.)
Anyway, if you have a second to help, we have a GitHub App[2] that you can install to test this out + help us find bugs. It's best at NPM now but we have basic support for other languages (no dep tree analysis yet).
There are so many edge cases with the ways that repos are setup so just have more scans coming in helps a ton. (Well, it breaks stuff, but we already determined that rage sustains me.)
Thank you. climbs off of soap box
0: https://github.com/lunasec-io/lunasec
1: https://www.lunasec.io/docs/blog/the-issue-with-vuln-scanner...
// The third case is handled by looking to see if any of:
// - reflect.Value.Method or MethodByName is reachable
// - reflect.Type.Method or MethodByName is called (through the
// REFLECTMETHOD attribute marked by the compiler).
//
// If any of these happen, all bets are off and all exported methods
// of reachable types are marked reachable.
See:
But this is even an improvement over any other language I've seen. All just flag CVEs in dependent libraries when 99% of the time it's like "to be vulnerable you have to do [really stupid thing]".
Let's hope that vulnerability scanning vendors adopt using this. For my own stuff or minor work things, it's great. When I fall under the specter of officialness, I'll still get popped by the Enterprise Security Scanning Standard Tool.
Probably the best would be to take the newest from go.sum. That’s what some scanners are doing now.
Filed bugs with 2 vendors over this though.
go list -m allThat seems like a bit of a jump! Maybe there's a better way of building dependency management tooling that doesn't use lock files, it seems strange to tie yourself to this approach just because it's how other tools work.
We don't get the static code analysis feature from Snyk (where vulnerabilities are raised only when they affect us), because this is an optional paid extra. Now we get it for free!
Snyk really need to up their game with their lacklustre Go support to compete with free.
GitHub has this for Dependabot via CodeQL which is a part of their "Advanced Security" package. ($$$, ie "contact us", but I've heard ~$1-1.5k per dev per year roughly)
Other big ones are SonaType, FOSSA, and Snyk (which OP mentioned). There are some smaller vendors too which I can add if anybody is curious.
GitHub CodeQL is by far the best and their tech comes from their acquisition of Semmle/LGTM a few years ago. When I was at Uber, we used Semmle to augment the efforts of the bug bounty and to "scale" our AppSec team to keep up with an ever growing engineering team.
The lack of flexibility with CodeQL and the other proprietary scanning tools is actually the reason why, when I decided to start a security company, I decided to center the company around building publicly on GitHub.
It's harder to make money, at least initially, but it's also the "right" choice to actually push this industry forward. (The thought on how to make money is a hosted SaaS, of course.)
Anyway, I'm happy to answer any questions around this stuff!
govulncheck ./...I spent quite sometime learning golang while using c++ at job, now I pressed the pause button on golang and decided to focus more on modern c++ instead, yeah its tooling is lacking comparing to golang, but it's just so widely used and too good on performance, will revisit Golang later.
https://spectrum.ieee.org/top-programming-languages/
https://www.cleveroad.com/blog/programming-languages-ranking/
https://distantjob.com/blog/programming-languagesrank/
https://statisticstimes.com/tech/top-computer-languages.phpThe IEEE Spectrum one seems independent
It also places all of your trust in the accuracy of the data submitted to govulncheck.
> go.sum… ends up reporting a lot of vulnerabilities that you don't actually care about because your code isn't actually linking to the optional transitive dependency that has the vulnerability in it.
Not a Go dev myself though.
go.mod will exactly tell you what version you have, always. *
* that does not apply if your code is a library; then, other dependency of the "main" app can "update" your dependency. Which sometimes does break things.
However, the go.mod of the main app will deterministically tell what version is used, always.
I never did understand what packages go to go.sum though and what is the logic there. But it is not that important.