Entry-Point Runtime — Go

Heuristics the Stella Ops scanner uses to classify a container entry point as a Go binary, plus the evidence it attaches and the edge cases it guards against. For the shared detector contracts, scoring, and calibration, see the Runtime Detector Overview. Go binaries are usually statically linked with distinctive build metadata, so this detector relies on ELF traits rather than package manifests.

Signals to gather

• Statically linked ELF with .note.go.buildid.
• .gopclntab section (function name table) or Go build ID strings.
• Minimal dynamic dependencies (often none) and musl/glibc loader differences.
• GODEBUG, GOMAXPROCS, GOENV environment variables.
• Go module artefacts: go.mod, go.sum.

Implementation notes

• Use ELF parsing to locate .note.go.buildid; fallback to scanning the first few MB for Go build ID.
• Distinguish from Rust/C by checking .dynsym count, presence of Go-specific section names, and the absence of GLIBCXX.
• For distroless images, rely solely on ELF traits since no package metadata is present.
• Record binary path and module files as evidence.

Evidence & scoring

• Strong boost for .note.go.buildid or .gopclntab.
• Add evidence for module files or env variables.
• Penalise binaries with high numbers of shared libraries (likely C/C++).

Edge cases

• TinyGo or stripped binaries may lack build IDs — fall back to heuristics (symbol patterns, text section).
• CGO-enabled binaries include glibc dependencies; still treat as Go but mention CGO in evidence if detected.
• Supervisors wrapping Go services (e.g., envoy) should be handled upstream by the Supervisor detector.

Related

• Runtime Detector Overview — shared contracts, scoring, calibration.
• Entry-Point Runtime — Rust — the other native sibling, distinguished by the absence of .note.go.buildid.
• Entry-Point Runtime — C / C++ — fallback for stripped or CGO-heavy binaries.
• Supervisor detector — multi-service stacks fronting Go binaries.