Where do you mandate SBOM generation across 400 services and artifacts you do not build yourself?

### What the question is really about This is not a tooling question. Across a large estate you will never get one vantage everywhere, so the decision is: what is the default, what are the acceptable fallbacks, who owns each, and how do you keep the resulting unevenness honest. ### The default: build-time, in shared templates Build-time generation wins on fidelity — the resolved dependency graph still exists, direct and transitive are distinguishable, and the document can be bound to the exact build that produced the exact artifact. It loses on reach, because it means touching every pipeline. That is why the delivery mechanism matters more than the choice: put it in the shared pipeline templates rather than asking four hundred teams to add a step. Adoption then follows template adoption, one improvement lands everywhere at once, and a team's opt-out is visible as a template divergence rather than as a silent omission. The platform group owns the generation step; service teams own only what generation cannot infer. ### The first fallback: artifact analysis at the registry Some services will not be on the golden path for years. Scanning artifacts as they arrive in the registry gives you coverage of that long tail immediately, at lower fidelity: you get the OS and packaged layers well, and you miss compiled-in and bundled components entirely. The judgment call is to accept this as *permanently* part of the design rather than as a temporary bridge. Even a fully migrated estate benefits, because the artifact vantage sees the base-image half that a build-time document of the application graph does not describe. ### The second fallback: artifacts you do not build Take a consumer-facing mobile banking application whose release build is performed by an outside agency. You hold no build system, no source tree at release time, and no pipeline to insert a step into. Two moves are available and you need both: - **Contract.** Require an SBOM as a release deliverable, with the release, in a named format, covering bundled libraries and native components. This is where a supplier requirement belongs — it is a commercial control, not a technical one. - **Verify.** Analyse the shipped package yourself: bundled library archives and native objects carry recoverable evidence. Reconcile the two documents. Divergence is a finding about the supplier relationship, not just about the app. Money is the asset here and the attacker position includes anyone holding the device, so a component you cannot enumerate is a component you cannot patch on a deadline. ### Keeping the unevenness honest The most important principal-level move: **record the vantage in the document.** Both major SBOM formats carry creation metadata describing what produced the document, and a mature process makes the vantage explicit and machine-readable. Then a responder handling a critical advisory at 02:00 can tell the difference between "this service has no affected component" and "this service's document could never have shown that component". Without that, you have built an estate-wide inventory whose reliability varies by a factor you cannot query. A practical tiering: tier 1, build-time plus artifact analysis, merged; tier 2, artifact analysis only; tier 3, supplier-provided, verified by sampling. Publish which tier each service is in and treat promotion between tiers as the roadmap. ### Sequencing and measurement Sequence by blast radius, not by enthusiasm: internet-facing services, then anything handling money or regulated data, then the rest. Willing teams are the easiest to convert and the least useful to convert first. Measure the share of production releases that ship with an attached document. Counting documents produced rewards re-running generators; counting releases covered rewards the thing you want. Add a second metric later — the share of documents produced by the highest-fidelity vantage — so the tiering visibly improves rather than stalling at "everyone has something". ### What to concede in the interview Do not claim uniformity is achievable. The strong answer names the fidelity gradient explicitly, argues for making it legible instead of pretending it away, and is clear about who funds each part: the platform team funds the default path, service teams fund declaring what generation cannot see, and procurement funds the supplier requirement. A candidate who says "we mandate build-time generation everywhere" has not run an estate this size.