Fortify SCA versus WebInspect licensing compared

Fortify is not a single product but a portfolio, and the two tools at its center, Static Code Analyzer and WebInspect, are licensed against different units. A finding that treats them as interchangeable, or that folds the two into a single count, applies the wrong metric to at least one of them and inflates the claim. Getting Fortify SCA versus WebInspect licensing compared right is the difference between a finding measured against the entitlements that actually apply and one measured against a blended assumption that no contract supports.

This article compares how SCA and WebInspect are licensed, why the two cannot be counted together, and how a buyer keeps the metrics separate in a finding. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Two tools, two methods, two metrics

Static Code Analyzer examines source code without executing it, identifying vulnerabilities in the code itself. WebInspect performs dynamic analysis against running applications, probing them from the outside as an attacker would. Because the tools work in fundamentally different ways, they are entitled and metered differently. SCA is governed by a developer seat metric tied to the people who submit code for analysis, the definition we set out in what counts as a Fortify developer seat in an audit. WebInspect carries its own metric expressed in operators, applications, or targets, the subject of WebInspect license metrics and scan counting. The two metrics are not convertible into one another.

Where the blend inflates the finding

Several blending errors recur in Fortify findings and each one pushes the number up:

• Counting WebInspect activity as SCA seats. Dynamic scans are attributed to the developer seat metric, multiplying the SCA count by activity that belongs to a different entitlement.
• Applying a single combined unit. A finding that reports one blended user total for both tools obscures which entitlement each user falls under and prevents the buyer from reconciling against either.
• Carrying SCA viewer logic into WebInspect. Console viewers counted as SCA seats are sometimes also counted again on the WebInspect side, double counting the same people.
• Treating scan volume as users on either side. A high scan count is read as a large population whether the scans are static or dynamic, when both tools support automation from a small number of seats.

Keeping the two unbundled

The defensible approach reads each entitlement separately and applies its actual unit to the activity that belongs to it. SCA usage is counted by code submitters against the developer seat metric; WebInspect usage is counted by operators or in scope targets against the WebInspect metric. The buyer separates the two data sets at the source, attributing each scan, account, and project to the correct tool before any count is built. This separation also clarifies how named and concurrent definitions apply on each side, a question developed in Fortify named user versus concurrent user definitions. Where the entitlement scope itself is in question, see Fortify static versus dynamic analysis license scope.

Reconstructing each metric independently

As with every Fortify line, the position is rebuilt from the buyer's own records before any vendor measurement script runs. For SCA, the buyer assembles the active submitter population from scan submission logs; for WebInspect, the operator population and in scope target inventory from scan history. Each is reconciled against its own entitlement, and neither figure is allowed to borrow assumptions from the other. This dual reconstruction is part of reconciling Fortify entitlements before an audit, and it produces two defensible figures in place of one inflated blend.

A representative outcome

In a recent engagement, a finding reported a single combined user total covering both static and dynamic analysis and priced it against the SCA developer seat rate. By separating the two data sets at the source, the buyer showed that a large portion of the claimed total was WebInspect operator and scan activity that belonged under a different metric, while the genuine SCA developer population was far smaller than the blended figure implied. Reconciled separately, both lines settled well below the opening number, consistent with the reductions we see across Fortify matters and with the path our E-02 case file followed on the static analysis side, where a developer seat overclaim of $4.5M settled at $0.9M.

The discipline of separation

The core discipline on a Fortify finding that spans both tools is to refuse the blend. Static analysis is not dynamic analysis, a developer seat is not a WebInspect operator, and scan volume is not a user count on either side. Each entitlement specifies a unit, and the buyer is entitled to be measured against both, separately and correctly. 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.