This seems like a lot of work to identify the vulnerable functions that are called transitively. Could this work be reused to perform tree-shaking, so that Go only compiles the code you actually need? (Or, does Go already do this at compilation?)
See:
// 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.
Basically, if you do certain kinds of reflection, then more code is theoretically reachable and will be included in your binary. In practice, you end up with a large binary in anything that calls into autogenerated APIs.