Defending a Fortify developer seat finding line by line

A Fortify developer seat finding rarely survives close reading at the figure it opens with. The number is built by counting accounts and activity in aggregate, and aggregation is where defensible seats and indefensible ones get bundled together. The work of defending a Fortify developer seat finding line by line is exactly that: taking the count apart entry by entry, testing each claimed seat against the question of whether that person actually submits code for analysis, and removing everything that fails the test. Done carefully, the line by line method converts a large opening figure into the much smaller count the entitlement supports.

This article sets out the line by line approach to a developer seat finding, the categories that fall away under examination, and the evidence that holds the corrected count in place. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What a developer seat actually is

The Fortify developer seat metric is tied to the people who submit code to Static Code Analyzer, not to everyone who can reach the console or view a result. That distinction is the whole defense. A finding inflates by counting repository access, dashboard viewers, and automation as though each were a code submitting developer. The corrected count is the population that actually exercises the analysis capability, a definition we set out in what counts as a Fortify developer seat in an audit and in Fortify SCA seat overclaim repository access versus scan submitters.

The lines that fall away

Reading the count entry by entry, several categories routinely fail the submission test and should be removed:

• Read only viewers. Stakeholders who view dashboards and reports but never submit code are not developer seats, a point developed in Fortify Software Security Center user counting traps.
• Service and pipeline accounts. Automation that submits scans on a schedule is machinery, not a human seat, as covered in CI pipeline service accounts counted as Fortify seats.
• Dormant accounts. Logins that never authenticated in the measured window, or that belonged to people who have left, are not active developers.
• Duplicate identities. The same developer often appears under more than one account across directory changes, double counting a single seat.
• Non production only users. People who only operate against test and staging environments may fall under different terms, treated in Fortify non production use and license exposure.

The evidence that holds the line

Each removal has to rest on records the buyer can produce, because a rebuttal that asserts a smaller number without backing it invites the vendor to restore the original figure. The supporting evidence comes from the buyer's own systems: scan submission logs that show who actually submitted code, authentication records that show last login dates, directory exports that reveal duplicates, and environment tags that separate production from non production. Building this evidence is the work of documenting Fortify active developers for a rebuttal, and it is what turns a line by line argument into a defensible position rather than a negotiating stance.

Sequencing the rebuttal

The order of operations matters. The buyer first reconstructs the effective license position independently, before any vendor measurement script runs, so that the corrected count exists as the baseline rather than as a reaction to the vendor's total. From that baseline, the rebuttal proceeds line by line: present the active submitter population, then account for each excluded category with its supporting evidence. This sequencing reflects the Reconstruct and Rebut phases of the method, and it keeps the burden where it belongs, on the defensibility of the metric rather than on the buyer's willingness to settle. The reconstruction itself is described in reconciling Fortify entitlements before an audit.

A representative outcome

Our E-02 case file is the clearest illustration of the line by line method at work. A technology company faced a Fortify developer seat overclaim priced at $4.5M, built by counting repository access and console accounts as code submitting developers. By mapping actual scan submitters, removing read only viewers, service accounts, dormant logins, and duplicates, and isolating non production only users, the active developer population proved far smaller than the claimed count. The finding settled at $0.9M, an 80 percent reduction, with every removed line supported by submission and authentication records.

Why the line by line method works

The strength of the approach is that it never asks the vendor to accept a smaller number on faith. Each line is removed for a stated reason, backed by a record, and tied to the metric the entitlement actually specifies. A finding built on aggregation cannot withstand that scrutiny, because aggregation hides exactly the distinctions the metric depends on. For the measurement context behind the finding, see how OpenText measures Fortify usage in an audit.

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