Can OpenText count repository readers as Fortify users

It is one of the most common questions a buyer asks the moment a Fortify finding arrives: can OpenText count everyone with access to the source repository as a Fortify user. The short answer is that it should not, because the license metric ties a Fortify seat to use of the analysis tooling, not to read access to code. But the question deserves a full answer, because the vendor's measurement frequently does exactly that, and knowing why OpenText cannot simply count repository readers as Fortify users is what lets a buyer push the number back.

This article explains the basis for the objection, how the overcount happens, and how to evidence the correct population. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What the metric actually licenses

The Fortify seat metric, as defined in the Additional License Authorizations governing the Micro Focus security products, attaches to the use of the analysis tooling. A user is a person who runs scans or submits analysis, not a person who happens to have read access to the repository the scanner draws from. Repository access is a property of the source control system. It is granted broadly, to engineers, reviewers, product owners, auditors, and contractors, and the overwhelming majority of those people never invoke the analyzer. Counting them as Fortify users measures the wrong system entirely.

Why the overcount happens anyway

The vendor counts repository readers because they are easy to count. A directory group or a source control export produces a clean roster in minutes, whereas actual scan activity has to be pulled from the analysis platform and the build pipeline. Faced with that asymmetry, a measurement defaults to the available proxy and presents it as the seat count. The proxy is convenient for the vendor and systematically unfavorable to the buyer, which is reason enough to challenge it rather than accept it. We treat the specific challenge in how to challenge a Fortify repository access headcount.

Reading access versus consuming the product

The principle extends beyond repository readers. The same logic disqualifies results consumers, the managers and auditors who read findings in Software Security Center without running scans, covered in Fortify Software Security Center user counting traps, and it disqualifies service accounts that exist for integration rather than analysis. In every case the test is the same: did this identity consume the product by running or submitting analysis. If the answer is no, the identity is not a licensable Fortify user regardless of what access it holds.

Evidencing the correct population

To replace the reader roster with the real user population, the buyer reconstructs the seat count from activity records. Scan submission history in Software Security Center, invocation logs in the build pipeline, and processing records from ScanCentral together identify the identities that genuinely used the product. That population is dated and attributable, which means the vendor cannot dismiss it as an estimate. Building it before any vendor script runs is the heart of the reconstruction operation and is covered in reconciling Fortify entitlements before an audit.

A representative outcome

In a recent technology sector engagement, the vendor's finding counted the entire repository access roster as Fortify users. We demonstrated, from the analysis platform and the build pipeline, that only a small fraction of that roster had ever run or submitted a scan. The vendor's own metric, applied honestly, supported the smaller number, and the finding settled at a fraction of its opening figure, in the range we see on these matters. That engagement is the one we record as E-02.

The answer, in full

OpenText can present a repository access roster as an opening position, and it frequently does. What it cannot do is sustain that roster as the seat count when the buyer arrives with dated evidence of actual use and the license metric on its side. The objection is not a technicality. It is the correct application of the vendor's own definition, and it is among the most reliable reductions available on a Fortify finding. For the underlying metric, see what counts as a Fortify developer seat in an audit.

What the vendor can and cannot demand

The objection to counting repository readers is strengthened by understanding the limits on what the vendor may demand. OpenText gives seven days notice before an audit and asserts the right to copy relevant records. Relevant is the operative word. A source control access export is relevant to who can read code, but it is not a measurement of who used the Fortify analyzer, and a buyer is entitled to ask that the records examined actually bear on the license metric in dispute. Providing a repository roster because it was requested, without contesting its relevance to the seat count, is how the proxy becomes the baseline.

The disciplined posture is to cooperate with the audit while insisting that the seat count rest on records that measure use. The buyer supplies, through a single controlled channel, the activity evidence that genuinely bears on Fortify consumption: scan submission history, pipeline invocation logs, and platform processing records. The buyer is not obstructing by declining to treat an access roster as a seat count. It is holding the vendor to its own metric. Compliance is the licensee's responsibility under the agreement, and meeting that responsibility means measuring against the correct unit, not the most expansive one available. A buyer who frames cooperation this way stays squarely inside the audit terms while denying the vendor the substitution that inflates the finding. The result is a record that supports the smaller, evidenced population rather than the broad roster, which is exactly the ground on which these disputes are won.

The lasting principle is that access and use are different facts measured by different systems, and only one of them is the license metric. A repository roster describes who can see code. A Fortify seat describes who ran the analysis. The vendor reaches for the roster because it is convenient, but convenience is not the standard the license sets. A buyer who keeps that distinction sharp, supplies activity evidence through a single controlled channel, and declines to let an access export stand in for a seat count is applying the vendor's own metric correctly. That is not obstruction and it is not aggression. It is the disciplined position from which these findings reliably come down.

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