Documenting Fortify active developers for a rebuttal

The single most effective move in a Fortify seat dispute is to document who actually uses the tool. Findings inflate when the audit team counts everyone with access, every account ever created, and every name in a directory as a licensed developer seat. The rebuttal answers with evidence: a documented population of active developers, separated cleanly from passive access, dormant accounts, and service identities. Documenting Fortify active developers for a rebuttal is the work that turns an assertion about headcount into a defensible number.

This article explains which records prove real usage, how to separate access from scanning, and how the documentation drives the finding down. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Why active use is the right standard

A developer seat is meant to capture a person who uses the tool, not a person who could in principle log in. The audit team's opening count almost always rests on access rather than use, because access is easy to export and use takes evidence to establish. The rebuttal reverses that. It defines the seat by actual scanning activity and then documents that activity person by person. The distinction between access and use is the central trap on this track, examined in Fortify SCA seat overclaim repository access versus scan submitters.

Which records prove real usage

The documentation rests on records the buyer already holds:

• Scan submission logs. The clearest evidence of an active developer is a record of scans they submitted within the measured window.
• Commit and build records. Where scans run from a pipeline, commit and build history ties activity to real contributors, examined in reducing a Fortify finding with commit and scan evidence.
• Account status records. Disabled, expired, and never activated accounts come out of the count, as do the service identities covered in CI pipeline service accounts counted as Fortify seats.
• Role and access mapping. Readers and reviewers separate from submitters, a distinction developed in Fortify Software Security Center user counting traps.

Separating access from scanning

The core of the rebuttal is the separation of passive access from active scanning. Many accounts in Software Security Center belong to people who read findings, managers who review dashboards, or auditors who never submit a scan. None of these are developer seats under a metric that counts scan submitters. The buyer documents the submitter population from scan logs and then documents everyone else as the non submitting population they are. The number that survives is the active developer count, and it is consistently smaller than the access based count the finding opened with. This is the heart of how to challenge a Fortify repository access headcount.

Building the documentation before the script runs

The reconstruction happens before any vendor measurement script runs. The buyer pulls scan history, maps each scan to a real person, sets aside service accounts and disabled identities, and assembles a documented roster of active developers with the evidence attached. Doing this first means the buyer controls the count and the framing, rather than reacting to a number the vendor has already published. This is part of reconciling Fortify entitlements before an audit.

How the documentation drives the number down

Once the active developer roster exists, the rebuttal is arithmetic. Each name on the audit team's list either has scanning evidence behind it or it does not. Those with evidence stay; those without move to the non submitting population. The finding cannot survive its own list once the list is tested against use, and the corrected count flows directly into the settlement. The line by line method is set out in defending a Fortify developer seat finding line by line.

A representative outcome

In a recent engagement, a finding counted every account in Software Security Center as a developer seat, producing a headcount far above the team that actually scanned code. By documenting the active developers from scan submission logs, separating readers, managers, and service accounts, and removing disabled identities, we reduced the seat count to the population with real scanning evidence behind it. The finding settled well below its opening figure, consistent with the path our E-02 case file followed, where a technology company brought a Fortify developer seat overclaim down by 80 percent.

The rebuttal in one line

Prove use, not access; document the submitters, set aside everyone else, and let the evidence set the count. That is how documenting Fortify active developers turns a headcount assertion into a defensible position. For the broader measurement context, see how OpenText measures Fortify usage in an audit, and to build the documentation with us you can open a case with our team.

How the four Rs turn evidence into reduction

Documentation is the engine of the rebut stage in our method. The reconstruct stage assembles the scan and commit evidence into an active developer roster, independently and before any vendor script runs. The rebut stage then tests every name on the audit team's list against that roster, moving accounts without scanning evidence into the non submitting population where they belong. The resolve stage carries the corrected count into the settlement and converts forward into an agreement with a defined seat metric. Each stage depends on the documentation, which is why assembling it early, while the records are intact, is the highest leverage move a buyer can make.

Common objections and how the records answer them

The audit team has standard objections, and the records answer each. If the response is that an account could scan, the roster answers with whether it did. If the response is that access implies use, the scan logs answer with actual submissions. If the response is that service accounts represent users, the configuration answers with the automation they belong to. If the response is that disabled accounts were active earlier, the status history answers with the dates. In every case the objection is rhetorical and the record is factual, and a rebuttal built on documented activity holds where one built on argument alone does not.

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