How to challenge a Fortify repository access headcount

A Fortify finding often opens with a single large number: the count of people who can reach the source code. The audit measurement treats that population as the licensed seat figure, on the theory that anyone who can touch a repository is a potential Fortify user. The trouble is that the population with repository access is almost always far larger than the population that actually submits code for analysis. Knowing how to challenge a Fortify repository access headcount is the difference between accepting an inflated baseline and rebuilding the count from what the tools actually did.

This article walks through where the repository access headcount comes from, why it overstates the seat figure, and the evidence a buyer assembles to bring it back to defensible ground. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Where the headcount comes from

The repository access headcount is usually drawn from the source control system, not from Fortify itself. An audit team pulls the list of accounts with read or write permission on the repositories under review and proposes that list as the count of Fortify users. It is an attractive shortcut for the vendor because it is easy to extract and it produces a large number. But access permission is a measure of who could, in principle, see code; it says nothing about who used Fortify to scan that code. This is the same conflation we set out in Fortify SCA seat overclaim repository access versus scan submitters, where the gap between readers and submitters is the whole argument.

Why access overstates the seat figure

A modern repository carries far more readers than scanners. Reviewers, product managers, security analysts, auditors, release engineers, and dormant accounts all accumulate read permission over time, and most of them never open a Fortify client or submit a scan. Counting them as seats assumes a usage pattern that the activity logs do not support. The overstatement compounds in three predictable ways:

• Read only roles. People who can view but never scan are counted as though they were active scan submitters, the question developed in can OpenText count repository readers as Fortify users.
• Service and automation accounts. Pipeline identities that exist to move code, not to use Fortify, inflate the list, as covered in CI pipeline service accounts counted as Fortify seats.
• Dormant and departed users. Accounts that retain access long after a person has moved on remain in the export and are counted as live seats.

The evidence that resets the count

Challenging the headcount is an evidentiary exercise, not a rhetorical one. The buyer replaces the access list with a count built from what Fortify recorded. The Software Security Center holds the record of which accounts submitted scans and uploaded results, and the build and source control systems record which contributors triggered those scans. By attributing scans to the contributors whose commits set them off, the buyer arrives at the population of active scan submitters, which is the figure the metric actually licenses. This is the method we develop in reducing a Fortify finding with commit and scan evidence, and it is far more reliable than any permission export.

The work proceeds in a defined order. First, set aside accounts with no scan activity in the review period. Second, remove service and automation identities, which submit on behalf of many people rather than acting as seats. Third, remove dormant and departed accounts. What remains is the distinct active developer population, counted under the applicable metric, whether that is named or concurrent, a distinction we treat in Fortify named user versus concurrent user definitions.

Anchoring the count to the entitlement

The corrected population is only meaningful when it is read against what the buyer actually bought. Before any vendor measurement script runs, the buyer reconstructs its effective license position from purchase records and the applicable terms, so that the active submitter count can be compared to a known entitlement rather than to a vendor assumption. That reconstruction is the subject of reconciling Fortify entitlements before an audit, and it ensures the challenge to the headcount lands against a defensible baseline rather than against the vendor's preferred starting number.

A representative outcome

In a recent engagement, a Fortify finding proposed a seat count taken directly from a source control access export that ran into the thousands of accounts. By replacing the access list with the Software Security Center scan record, attributing scans to the contributors who triggered them, and removing read only, service, and dormant accounts, the buyer rebuilt the count around the developers who actually submitted code for analysis. The defensible figure was a fraction of the access headcount, and the finding settled well below its opening position. The pattern is consistent with our E-02 case file, a technology company whose Fortify developer seat overclaim of $4.5M settled at $0.9M, an eighty percent reduction.

Holding the line on the headcount

The discipline is simple to state and demanding to execute: never accept an access list as a seat count. Repository access is a measure of reach, and the Fortify metric is a measure of use. The two diverge in every estate of meaningful size, and the divergence is correctable from records the buyer already holds. For the wider measurement context, see how OpenText measures Fortify usage in an audit, and for the line by line method of testing each entry, see defending a Fortify developer seat finding line by line.

For the full seat counting methodology, read the Fortify seat counting white paper.