CC @bcmills @matloob

While I do quite like this idea, it does introduce an inconsistency: standard library packages would be captured on a per-package basis, while external dependencies are captured only on a whole-module basis.

It's been my experience (as a maintainer of a Go program distributed to users as built executables) that these vulnerability scanners are also prone to overestimate the impact of third-party dependencies, because the tracked information only tracks entire modules even though the official vulnerability database is capable of per-package tracking. So far I've received more reports of false positives where the affected package is not even included in my program than I have seen useful reports that indicate genuine problems^[1].

With that in mind, would it make sense to generalize this proposal to capturing information about all packages that are linked into the program, whether standard library or otherwise? That would then in theory allow these vulnerability scanners to operate at the same granularity as the vulnerability database does, and thus generate fewer false-positives.

On the other hand, I expect that storing all of the package names directly as strings would bloat the metadata quite a bit, especially if stored in addition to the existing module-related information. Some sort of compression might be warranted to exploit the fact that a typical program will have multiple packages belonging to the same module which thus share a common prefix. Perhaps the storage format could extend the existing module metadata in a backward-compatible by pointing to the entries in the table of modules and then only storing the subsequent suffix to concatenate with a module name to produce the full package name. Of course, that could very well be a premature optimization.

^[1] This is admittedly only really true for modules that contain an assortment of thematically-related-but-separate functionality. The golang.org/x/... modules seem to have been a common theme so far because most of them contain a wide variety of different packages where our software uses only a small fraction of that surface area. Maybe those "x" packages are just structured more like the standard library than third-party packages typically are, and so I'm over-generalizing a problem that is specific to those.

If you have the version info for all of the modules used in the binary, and you know which Go release was used to build the binary, you can use go list to determine which standard-library packages it used.

Moreover, just knowing the packages isn't enough for precise vulnerability reporting anyway: really you should analyze the individual symbols, not just the packages.

While I do quite like this idea, it does introduce an inconsistency: standard library packages would be captured on a per-package basis, while external dependencies are captured only on a whole-module basis.

That's true, but the stdlib is sufficiently different (and well-known) that it may deserve this treatment. Most (arguably nearly all) modules are fairly focused on providing a specific piece of functionality; the stdlib is wide-ranging and covers many different things, with essentially every binary only needing a subset of them.
It also (in the foreseeable future, anyway) doesn't make major releases so it can't drop functionality that's now undesirable or difficult to maintain, whereas modules can do this if they have, say, an interface that later turns out to be a problem (e.g. a function that doesn't return an error but eventually turns out that it needs to).

I also don't think this is precise enough to be worth doing, the inclusion of a package doesn't necessarily mean something vulnerable from it was used.
The approach taken by govulncheck seems to be much better.