WebInspect license metrics and scan counting

Fortify audits tend to focus on Static Code Analyzer seats, but the dynamic analysis side of the portfolio carries its own counting traps. WebInspect is licensed and measured differently from SCA, and a finding that blurs the two, or that counts WebInspect activity by the wrong unit, overstates exposure in ways a buyer can contest. Understanding WebInspect license metrics and scan counting is essential whenever a finding reaches beyond static analysis into dynamic testing.

This article explains how WebInspect is licensed, where scan counting goes wrong, and how the metric differs from SCA. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

How WebInspect differs from SCA

Static Code Analyzer examines source code without running it. WebInspect performs dynamic analysis against running applications, probing them as an attacker would. Because the two tools work differently, they are licensed differently, and the metrics that define a WebInspect entitlement are not interchangeable with the developer seat metric that governs SCA. A finding that applies SCA seat logic to WebInspect, or that counts the two under a single combined unit, is applying the wrong metric and inflating the claim. We compare the two directly in Fortify SCA versus WebInspect licensing compared.

Where scan counting goes wrong

WebInspect findings inflate through several recurring errors. The most common are:

• Counting scans as users. A high volume of dynamic scans does not imply a large user population. Automated and scheduled scans can run from a small number of seats.
• Counting test and staging scans as production. Dynamic testing frequently runs against non production environments, which the license may treat differently, as covered in Fortify non production use and license exposure.
• Counting one off and evaluation scans. Proof of concept and ad hoc scans against retired targets should not enter the sustained measurement.
• Mixing WebInspect Enterprise components. The enterprise deployment introduces connectivity and component licensing that is distinct again, treated in WebInspect Enterprise and connectivity licensing.

Reading the WebInspect metric correctly

The defensible approach is to read the specific entitlement and apply its actual unit. Where the entitlement is expressed in terms of seats or named users, the count is the people who operate the tool, not the number of scans they run. Where it is expressed in terms of applications or targets, the count is the distinct in scope applications, not every URL ever probed. A finding that conflates scan volume with the licensed unit overstates exposure, and the correction is simply to apply the metric the entitlement actually specifies.

Evidencing the real picture

As with every Fortify line, the buyer reconstructs the position from its own records before any vendor script runs. WebInspect maintains scan history, target inventories, and operator records. From these the buyer assembles the count under the correct unit, separates non production and evaluation activity, and isolates the WebInspect Enterprise components from the standalone tool. This reconstruction is part of reconciling Fortify entitlements before an audit and turns a scan volume narrative into a metric based one.

A representative outcome

In a recent engagement, a finding treated a large volume of dynamic scans as evidence of widespread WebInspect usage and priced accordingly. By reconstructing the operator population and the in scope target inventory, and by separating non production and evaluation scans, we showed that the licensed unit supported a far smaller count than the scan volume implied. The dynamic analysis portion of the finding settled well below its opening figure, consistent with the reductions we see across Fortify matters and with the path our E-02 case file followed on the static analysis side.

Keeping the metrics separate

The discipline on a WebInspect finding is to refuse the conflations: scans are not users, non production is not production, and dynamic analysis is not static analysis. Each WebInspect entitlement has a unit, and the buyer is entitled to be measured by that unit. For the broader measurement context, see how OpenText measures Fortify usage in an audit.

Sustained activity versus burst scanning

One of the most useful distinctions on a WebInspect finding is between sustained operation and burst activity. Dynamic scanning is often bursty by nature: a release cycle triggers a cluster of scans against a set of applications, then activity subsides until the next cycle. A measurement that takes a peak moment and treats it as the steady state count overstates what the buyer actually operates. The defensible figure reflects sustained use across the measured window, not a single high point driven by a release event or a scheduled batch. Separating the two requires reading the scan history with the timeline in view rather than as a flat total.

The same care applies to how scans map to the licensed unit. If the entitlement is expressed in operators or named users, a burst of scans run by a small team does not multiply the user count. If it is expressed in applications or targets, repeated scans of the same application across a release cycle do not multiply the target count. The vendor's number frequently conflates scan volume with the licensed unit precisely because burst activity produces a large volume in a short window. The buyer corrects this by reconstructing the timeline, mapping scans to operators and to distinct in scope targets, and isolating release driven bursts from steady operation. The corrected figure is materially smaller than a peak based count, and it is defensible because it reflects the unit the entitlement actually specifies. For the comparison with static analysis, see Fortify SCA versus WebInspect licensing compared.

The discipline across a WebInspect finding comes down to refusing three conflations. Scans are not users, so volume does not set the seat count. Bursts are not steady state, so a release driven peak does not set the sustained figure. And dynamic analysis is not static analysis, so SCA seat logic does not transfer to WebInspect. Each WebInspect entitlement specifies a unit, and the buyer is entitled to be measured by that unit and no other. A reconstruction that reads the timeline, maps scans to operators and distinct targets, and isolates non production and evaluation activity produces a figure that is both smaller and more defensible than any count built from raw scan volume.

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