Why would some people even care or look at go.sum where go.mod is clean and self explanatory?
Re:Vulnerability Management for Go
by preseinger on Tuesday September 06, 2022 @07:16PM
(#32744395)
Prior to 1.17, go.mod was not a complete representation of the dep graph. More broadly, the problem is that programmers expect dependency management tooling to have a lock file, see go.sum, and assume it's a lock file. This isn't a problem with those programmers, it's a problem with Go modules.
> This isn't a problem with those programmers, it's a problem with Go modules.
That 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.
go.mod is the lock file.
Re:Vulnerability Management for Go
by preseinger on Thursday September 08, 2022 @03:43PM
(#32770997)
It isn't in the traditional sense. There isn't anything in its specification that guarantees the things that most people expect lock files to guarantee.
Well, I do understand that the actual version used there is ambiguous.
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.
Re:Vulnerability Management for Go
by preseinger on Tuesday September 06, 2022 @07:17PM
(#32744398)
The newest from go.sum isn't reliably the version used in the dep graph. The only way to get that information reliably is via go list. Unfortunately.
Oh, you are totally right. I read that in the GitLab issue tracking their version of the problem and totally forgot that’s where they landed.
Also don't forget that more than one version of a dependency might be compiled into your application!
Re:Vulnerability Management for Go
by preseinger on Thursday September 08, 2022 @03:42PM
(#32770985)
Only one major version. And go considers different major versions to be different dependencies.
not true for go
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.