Fortify SCA seat overclaim: repository access versus scan submitters

Almost every inflated Fortify finding begins with the same substitution. The vendor cannot easily see who actually runs a static analysis scan, so it measures something it can see instead: the list of people with access to the source code repository the scanner reads from. That headcount is far larger than the population of engineers who genuinely submit scans, and the gap between the two numbers is where a Fortify SCA seat overclaim is manufactured. Understanding the difference between repository access and scan submission is the single most valuable thing a buyer under a Fortify audit can learn.

This article walks through how the substitution happens, why it does not hold up against the license metric, and how a buyer reconstructs the defensible number. It pairs with our Fortify and AppSec audit defense practice and the broader complete OpenText audit defense playbook for 2026.

What a Fortify SCA seat actually licenses

Fortify Static Code Analyzer is licensed by the people who use it to analyze code, not by the people who can read the code being analyzed. Those are different populations and they rarely overlap cleanly. A modern source repository grants read access to product managers, designers, security reviewers, auditors, contractors, and service accounts that never invoke the scanner. Only a subset of engineers actually translate, scan, and submit results into the analysis pipeline. The license follows that subset.

When a measurement counts everyone with repository access and treats each of them as a consumed SCA seat, it is counting an entitlement that was never used. The right unit is the active scan submitter: the identity that has actually run an analysis or pushed results into Software Security Center within the measured window. Everything else is noise that inflates the opening finding.

How the overclaim is constructed

The pattern is consistent across engagements. A measurement script or self disclosure questionnaire pulls a roster from the source control system or from the directory group that grants repository access. That roster becomes the claimed seat count. Because it is sourced from access rather than activity, it sweeps in:

• Engineers who read code but never run a scan.
• Reviewers, product owners, and analysts with read only access.
• Service and automation accounts that exist for integration, not for human analysis.
• Former staff whose directory entries were never deprovisioned.

Each of those rows is a candidate for removal. The vendor presents the total as if it were measured consumption, but it is a proxy, and a proxy that systematically overcounts. The defense is to replace the proxy with evidence of actual scan activity.

Reconstructing the defensible seat count

Reconstruction is the second of the four operations we apply to every engagement, and on a Fortify matter it is decisive. Before any vendor script runs, we build the effective license position independently from the systems that actually record analysis activity. Software Security Center holds scan submission history. Build pipelines hold the record of which jobs invoked the analyzer. ScanCentral records which controllers and sensors processed work. Together these sources produce a list of identities that genuinely consumed the product, dated and attributable.

That list is almost always a fraction of the repository roster. We then map each claimed seat to evidence. A seat backed by scan submission stays. A seat backed only by repository access is challenged and, in most cases, removed. The output is an active developer population that the buyer can stand behind line by line, which is exactly what our note on documenting Fortify active developers for a rebuttal describes in detail.

Why the license language supports the buyer

The Micro Focus products that OpenText now audits are governed by Additional License Authorizations, the document set that defines each product metric. Where the authorization for SCA ties the seat to use of the analyzer, a population defined by repository read access is the wrong measurement, not merely a generous one. The buyer is not asking for leniency. The buyer is asking the vendor to apply its own metric definition, which is the strongest position available in any audit.

This is also why a clean entitlement reconstruction matters before the conversation turns adversarial. When the buyer arrives with a dated, evidence backed submitter list and the vendor arrives with a directory export, the burden shifts. Our note on how to challenge a Fortify repository access headcount covers the specific objections that move the number.

A representative outcome

In a recent technology sector engagement, the vendor opened with a developer seat overclaim built almost entirely from repository access rosters. We mapped the claimed seats against actual scan submitters recorded in the analysis platform and the build pipeline. The population that had genuinely run scans was a small fraction of the roster the finding relied on. Reconstructing the effective position around real submitters, and removing service accounts and read only identities, reduced the finding from its opening figure to a settlement at roughly one fifth of the claim, a reduction in the range we see consistently on seat overclaim matters. This is the case we file as E-02, and it follows the same path every Fortify seat dispute takes.

What to do when the finding lands

Do not accept the roster as the seat count and do not let a vendor script run before the position is reconstructed. The roster is a starting assumption, not a measurement, and treating it as final concedes the most valuable ground in the audit. Preserve the records that prove activity, route all vendor contact through a single controlled channel, and build the submitter list from your own systems first. For a deeper treatment of the metric, see what counts as a Fortify developer seat in an audit and the broader picture in how OpenText measures Fortify usage in an audit.

Why the first seven days decide the seat count

The window in which a buyer can reframe a Fortify seat overclaim is short. OpenText gives seven days notice before an audit and asserts the right to copy relevant records, which means the vendor will move quickly to establish a roster as the baseline. If that roster becomes the agreed starting point, every later argument about scan submitters is uphill, because the buyer is then disputing an accepted number rather than setting it. The Respond operation exists to prevent that. We take over first contact, agree scope, sign an appropriate confidentiality arrangement, and route everything through a single controlled channel so that no roster reaches the vendor as a concession before the position is reconstructed.

Inside that window the priority is preservation, not disclosure. Scan submission history, build pipeline logs, and platform activity records are the evidence that will later replace the access roster, and they must be captured before systems are reconfigured or logs rotate out. A buyer who preserves the right records in the first week arrives at the reconstruction with everything needed to draw the line between repository access and genuine scan submission. A buyer who waits often finds the most useful evidence has aged out, which hands the vendor the proxy by default. The discipline of the early days is therefore directly responsible for how far the seat count can fall later, and it is the reason we treat first contact as the most important phase of the whole engagement rather than an administrative preliminary. The broader sequence is set out in the complete OpenText audit defense playbook for 2026.

You can also download our briefing on Fortify seat counting for the full methodology. Read the Fortify seat counting white paper.