Go 1.17+ direct requirements are omitted from explicitlyReferencedComponentIds

Summary

For Go modules using a go directive >= 1.17, dependencies explicitly required in go.mod are detected, but are not included in dependencyGraphs[*].explicitlyReferencedComponentIds.

Consumers of Component Detection output therefore classify these direct dependencies as transitive or indirect.

Minimal reproduction

Public reproduction:

https://github.com/octofelickz/component-detection-test/tree/main/go

module github.com/octofelickz/component-detection-test/go-fixture

go 1.23

require github.com/google/uuid v1.6.0

main.go also imports and uses github.com/google/uuid. The default-branch workflow restores the module with Go 1.23 and runs the latest Component Detection release:

https://github.com/octofelickz/component-detection-test/actions/runs/35418002490

GitHub's persisted dependency graph displays github.com/google/uuid v1.6.0 as transitive from go/go.mod.

Expected result

"explicitlyReferencedComponentIds": [
  "github.com/google/uuid v1.6.0 - Go"
]

A consumer should be able to classify the module as direct.

Actual result

The component is present in the graph but absent from explicitlyReferencedComponentIds, so it is submitted as indirect.

Suspected cause

GoModParser.TryRegisterDependencyFromModLine calls RegisterUsage(new DetectedComponent(goComponent)) for every require entry without setting isExplicitReferencedDependency and without checking for // indirect:

https://github.com/microsoft/component-detection/blob/9a7761e95f76e91a585f75616b7ee8a3997c7c87/src/Microsoft.ComponentDetection.Detectors/go/Parsers/GoModParser.cs#L86-L155

For Go versions >= 1.17, the adjacent go.sum is skipped and this parser is the component-registration path:

https://github.com/microsoft/component-detection/blob/9a7761e95f76e91a585f75616b7ee8a3997c7c87/src/Microsoft.ComponentDetection.Detectors/go/GoComponentDetector.cs#L54-L94

The older GoCLIParser already implements the expected distinction, registering modules with Indirect == false as explicitly referenced:

https://github.com/microsoft/component-detection/blob/9a7761e95f76e91a585f75616b7ee8a3997c7c87/src/Microsoft.ComponentDetection.Detectors/go/Parsers/GoCLIParser.cs#L107-L165

go mod graph does not repair the missing metadata. It only adds edges between registered components, and the current relationship parser requires both sides to contain @, while the main module in official go mod graph output has no version:

https://github.com/microsoft/component-detection/blob/9a7761e95f76e91a585f75616b7ee8a3997c7c87/src/Microsoft.ComponentDetection.Detectors/go/Utils/GoDependencyGraphUtility.cs#L34-L85

Suggested fix

When parsing a require entry from go.mod, register it as explicitly referenced unless it is marked // indirect.

Please add tests covering:

1. A direct single-line require.
2. Direct and // indirect entries inside require (...) blocks.
3. The same classifications with Go CLI available and unavailable.
4. GetAllExplicitlyReferencedComponents() output.

The current GoModParser tests verify component discovery but do not assert explicit-reference metadata.

Start with src/Microsoft.ComponentDetection.Detectors/go/Parsers/GoModParser.cs and compare its registration with GoCLIParser.cs. Review the existing GoModParser tests, then cover direct and // indirect single-line and block requirements with Go CLI available and unavailable. Done means GetAllExplicitlyReferencedComponents() marks only direct requirements explicitly and preserves component discovery.