What counts as a Fortify developer seat in an audit

When a Fortify audit lands, the first argument is almost always about the definition of a single word: seat. The vendor has one working definition, the buyer often has another, and the distance between them is the finding. Knowing precisely what counts as a Fortify developer seat in an audit is therefore not a pedantic exercise. It is the foundation of the entire defense, because every dollar in the claim is the seat count multiplied by a price.

This article sets out the definition that holds, the populations that get wrongly swept into the count, and the evidence that settles the question. It supports our Fortify and AppSec audit defense work and links up to the complete OpenText audit defense playbook for 2026.

The definition that holds

A Fortify developer seat licenses an individual who uses the Fortify tooling to perform application security analysis. For Static Code Analyzer that means an engineer who runs scans or submits analysis results. The seat attaches to use of the product, not to membership in a team, not to access to a code repository, and not to the existence of a directory account. This is the definition embedded in the Additional License Authorizations that govern the Micro Focus security portfolio, and it is the definition a buyer should hold the vendor to.

The populations that get wrongly counted

Findings inflate by treating adjacent populations as if they were developer seats. The most common are:

• Repository readers. People who can see source code but never invoke the analyzer. This is the largest source of overcount and the subject of our note on whether OpenText can count repository readers as Fortify users.
• Service and automation accounts. Identities created for integration and pipeline orchestration, not for human analysis. We cover these in CI pipeline service accounts counted as Fortify seats.
• Consumers of results. Managers, auditors, and reviewers who read findings in Software Security Center but never run a scan. See Fortify Software Security Center user counting traps.
• Inactive and departed staff. Directory entries that were never deprovisioned and projects that were retired.

Named user and concurrent user are not the same seat

A second definitional trap sits underneath the first. Fortify entitlements can be expressed as named users or as concurrent users, and the two count very differently. A named user model attaches the license to specific individuals. A concurrent model attaches it to simultaneous use. A finding that prices a concurrent entitlement as if every named individual needed a seat doubles the exposure. We pull this apart in Fortify named user versus concurrent user definitions, and it is a routine line of rebuttal.

The evidence that settles the question

Because the seat attaches to use, use is what the buyer must evidence. The authoritative sources are the systems that record analysis activity: scan submission history in Software Security Center, invocation records in the build and continuous integration pipeline, and processing records from ScanCentral controllers and sensors. From these, a buyer assembles a dated list of identities that genuinely consumed the product. That list is the seat count. Everything outside it is challengeable.

This reconstruction is the second of our four operations and the most decisive on a Fortify matter. We build the effective license position from the buyer's own systems before any vendor script runs, so the negotiation starts from evidence rather than from a directory export. The mechanics are in reconciling Fortify entitlements before an audit.

A representative outcome

In a recent engagement in the technology sector, the vendor defined the developer seat count as the full roster of repository access, then priced every row at list. We reconstructed the population around actual scan submitters and removed service accounts, results consumers, and departed staff. The defensible developer seat count came in dramatically lower than the claim, and the finding settled at a fraction of its opening figure, consistent with the reductions we see on seat definition disputes. That matter is the one we record as E-02.

Holding the line

The definition of a developer seat is not the vendor's to set unilaterally. It is set by the license metric, and the metric ties the seat to use. When a buyer arrives with dated evidence of who actually ran the analyzer, the conversation moves from the vendor's roster to the buyer's record, and the number falls. For the line by line approach, see defending a Fortify developer seat finding line by line.

The objections a buyer should be ready for

When a buyer reconstructs the developer seat count around real scan activity, the vendor raises a predictable set of objections, and being ready for them is part of holding the definition. The first is that anyone with repository access could in principle run a scan, so the access roster represents potential use. The answer is that the license meters actual use, not theoretical capability, and a seat that was never consumed is not a seat that was licensed. The second objection is that the activity records are incomplete, so the access roster is the safer estimate. The answer is that an incomplete record understates use at worst, which favors the vendor, and that the burden of a precise measurement sits with the party asserting the shortfall.

The third objection is that some identities ran a single scan long ago and should still count. Here the conversation turns to the measured window and to whether isolated historic activity belongs in a current seat count, which is a negotiation rather than a given. The fourth is that service accounts performed real analysis and so are licensable. The answer is to examine each account: automation that orchestrates a pipeline is not a human developer seat, while an account a person used to run interactive analysis may be. None of these objections survives a dated, attributable activity record presented calmly and line by line. The buyer who anticipates them keeps the definition anchored to use, and the definition anchored to use is the definition that produces the smaller, defensible number rather than the vendor's roster.

It helps to remember why the definition carries so much weight. A Fortify finding is the seat count multiplied by a price, then compounded by back maintenance, so a definition that is even modestly too broad produces a finding that is substantially too large. Pinning the seat to scan use is not a marginal refinement. It is the lever that moves the whole figure. A buyer who establishes the correct definition early, evidences it from activity records, and refuses to let an access roster stand in for measured consumption has done the work that determines the size of every component that follows, which is why we treat the definition as the first battle in any Fortify defense rather than a detail to settle later.

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