The Board Has Your Application Count. Source Control Returns a Different Number.

Two counts, two different questions

The number went into the board pack because someone asked how many applications the business runs. The portfolio has a row per application, the rows were counted, and the count was correct for the question. Then an inventory ran across source control and came back with a figure that has no visible relationship to it.

Both counts measure something real. They measure different objects. An application is something the business names, funds, and assigns a sponsor to, and it exists because approval needs a line item. A repository exists because a team needed somewhere to put code, and teams have made that decision hundreds of times over a decade, each time as an engineering convenience.

The CIS Critical Security Controls open with an inventory of enterprise assets and an inventory of software assets. Where a source repository fits in that scheme is left to the organization, so the choice of unit got made informally, by different people, at different times. The divergence follows from it.

The gap opens for structural reasons, and each of them is a decision that made sense to the person who took it.

• One funded application decomposes into a web front end, a set of backend services, a shared client library, and the infrastructure code that stands it all up
• Mobile builds carry a repository per platform, and the release tooling around them carries more
• Acquisitions arrive with their own source control tenant, which stays live for years after the integration is declared finished
• Shared libraries and internal packages belong to no single application in the portfolio, because they belong to most of them
• Contractor organizations, forks, mirrors, and archived repositories accumulate, and each one stays until someone is given the job of removing it
• A monorepo split into forty services moves the repository count by thirty nine and the portfolio count by zero

The board is asking about the first number

The instinct is to walk in with the new figure and an explanation of where it came from. That order fails, because the live question in the room is about the earlier number. A board that hears a revised count wants to know whether the original was wrong, whether anyone knew at the time, and which of the other figures in front of them are now in doubt. Answer the arithmetic while leaving that hanging and you spend credibility the program will need in the next funding cycle.

People remember the figure and lose the qualification attached to it. A number presented once as an approximate portfolio count comes back two quarters later as the number of applications we have, quoted by someone who was in the room and meant no harm by it. That is what a deck does to a number. The qualification lives in the speaker's voice, and the slide keeps only the figure.

So the reconciliation has to exist before the conversation does. What earns the room back is the mapping between the two counts: where every repository sits relative to the portfolio, and a stated reason for the ones that sit outside it.

A board that hears a revised count is asking which of your other numbers are now in doubt.

The reconciliation is the deliverable

Every repository resolves into one of a small set of categories. Some map onto an application the portfolio already names. The others map onto shared code, infrastructure, inherited tenants and archives, and naming those categories turns a discrepancy into a structure someone can follow.

CWS counted one application security estate end to end, and it came to roughly 6,300 repositories. The count on its own settled nothing. What made it usable was the classification underneath it: live code or not, an owner, an exposure, and whether a business sponsor could name the application it belonged to.

Work the categories in the order that removes volume first. A smaller residual is easier to defend line by line, and the residual is where the questions land.

• Repositories that map cleanly to a named application, reported with the repositories-per-application ratio, which is the first thing the room will ask for
• Shared libraries and internal packages consumed across several applications, which need an owner independent of any one of them
• Infrastructure and pipeline code, absent from the portfolio and holding the credentials that reach production
• Repositories inherited through acquisition, sitting in a separate tenant, still building
• Archived and dormant repositories, dated, with a stated retention position so they stop inflating the headline
• Repositories with no determinable owner, which is the line that will draw the most attention and deserves it

Present both numbers and say what each one governs

Keep the portfolio count. It is the right unit for what a board governs: which business capabilities exist, what they cost, who sponsors them. Add the repository count beside it as the denominator for security coverage, and say plainly that this is the figure the program will be measured against from here.

The framing that holds is that both counts answered the questions actually put to them, and the newer one is finer. Both statements are true, and a true statement holds up when a note-taker repeats it two quarters later. Calling the earlier count wrong invites a follow-up about what else is wrong, and it describes the situation inaccurately anyway.

One point of view rather than a finding: the reconciliation lands better when the person who gave the original number is the one who brings it. Sending someone else reads as distance from the problem, and distance is the thing under examination. Whether the counting rules get fixed in writing before the meeting is a CWS recommendation too. CIS Controls 1 and 2 ask for the inventories. They leave the unit, and the messenger, to you.

Put five items in front of them and let the two numbers sit next to each other on the same page.

• The portfolio count, unchanged, with the date it was produced and the question it answered
• The repository count, with its collection date, the tenants covered, and the tenants known to sit outside the collection
• The category breakdown, so the difference is accounted for line by line, with every part of it attached to a category
• The subset phase one covers, with the selection criteria written out, because the coverage question follows within a minute
• The re-baseline date, since a count with no refresh cycle goes stale the same way the first one did

One sentence survives being repeated back to you in six months: the measurement got finer, and the estate is the same size it was yesterday.

What the second number changes about reporting

A single number in a deck gets repeated until somebody challenges it. Two numbers with a documented relationship between them can absorb the challenge, and that is what you want standing behind the program for the next three years.

Decide which number appears where, and write the decision down. Coverage percentages, tiering, and triage staffing all run off the repository count. Portfolio risk ratings, business ownership, and spend run off the application count. A metric that mixes the two produces a coverage figure that resists reproduction, and someone will eventually try to reproduce it while looking for a different answer.

Then give the reconciliation an owner and a cadence. Repositories are created every week, so the mapping starts decaying the day it is built. A quarterly refresh against the same collection method keeps the two counts tied together, so the next divergence arrives as a variance you report on your own schedule.

The definitional piece is the cheapest one and the easiest to postpone. Write down what counts as a repository for this program. Two competent people can read the same estate and produce counts that differ by a multiple, and written rules are what keep that disagreement out of the board pack.

• Name the owner of the reconciliation by role, and put its refresh on the same cadence as the risk report
• Fix the counting rules in writing: monorepos, forks, mirrors, archived repositories, and internal tooling each get a stated treatment
• Keep the collection method stored with the data, so the next refresh is comparable to this one
• Report the residual openly: the tenants nobody has read access to yet, and what it would take to get it
• Record who approved the rules and on what date, so the next revision is a change with a history behind it

The count is a deliverable only once somebody else can run it again and get the same answer.