Summary

Go services shipped as bare binaries in distroless/scratch/chainguard images are currently invisible to fossa container analyze: container analysis is static-only, Go strategies are excluded from the container discovery list, and no binary inspection exists. But Go binaries embed their complete module list (the data go version -m reads), so the dependency data is sitting in the artifact — syft already reads it.

This PR closes that gap end-to-end, prompted by an enterprise customer for whom this is their top-ranked ask (support has a validated repro + escalation context; ask @saramaebee for details):

• millhone: new go_buildinfo parser (pure Rust, no new binary-format crates) for the Go >= 1.18 inline buildinfo format; older/UPX-packed binaries skip gracefully with a debug log. Wired into the existing analyze-container layer walk behind a cheap magic-byte sniff. Output gains an additive discovered_go_binaries field (skew-tolerant in both directions).
• millhone: transparently gunzip layer blobs. Modern docker save emits OCI layout with gzip-compressed layers, which also silently broke JAR-in-container analysis when millhone runs against such archives directly.
• CLI: new App.Fossa.Container.Sources.GoBinary converts discovered modules into real go+path$version locators in per-layer srcUnits, reusing Strategy.Go.Gomod.parsePackageVersion so pseudo-versions normalize to commit hashes exactly like go.mod scans. No backend changes required — this rides the same locator channel go.mod analysis uses.
• CLI: the feature is always-on — no flag. (Earlier revisions gated reporting behind --experimental-enable-go-binary-discovery, but the buildinfo scan runs on every container scan regardless since millhone already walks the layers for JAR analysis, so the flag only gated reporting of the results. Per review discussion we dropped it. Note there is no scan-side opt-out: the gobinary units bypass target/path filters — see the PR comment on filtering for details. This matches how JAR-in-container observations already ship.)
• Docs: new "Container Go binary analysis" section in the container scanner reference (mechanism, Go >= 1.18 + main-module limitations), a mention in the container subcommand reference, a support-table row, and a changelog entry.

PoC scope, deliberately deferred: committed container-tar test fixtures, fourmolu pass, and the pre-1.18 pointer-format encoding.

Test plan

• Rust: 11 tests pass (cargo test -p millhone) — 9 parser unit tests on synthetic buildinfo buffers (replacements, +incompatible, pointer-format skip, truncation, sentinel validation) + 2 updated expected-JSON fixture tests
• Haskell: 7 new GoBinarySpec examples + full Container suite pass (cabal test unit-tests), re-verified after making discovery always-on
• Manual e2e on two repro images containing a Go binary with known modules (uuid v1.6.0, logrus v1.9.3, x/sys pseudo-version):
  • FROM scratch: previously a fully empty scan; now reports go+github.com/google/uuid$v1.6.0, go+github.com/sirupsen/logrus$v1.9.3, go+golang.org/x/sys$c0bba94af5f8
  • FROM cgr.dev/chainguard/static: Wolfi apk system deps and layer placement unchanged, Go modules reported from the app layer
• Backend sanity check that go+ locators with commit-hash revisions resolve as expected on a test project (same shape go.mod scans emit today)

Reproducing it yourself

1. Get the PoC binary

Every push to this PR builds release binaries; download the artifact for your platform from the PR's Build workflow run (Artifacts section at the bottom of the run summary), or:

run_id=$(gh run list --repo fossas/fossa-cli --branch poc/container-go-binary-analysis \
  --workflow build-all.yml --limit 1 --json databaseId --jq '.[0].databaseId')
gh run download "$run_id" --repo fossas/fossa-cli -n macOS-arm64-binaries -D fossa-poc
chmod +x fossa-poc/fossa

(Other artifact names: Linux-binaries, Linux-arm-binaries, macOS-intel-binaries, Windows-binaries.)

2. Build a repro image

Any image containing a Go >= 1.18 module-built binary works. A minimal one:

# Dockerfile
FROM golang:1.25-alpine AS build
WORKDIR /src
RUN go mod init example.com/repro-app \
 && go get github.com/google/uuid@v1.6.0 \
 && printf 'package main\n\nimport (\n\t"fmt"\n\n\t"github.com/google/uuid"\n)\n\nfunc main() { fmt.Println(uuid.NewString()) }\n' > main.go \
 && CGO_ENABLED=0 go build -o /app .
FROM scratch
COPY --from=build /app /app
ENTRYPOINT ["/app"]

docker build -t go-binary-repro . && docker save go-binary-repro -o repro-image.tar

(Swap FROM scratch for cgr.dev/chainguard/static to also see system deps alongside the Go modules.)

3. Run the PR binary

fossa-poc/fossa container analyze repro-image.tar --output \
  | jq '.image.layers[].srcUnits[] | select(.Type == "gobinary") | {Name, Imports: .Build.Imports}'

Expected: a gobinary source unit for the app binary whose imports include go+github.com/google/uuid$v1.6.0.

4. Controls

• PR binary: discovery is always-on — no flag needed; passing the former --experimental-enable-go-binary-discovery flag now errors as an unknown option (it existed only in earlier revisions of this PR, never in a release).
• Official release (brew install fossa or the install script): a plain fossa container analyze repro-image.tar --output of the scratch image reports no source units at all — the status quo this PR fixes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XzWtfpTqJtLyL48WfB35gG