The Scanner Reports 100 Percent Coverage. Coverage of What?

Two numbers with the same name

The figure in front of you reads as complete. It was computed correctly. Every repository the platform was configured to see has a scan attached to it, and the platform is reporting that accurately.

What the figure describes is the configured scope, and it describes it exactly. A platform is engineered to generalize across every organization that installs it, and it inherits whatever boundary the installation drew around it. Enumerating the whole estate has always been work that sits with whoever owns the estate.

So there are two denominators in play. The platform's denominator is the set of repositories connected to it. Yours is the set your organization is accountable for. Where those two agree, the percentage means what it appears to mean at a glance. Where they diverge, the percentage stays exactly as accurate as it was, and it describes a smaller estate than the one your name is on.

Part of that difference is visible from inside the tooling. Coverage views on these platforms list repositories the installation can see but has yet to scan, which is the connected-tenant slice of the gap and the cheapest part of it to close. A tenant outside the installation's reach sits outside the report entirely, and a percentage computed while it sits there looks the same on a slide as a percentage computed against a complete estate. It climbs the same way quarter over quarter too. What separates the two is a second count, taken independently, produced by somebody with reach into the parts of the organization the installation has yet to touch.

Divergence has ordinary causes, and none of them involve anyone doing anything wrong.

• An onboarding project connected the two largest source control tenants and stalled before the third, because the access request sat with a team carrying other commitments
• An acquisition kept its own tenant, and the integration was scheduled twice and deferred twice
• A build system predates the current one and still hosts pipelines nobody wants to disturb
• Contractor organizations were stood up outside the main tenant and outlived the project they were created for
• A language ecosystem in use somewhere in the estate was never included when scope was set, because the team setting it had no reason to know the ecosystem was there

The denominator is field work

A platform has to run against a five repository startup and a five thousand repository bank, and generalizing across both is what makes it worth installing. The information it would need sits outside every system it has been given a route to: a source control tenant it holds no credentials for, a business unit whose existence has not yet reached the security team, an acquisition whose systems are still under negotiation. That material lives in contracts, org charts, acquisition records, and the memory of people who have been there a long time.

Which makes the denominator a piece of field work with an owner, a method, and a date on it. It is the same shape of task as a network asset inventory or a data mapping exercise, and it fails the same way when it gets treated as a side effect of a rollout. Inventory sits at the front of the CIS Critical Security Controls for exactly this reason: they open with an inventory of enterprise assets and an inventory of software assets, ahead of everything that depends on them.

Where the work has no owner, the coverage figure arrives in a dashboard, travels upward through three layers of reporting, and gets acted on. A second source would have to be produced by somebody whose objectives include producing it.

Who should own the denominator, and whether coverage gets reported with its denominator attached, are CWS recommendations. CIS Controls 1 and 2 ask for the inventories and leave the assignment to you. The recommendation is that the denominator belongs to whoever owns the reported number. Split the two and the reporting obligation lands on one team while the enumeration lands on another, and the enumeration loses, because the reporting obligation is the one with a deadline and a meeting behind it. What the enumeration has to reach is unglamorous and finite.

• Every source control tenant, including ones a business unit pays for on its own budget
• The organizations inside each tenant, with archived and template ones marked as what they are
• Systems that arrived with acquisitions, and whether the migration has a date on it
• Wherever build tooling lives, since some of it sits in a system nobody classifies as source control anymore
• A named person per tenant who will confirm the list is complete to the best of their knowledge

A coverage percentage answers a question about configured scope, and it answers it exactly.

What counting roughly 6,300 repositories looks like

The denominator on the one estate CWS has counted came to roughly 6,300 repositories. It was built by enumerating every tenant the organization could be shown to own, then reconciling the contents against ownership records that different teams had maintained to different standards.

The shape of the difference matters more than its size. Repositories that turn up late arrive in clusters: an acquisition, a business unit, a legacy build system, a contractor organization that outlived its project. Cluster structure is what makes them expensive, because a cluster shares properties. One acquisition's repositories share a language ecosystem, a pipeline pattern, a set of conventions, and an owner who reports somewhere else entirely.

That last property is the expensive one. Onboarding a hundred repositories that already sit in a connected tenant and already build through your pipeline is a configuration afternoon. Onboarding a hundred repositories held by a business unit that has never had a conversation with the security team is a governance sequence measured in quarters, and it starts with finding somebody there who will accept the request.

Once a denominator exists, the coverage figure becomes something you can do arithmetic with. Subtract the connected population from the enumerated one and the remainder sorts into categories that carry different costs and different fixes. The original percentage stays exactly what it was. It gains a context to be read in.

Separating those categories is worth the effort, because the cheapest and the most expensive items in the gap look identical while they are still a single count.

• Repositories in a tenant that was never connected, where the fix is access, a change window, and somebody with authority in that tenant
• Repositories in a connected tenant that were never added to scope, where the fix is configuration and an hour from a person who has one
• Repositories with no pipeline, where engineering work has to happen before any tool can be gated on them
• Repositories in an ecosystem the program has not yet decided how to handle, which is a decision before it is a task
• Repositories that are dormant or archived and belong out of the denominator entirely, with the removal written down and dated

What the second number changes

Ecosystem fit is the immediate one. Deciding whether a program covers the languages in the estate requires knowing which languages are in the estate, and that list comes out of the enumeration. Licensing carries a dependency of its own: application security products meter on the contributing developer count or on the volume of code, so the enumeration is what tells you which teams and which codebases a contract has to cover.

The one that arrives with less warning is the audit question. When an audit committee or a regulator asks what proportion of the application estate is under scanning, the dashboard figure answers a narrower question than the one that was asked. The person asking is the one best placed to spot that distinction, and when they spot it in the room it converts into an action item with a name attached. An organization that has enumerated its estate answers the question that was asked and moves to the next item.

Board reporting behaves the same way over a longer horizon. A coverage number that climbs quarter over quarter looks like progress until someone asks whether the denominator moved, and answering that requires a denominator that was established and dated. Enumerate it once and the trend line becomes readable: coverage rose because more of the estate came under scanning, or the estate shrank because dormant repositories were retired, and those are different achievements with different follow-on work.

The tool decision stays where it is. The platform goes on doing the thing it does well, against a scope that is now the right size, and the figure it produces becomes one you can hand an auditor without a footnote. The change sits upstream of the tool entirely. Somebody counted, wrote down what they counted and when they counted it, and got a named person to confirm the list was complete.

Several downstream numbers stop being assertions once the denominator exists.

• Tiering and coverage targets computed against the live repository population, which first requires knowing what that population is
• Triage staffing derived from your own active repository count and observed findings density
• A phased scope where every deferral is written down with the criterion it rests on
• A gap list of repositories with no owner, no pipeline, or no determinable exposure, each one an item somebody can be assigned
• A re-baseline date, because estates move whether or not anybody is counting

Counting the estate is the part that has always belonged to the owner.

Reporting coverage so it survives the next question

Report two figures and the relationship between them. Coverage of connected scope is what the platform reports, and it is exact. Coverage of the enumerated estate is that same figure multiplied by the share of the estate currently connected. Put both in one table, with the second carrying the date its denominator was established and the method used to establish it.

A denominator without a date ages badly. Estates move: a business unit stands up a new organization, an acquisition closes, a migration finally finishes, a team consolidates forty services into one place. Six months is long enough for a count to drift far enough that somebody will find the drift before you do. Put a re-baseline interval against it and the drift becomes a scheduled correction that costs an afternoon.

Arguments about coverage are arguments about units. A monorepo holding forty services counts as one repository or as forty, and both readings are defensible until one of them is written down and applied everywhere. Pick the answer, state it once, and settle it before the first number goes into a deck.

The discipline that holds up under questioning is small, and it comes down to writing decisions down while the reasoning is still in the room.

• The enumerated count, the date it was taken, and the method used to take it
• The unit of work, stated once: how monorepos, forks, mirrors, templates and archived repositories each get treated
• The named person per tenant who confirmed the tenant list was complete, and when
• The threshold at which a newly discovered tenant triggers a re-plan, written as a number so it triggers itself
• Which repositories are deliberately out of scope, and the criterion each exclusion rests on

Report the denominator alongside the percentage and the next question already has its answer attached.