Fortify Audit Workbench access and the seat definition

Audit Workbench is the Fortify client used to open scan results, triage findings, and decide which issues are real. It is a reviewing tool, not a scanning tool, and the people who use it are often a different population from the developers who submit code for analysis. When an audit treats every account that can open Audit Workbench as a licensed seat, it sweeps reviewers, security analysts, and triagers into a count that is meant to license the people who actually run scans. The relationship between Fortify Audit Workbench access and the seat definition is where a finding either holds to what the entitlement licenses or inflates into the reviewing population.

This article explains what Audit Workbench does, why access to it is not the same as a scanning seat, and how a buyer reconciles the two against the entitlement. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What Audit Workbench is for

Audit Workbench opens the results of a scan so that a person can review them. A security analyst uses it to confirm which findings are genuine, a team lead uses it to prioritize remediation, and a developer may use it to understand an issue in their own code. None of these activities is the act of scanning. The work that consumes the analysis engine, submitting source for static analysis, happens elsewhere, and it is that work, not the review of its output, that the seat metric is most often built around. Confusing the two is the same category error we describe in Fortify SCA seat overclaim repository access versus scan submitters, where reach is mistaken for use.

Why reviewing is not a scanning seat

The reviewing population is frequently larger and more varied than the scanning population. Analysts who never write code review findings; managers who never open a scan read summaries; auditors and compliance staff look at results without ever submitting source. Counting all of them as scanning seats assumes a usage pattern the activity record does not support. What the entitlement licenses must be read first, because some entitlements distinguish the scanning role from the reviewing role and some do not, a distinction tied to the role based access question we examine in Fortify SSC role based access and consumer counts.

Reading the seat definition against the entitlement

The defensible count begins with the contract, not the client. The buyer reads the entitlement to establish what the licensed unit actually is: scanning users, named users of the platform, concurrent users, or some other definition. Only then can Audit Workbench access be placed correctly. If the entitlement licenses scanning, then reviewers who never scan are not seats. If the entitlement licenses platform users more broadly, the count is bounded by the metric, named or concurrent, that the contract specifies, as set out in Fortify named user versus concurrent user definitions. Reading the entitlement first is part of reconciling Fortify entitlements before an audit, and it prevents the buyer from accepting a reviewing headcount as a scanning seat figure.

Building the count from evidence

Once the seat definition is clear, the buyer rebuilds the population from records rather than from access lists. The scanning population is established from the Software Security Center scan record and the commit history that triggered each scan, the method in reducing a Fortify finding with commit and scan evidence. The reviewing population is identified by what those accounts actually did, opening results without submitting scans, so that it can be set aside where the entitlement licenses scanning. Service and integration identities are removed as well, consistent with how Fortify integration and API users are counted. What remains is the population the entitlement actually licenses.

A representative outcome

In a recent engagement, a Fortify finding counted every account with Audit Workbench access as a developer seat, which pulled in a large body of security analysts and reviewers who never submitted a scan. By reading the entitlement to confirm that the licensed unit was the scanning population, then separating the accounts that only reviewed results from those that actually scanned, the buyer rebuilt the count around the scanning developers. The corrected figure was substantially below the access based number, and the finding settled well under its opening position, consistent with the reductions we see across Fortify matters and with our E-02 case file, where a developer seat overclaim of $4.5M settled at $0.9M.

Holding the seat definition

The discipline is to let the entitlement, not the client, define the seat. Audit Workbench access shows who can read results; it does not establish who consumes the scanning the metric licenses. Each conflation of reviewer with scanner is correctable from the scan record and the contract, and each correction moves the finding toward the figure the entitlement supports. For the broader measurement context, see how OpenText measures Fortify usage in an audit, and for the line by line discipline, see defending a Fortify developer seat finding line by line.

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