Fortify static versus dynamic analysis license scope

Fortify covers two distinct kinds of application security testing, and they are licensed under separate scopes. Static analysis, performed by Static Code Analyzer, examines source code without running it. Dynamic analysis, performed by WebInspect, probes running applications from the outside. Because the two work differently, they carry different metrics, and a finding that blends them, or that applies one product's scope to the other's usage, overstates exposure. Reading the Fortify static versus dynamic analysis license scope correctly is what keeps a finding from charging the same activity twice or under the wrong unit.

This article explains how the two scopes differ, where findings conflate them, and how a buyer keeps each in its lane. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Two products, two scopes

Static Code Analyzer and WebInspect are not two settings of one tool. They are separate products with separate entitlements. SCA is typically governed by a developer seat metric tied to the people who submit code for analysis. WebInspect is governed by its own unit, often operators or applications, tied to dynamic scanning. The scopes do not interchange. A developer who never touches dynamic scanning is outside the WebInspect scope, and an operator who only runs dynamic scans is outside the SCA seat metric. The direct comparison is developed in Fortify SCA versus WebInspect licensing compared.

Where findings blend the two scopes

The recurring conflations on a combined Fortify estate are predictable:

• Counting one population under both metrics. The same developers are charged as SCA seats and again as WebInspect users, though most never run dynamic scans.
• Applying SCA seat logic to WebInspect. Dynamic scan volume gets translated into a seat count it was never meant to drive, an error examined in WebInspect license metrics and scan counting.
• Treating the WebInspect Enterprise layer as SCA seats. Console users and sensors get priced under the static metric, a confusion addressed in WebInspect Enterprise and connectivity licensing.
• Counting shared infrastructure twice. Build servers and scan farms that serve both products get charged once per product, examined in Fortify scan farm and build server license questions.

Reading each scope correctly

The defensible approach is to read each entitlement separately and apply its own unit to its own usage. The SCA count is the people who submit code for static analysis. The WebInspect count is the operators or applications in scope for dynamic scanning. A person counts under SCA only if they use SCA, and under WebInspect only if they use WebInspect. Where someone genuinely uses both, both apply, but the burden is to show actual use in each scope, not to assume it from membership in a combined team. The seat definition that underpins the static side is set out in what counts as a Fortify developer seat in an audit.

Separating the populations

The practical work is to map who does what. A buyer lists the developers who submit code for static analysis, the operators who run dynamic scans, and the small overlap who do both. Most estates show two largely distinct populations with a modest intersection, not one population that uses everything. Once the map exists, the double counting collapses, because each person falls under the scope they actually use. This mapping is part of reconciling Fortify entitlements before an audit.

Evidencing the real picture

The buyer reconstructs each population from its own records: SCA scan submissions for the static count, WebInspect scan history for the dynamic count, and access logs to confirm the overlap. The reconstruction shows two scopes with two populations, not one population charged twice. The corrected figure reflects actual use in each scope and is materially smaller than a count that assumes universal use of both products.

A representative outcome

In a recent engagement, a finding counted an entire engineering organization under both the SCA seat metric and the WebInspect metric, as though every developer ran both static and dynamic analysis. By reconstructing the two populations from scan submission records, we showed that static analysis users and dynamic scanning operators were largely distinct, with only a small overlap. Charging each person under the scope they actually used cut the combined count substantially. 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, where a technology company reduced a developer seat overclaim by 80 percent.

Keeping the scopes apart

The discipline is simple to state and powerful in effect: static is not dynamic, SCA is not WebInspect, and use of one is not use of the other. Each scope has a unit, each unit has a population, and the buyer is entitled to be measured scope by scope. For the line by line method behind this, see defending a Fortify developer seat finding line by line, and to separate your scopes before a finding lands you can open a case with our team.

How the four Rs separate the scopes

Separating static from dynamic is method work. In the reconstruct stage we build two populations independently, one for the people who submit code for static analysis and one for the operators who run dynamic scans, before any vendor measurement script runs. In the rebut stage we challenge every line that charges a person under both scopes without evidence of use in each. In the resolve stage we settle on a position that reflects two metrics applied to two populations, and convert forward into entitlements that keep the scopes defined. The discipline is the same one that runs through every Fortify matter: read the entitlement, apply the unit, document the use.

Where overlap genuinely exists

It is fair to acknowledge that some people genuinely use both products. A security engineer may submit code for static analysis and also run dynamic scans against a running application. Where that is true, both scopes apply to that person, and the defense does not pretend otherwise. The point is that overlap must be shown, not assumed. A finding that treats an entire organization as dual users is asserting an overlap that the records rarely support. The buyer documents the real intersection, which is almost always a modest fraction of either population, and charges it honestly while refusing to let an assumed overlap inflate the count.

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