When coming from other programming languages, you are often used to using lock-files. There you have a nice dependency structure with links between packages and their dependencies, even dependencies for dependencies. This is very handy when creating a Software Bill of Materials, for license compliance and for vulnerability scanning.

When coming to Golang, my initial thought was that go.mod and go.sum were Golang’s equivalents to package.json och package.lock. This would mean that go.sum was the file to use for checking dependencies. But it turns out that go.sum is not a lock file (even if I don’t really understand the issue by reading from that link). Thus, programs like dependabot only checks go.mod, not go.sum.

But here is an example scenario which I find problematic:

  • An example application uses github.com/99designs/gqlgen as a dependency
  • gqlgen has andybalholm/cascadia as an indirect dependency
  • cascadia does not show up in my application’s go.mod as an indirect dependency. It only shows up in go.sum.
  • Thus, vulnerabilities in cascadia will not show up in dependabot

This seems like a big hole in the dependency graph. It have tried to understand how that can be, and the answer seems to be module graph pruning. To quote what a dude called Jeff wrote in the discussion thread which ended up in dependabot removing go.sum as a source file

Now with 1.17, those indirect deps that that would be discovered by walking the dep tree, but aren’t actually used in the final binary, get pruned out of the list in go.mod. And then the remaining // indirect deps are listed in go.mod (previously they were optional). So now go.mod can be treated as a definitive source of “here’s all the packages that are required in the final binary, w/o having to walk the dep tree”.

So allegedly, Golang does a good enough job of removing redundant dependencies that this should not be an issue. It does not seems obvious to me how that is handled between different build-tags and so on, but if dependabot trusts go.mod as a complete list of dependencies, then that is probably good enough.