Should every service build under GOFIPS140 and run with fips140=only, or only the regulated one?

## The decision, stated plainly There are two coherent positions and a lot of incoherent middle ground. Position one: every artefact in the fleet is built with `GOFIPS140` set and runs with `GODEBUG=fips140=only`, so there is exactly one build recipe and no chance of shipping the wrong variant into a regulated slot. Position two: only the services inside the audited boundary get that treatment, and everything else builds normally. Both are defensible; which is right depends on facts you have to go and get rather than reason about from first principles. ## What decides it **Where the audit boundary actually runs.** This is not an engineering decision. A compliance or security officer defines the scope of the assessed system, and if their scope statement covers a service you left `off`, that service moves inside regardless of how inconvenient it is. What remains yours is the implementation: which snapshot is pinned, how strict mode is rolled out, how the evidence is captured. Getting that division wrong — deciding scope yourself and presenting it as a technical fact — is the failure mode that gets a lead overruled late and expensively. **The blast radius of strict mode across shared code.** This is the argument against the fleet-wide position and it is concrete. Internal libraries are full of legitimate non-security digests: an ETag from MD5, a SHA-1 cache key, a checksum pinned by an old wire format. Under `fips140=only` those stop working, some of them by panicking rather than erroring, in services that were never in scope. You have converted a compliance requirement into an availability risk for unrelated systems. **The cost of two variants.** Two artefacts to build, sign, store and roll back, a test matrix that runs both, and the possibility that a bug reproduces in only one of them. That is a real tax, and it is the argument for the fleet-wide position. It is worth paying when one service out of twenty is regulated. It stops being worth it when most of the fleet is in scope: at that point a single recipe is cheaper than the divergence. **Toolchain coupling.** A pinned snapshot ties the regulated build to a specific validated version of the Go Cryptographic Module. When the toolchain moves, somebody has to decide whether the pinned version is still shipped and still covered. Applying that coupling to every service in the organisation means every upgrade drags that question along with it. ## The position I would actually take, and why Scope to the boundary, and build the bridge in CI. - Regulated services build with a **pinned** `GOFIPS140` version. Not `latest`: `latest` enables the mode but compiles the toolchain's current cryptographic source, which carries no external validation and changes under you with each release. Pinning is the difference between "we run FIPS mode" and "we run this validated module version", and only the second is an answer to an auditor. - Those services run `GODEBUG=fips140=only`, introduced through a canary instance rather than a fleet flip, because some rejections are panics. - Everything else builds `off`. - **Shared libraries carry a required check** that runs their tests under `GODEBUG=fips140=only`. This is the load-bearing piece. It costs one CI job per library, and it moves the failure from a regulated service's production traffic to the library author's pull request. Without it, the two-variant policy quietly rots: someone adds a SHA-1 checksum to a common package and nobody finds out until the regulated service redeploys. - **Evidence is mechanical.** The release pipeline records `go version -m` output for the shipped artefact, which carries `GOFIPS140=<version>` and `DefaultGODEBUG=fips140=on`. An assertion in a runbook is not evidence; a setting stamped into the binary is. ## What I would not claim That the mode certifies anything by itself. It selects and enables a module that has been through validation and constrains what the standard library will do. It does not constrain vendored or hand-rolled cryptography compiled into the same binary, and it says nothing about key management, operational procedure, or the rest of what a regime asks for. Overstating this in a design document is how a team ends up surprised in an assessment, and it is the claim a reviewer should push on hardest. ## Revisiting the call Write down the trigger for reconsidering: if the share of services inside the boundary crosses roughly half the fleet, or if the shared-library CI check starts failing often enough that people route around it, the two-variant policy has stopped paying for itself and one recipe becomes the cheaper answer. A decision with no stated reversal condition is the one nobody revisits until it hurts.