Fortify scan farm and build server license questions

Large Fortify deployments rarely scan from developer workstations. They centralize scanning on a farm of dedicated machines and run it through the build pipeline, so that analysis happens automatically and at scale without occupying a developer's seat. That architecture is efficient, but it confuses an audit measurement that expects to find usage tied to people. The Fortify scan farm and build server license questions turn on a single distinction: whether the centralized scanning infrastructure is counted as licensed seats or recognized as the shared machinery that serves a defined developer population.

This article explains how scan farms and build servers complicate a Fortify finding, the licensing questions they raise, and how a buyer counts centralized scanning defensibly. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Why centralized scanning confuses the count

When scanning runs on dedicated infrastructure, the activity that an audit measures, the volume of scans and the accounts that submit them, no longer maps cleanly to individual developers. A scan farm can produce an enormous number of scans from a small number of service identities, and a build server submits on behalf of the entire organization. A measurement that reads scan volume as a user count, or that treats each scanning node or service account as a seat, counts infrastructure rather than people. This is the same machinery versus headcount problem we set out in CI pipeline service accounts counted as Fortify seats, applied to the scanning tier specifically.

The licensing questions that arise

Centralized scanning raises questions that the entitlement, not the audit measurement, should answer:

• Are scanning nodes seats? The dedicated machines that perform analysis are infrastructure. Whether and how they are licensed is a question of the controller and sensor model, treated in Fortify ScanCentral controller and sensor licensing.
• How is the build server's submission counted? A build server submitting on behalf of the organization is one identity acting for many; the count is the developers served, not the server.
• Does scan volume change the seat count? A high volume produced by a farm does not multiply the developer population, a point developed in Fortify burst scanning and capacity definitions.
• Is non production scanning swept in? Farms often scan test and staging builds, which may fall under different terms, as covered in Fortify non production use and license exposure.

Counting the developers the farm serves

The defensible figure is the population of developers whose code the scanning infrastructure analyzes, counted under the applicable metric. The farm and the build servers are the means by which that population's code is scanned; they are not additional consumers. To establish the count, the buyer attributes scans back to the commits and contributors that triggered them, which the source control and build systems record, and counts the distinct active developers rather than the nodes or the volume. This attribution is the same evidentiary method described in reducing a Fortify finding with commit and scan evidence, and it separates the infrastructure from the people it serves.

Reconstructing the centralized deployment

As with every Fortify line, the buyer rebuilds the position from its own records before any vendor measurement script runs. The deployment topology is documented so that scanning nodes and build servers are identified as infrastructure, the service identities they use are set aside, and the scan history is attributed to the contributor population. The result distinguishes three things the measurement tends to merge: the infrastructure, the automation identities, and the developers. This reconstruction is part of reconciling Fortify entitlements before an audit, and it produces a count that reflects the served population rather than the scanning tier.

A representative outcome

In a recent engagement, a finding counted a scan farm's nodes and the service accounts that drove them as developer seats, and additionally read the farm's very high scan volume as evidence of a large user base. By documenting the deployment topology, identifying the farm and build servers as shared infrastructure, and attributing scans to the contributors whose commits triggered them, the buyer rebuilt the count around the developers the farm actually served. The corrected population was far below the claimed figure, and the finding settled well below its opening number, consistent with the reductions we see across Fortify matters and with the path our E-02 case file followed, where a developer seat overclaim of $4.5M settled at $0.9M.

Holding the infrastructure distinction

The discipline on a centralized Fortify deployment is to keep the scanning tier and the developer population apart. A scan node is not a seat, a build server is one identity acting for many, and scan volume is a measure of throughput rather than headcount. Each conflation is correctable from records the deployment and build systems already hold, and each correction moves the number toward the figure the entitlement supports. For the broader measurement context, see how OpenText measures Fortify usage in an audit.

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