How OpenText measures Fortify usage in an audit

Understanding how OpenText measures Fortify usage in an audit is the foundation of every defensible position on a Fortify finding. The compliance team does not arrive with a neutral count; it arrives with a measurement methodology that, left unexamined, reads the largest plausible number out of the data it collects. The buyer who understands what the vendor measures, where it pulls the data from, and which assumptions are baked into the count can challenge the figure at its source rather than negotiating against a total that was never defensible to begin with.

This article explains the data OpenText typically gathers in a Fortify audit, the metrics it maps that data to, and the points where the measurement overstates the licensed unit. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What the audit collects

OpenText gives seven days notice before an audit and the right to copy relevant records. In a Fortify matter, the records that matter are the ones that describe who uses the analysis tools and how much. The measurement typically draws on the Software Security Center account directory, scan and submission history, project and application inventories, and the deployment topology of any ScanCentral or build server infrastructure. Each of these sources answers a different question, and the vendor's number depends heavily on how those answers are combined. A measurement that treats every console account as a seat, or every scan as a user, is reading the data more aggressively than the entitlement supports. For what the audit actually copies, see what records does OpenText copy in a Fortify audit.

The metrics the data is mapped to

Fortify is licensed against specific units, and the central question in any measurement is whether the collected data has been mapped to the right one. Static Code Analyzer is governed by a developer seat metric tied to the people who submit code for analysis. WebInspect, the dynamic analysis tool, carries its own metric and should never be folded into the SCA count, a distinction we develop in Fortify SCA versus WebInspect licensing compared. The entitlement may express the unit as named users or as concurrent users, and the two produce very different counts from the same data, as covered in Fortify named user versus concurrent user definitions. A measurement that applies the wrong metric to the right data is just as inflated as one that mishandles the data itself.

Where the measurement overstates

Several recurring patterns push the vendor's Fortify number above the defensible figure:

• Access read as consumption. Console accounts that only view dashboards are counted as licensed seats, a trap detailed in Fortify Software Security Center user counting traps.
• Service accounts read as people. Automation and integration accounts appear in the data and are counted as human seats unless the buyer separates them.
• Scan volume read as user count. A large number of scans is treated as evidence of a large user population, when automated scans run from a small number of seats.
• Non production read as production. Test and staging activity is counted into the production figure unless the buyer isolates it.
• Dormant and decommissioned activity retained. Historical accounts and retired projects remain in the count unless the buyer removes them.

Reconstructing against the measurement

The buyer side response is not to argue with the vendor's total in the abstract but to rebuild the position from the same source data, mapped correctly. This is the Reconstruct phase of the method: build the effective license position independently against entitlements and the Additional License Authorizations before any vendor measurement script runs. From the Software Security Center directory, scan history, and project inventory, the buyer assembles an active consumer count under the correct metric, separates non production activity, and removes dormant and decommissioned entries. This work is the substance of reconciling Fortify entitlements before an audit, and it produces a figure the buyer can defend against the vendor's measurement point by point.

A representative outcome

In a recent engagement, the vendor measurement combined the full console directory, total scan volume, and a flat project count into a single developer seat figure that priced at full list. By rebuilding the position from the same source data, the buyer mapped scans to actual submitters, separated service accounts and dormant logins, isolated non production scanning, and removed retired projects. The corrected count was a fraction of the measured total, and the finding settled well below its opening figure, consistent with our E-02 case file in which a Fortify developer seat overclaim of $4.5M settled at $0.9M, an 80 percent reduction.

The discipline of measuring back

The lesson across Fortify findings is that a measurement is a set of choices, and every choice that inflates the number can be tested against the entitlement and the records. The buyer who measures back, using the same data the vendor used but mapping it to the unit the license actually specifies, replaces an aggressive total with a defensible one. For the line by line approach to a developer seat finding, see defending a Fortify developer seat finding line by line.

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