[kfeofantov]

Go 1.25 made the runtime size GOMAXPROCS from the cgroup CPU quota
(containermaxprocs) and follow a quota that changes under it
(updatemaxprocs). Which behaviour a binary gets follows from the main
module's go directive, not from the toolchain that compiled it — so
go_build.go_version, which is the toolchain, does not separate a build that
reads the quota from one that counts the node's cores. Today the first-hour
finding fires on both, and the fleet where it is wrong is the fleet that already
did the work. ADR 0047's Context states the pre-1.25 runtime as the runtime;
ADR 0050 corrects it there rather than editing an accepted body.

What ships. The node parses the toolchain's compound DefaultGODEBUG build
setting and keeps those two names, as go_build.godebug. The parse happens
before the node→controller channel, so nothing outside the list crosses the wire.

Why parsed and not allow-listed whole. The compound value carries every
deviating setting — six for a module on go 1.21, mostly TLS, net/http and
go/types. Keeping it whole would ship all of them, then drop the value against
ADR 0019's 128-character bound, which lands on long lists, which are the old go
directives, which are the only builds this field exists to find. The failure mode
would be silence on exactly the population the finding is about.

Ceilings. security.md 930 → 940, backend-requirements.md 460 → 475, with
the reason in prose_test.go: an absent name means the build takes its
toolchain's default, not 0, and that obligation does not fit a table row.

No new RBAC, no new read, no new privilege — DefaultGODEBUG is in build info
the scanner already opens.

Evidence:

go test -race ./...   # green
make lint             # 0 issues

The -update run touched one golden (go-build.golden.json) and no other.

🤖 Generated with Claude Code

https://claude.ai/code/session_011YRKuL97KRndaopfpixrhp