How do you reach trustworthy SBOM estate coverage when operators can publish artifacts outside CI?

## The denominator decides everything Coverage is a fraction, and almost every honest failure in this area is a wrong denominator. If you count 'services whose pipelines emit an inventory document' over 'services with pipelines', you get a flattering number that answers a question nobody asked. The number that matters is: **workloads currently running with a current record, divided by workloads the platform says are currently running.** That denominator has to come from outside the ingestion path. A serverless platform knows every deployed function; an orchestrator knows every running image digest; a device-management system knows every firmware version in the field. Those inventories exist for operational reasons and are far harder to bypass than a pipeline convention. ## The gap is a permissions story Consider a platform whose estate is populated from deploy-time events. A function that an operator published by hand from a laptop — during an incident, out of hours, entirely in good faith — runs in production and has no record. This is not carelessness, and it is not rare. It exists because the platform grants a publish permission that bypasses the recorded path, usually deliberately, because someone once needed it at 03:00. So the real question is not 'how do we get better at collecting documents' but 'how many ways can code reach production, and which of them produce evidence'. Enumerating those paths — pipeline deploys, manual publishes, vendor-managed appliances, third-party hosted components, images pulled directly by a team's own automation — is the first piece of work, and it usually finds more paths than anyone expected. ## Choosing the lever There are two families of response and they trade differently. **Make the recorded path the only path.** Withdraw the direct publish permission, or refuse to run an artifact with no estate record. This is the only option that converges, because it removes the source of new gaps rather than chasing them. The costs are real: you need a documented break-glass route that still produces a record afterwards, you need to survive the first incident where the gate is in the way, and you need enough organisational authority to hold the line when a senior engineer wants their laptop workflow back. Attempt it without an exception path and it will be disabled the first bad night, permanently. **Reconcile and attribute.** Continuously diff the platform's inventory against the estate and give every unmatched workload an owner. This is adoptable anywhere, needs no permission changes, and produces useful pressure. It also never finishes: the gap is refilled as fast as it is drained, because nothing stops a new unrecorded publish. The mature answer usually sequences them: reconcile first to find out how big the problem is and who creates it, then use that data to justify closing the path. Going straight to the gate without evidence is how a security team spends its credibility in one meeting. ## Some of the estate you cannot reach Be honest about the parts where neither lever applies: a vendor-managed appliance you do not control, a hosted service whose internals you never see, an acquired business unit on its own platform. These are not coverage failures to be engineered away; they are scope boundaries to be **declared**. An estate that quietly counts them as covered is worse than one that names them as out of scope, because the first produces confident wrong answers. ## What you owe whoever reads the answer The operational output of all of this is a habit: every answer from the estate carries its coverage. 'Twelve workloads match; the estate currently covers 86% of running workloads, and the uncovered set is concentrated in two device fleets and one acquired business unit.' That is what lets an executive, an auditor or a customer weigh the answer correctly — and it is what stops a partial estate from being cited as a clean bill of health. The temptation at this level is to promise the number will reach 100%. It usually should not be the goal. Getting from 60% to 90% is a platform change with a clear payoff; the last few percent is often a handful of systems where the honest move is a declared exception with a named owner and a review date, not an engineering programme that never ships.