Defending Fortify against an inflated seat baseline

Every Fortify finding starts from a number that purports to describe how many seats the buyer is using. That starting count is the baseline, and because the entire finding multiplies out from it, an inflated baseline contaminates everything downstream: the list price exposure, the back maintenance, and the forward position the vendor proposes. The baseline is the most consequential figure in the whole document, and it is also the figure most often overstated. Defending Fortify against an inflated seat baseline means resetting that starting count to the defensible figure before anything is calculated on top of it.

This article explains how a seat baseline is overstated, why the error compounds, and how a buyer resets the baseline to what the estate actually supports. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Why the baseline drives the whole finding

A finding is not a single number; it is a chain of calculations, and the seat baseline is the first link. The deemed acquisition at list price is applied per seat, the back maintenance is calculated against the seat count, and the forward proposal is sized to the same baseline. An overstatement at the top therefore does not add a fixed amount to the total; it multiplies through every layer. This is why the baseline deserves more scrutiny than any other figure, and why the maintenance tail examined in Fortify perpetual maintenance reinstatement in a finding inherits the baseline's errors wholesale.

How a seat baseline is inflated

The recurring sources of baseline overstatement are well known and individually correctable:

• Repository access counted as seats. The most common inflation is treating everyone with read access as a consumer rather than counting actual scan submitters, the core of the Fortify SCA seat overclaim between repository access and scan submitters.
• Service and integration accounts counted as people. Automated identities inflate the baseline when treated as human seats, drawn from CI pipeline service accounts counted as Fortify seats.
• Decommissioned projects still in the count. Retired work that lingers in the data, the subject of decommissioned Fortify projects still on the audit.
• Non production activity folded into production. Test, staging, and CI scanning read as production demand, covered in how to scope Fortify non production scanning.
• Peak activity read as the steady state. A release window spike treated as the permanent population, examined in Fortify burst scanning and capacity definitions.

Resetting the baseline to the defensible figure

The defensible baseline is the population that genuinely meets the licensed metric, in production, as real consumers, across a representative period. A buyer resets the baseline by working through each inflation source in turn: it removes repository readers who never submitted a scan, strips out service and integration accounts, drops decommissioned projects, scopes out non production activity, and reads the timeline rather than the peak. What remains is the seat count the estate actually supports, and it is consistently and materially smaller than the opening baseline. This reset is the heart of defending a Fortify developer seat finding line by line.

Evidencing the corrected baseline

A reset baseline holds only if it is documented. The buyer reconstructs the figure from its own records: scan history showing who submitted scans, identity directories distinguishing people from service accounts, environment maps separating production from non production, and project inventories marking what is live versus retired. From these the buyer presents a baseline that is verifiable line by line rather than asserted, which is what converts a contested number into a settled one. The evidence approach is set out in reducing a Fortify finding with commit and scan evidence, and the full position is assembled through preparing a Fortify entitlement reconstruction.

How the four Rs reset the baseline

The baseline reset runs through the method end to end. In the respond stage the firm controls the single channel so no raw estate data reaches the vendor before the baseline is built independently. In the reconstruct stage it assembles the scan, identity, environment, and project records and establishes the defensible seat count before any vendor measurement script runs. In the rebut stage it challenges every line of the vendor baseline against that reconstruction, source by source. In the resolve stage the settlement is struck on the corrected baseline and converted forward into an agreement whose seat metric is defined so the next baseline cannot drift. Because the baseline drives the whole finding, the reset is where the largest single reduction is usually found.

A representative outcome

In a recent engagement, a Fortify finding opened with a seat baseline built from broad repository access, a set of automated pipeline accounts, and several decommissioned projects that had never been removed from the data. By resetting the baseline to genuine scan submitters in production, removing the service accounts, and dropping the retired projects, the buyer reduced the starting count dramatically, and every downstream charge fell with it. The matter settled well below its opening figure, consistent with our E-02 case file, where a technology company brought a Fortify developer seat overclaim down by 80 percent. The reduction came not from arguing each charge separately but from correcting the single number they all depended on.

The baseline discipline in one line

Reset the seat baseline to genuine production consumers before any charge is calculated on it, and the whole finding contracts at once. That is how a buyer defends Fortify against an inflated seat baseline. For the comparison that often underlies a disputed baseline, see Fortify named user versus concurrent user definitions, and to reset your baseline with us you can open a case with our team.

For the seat counting methodology behind the baseline, read the Fortify seat counting white paper.