WebInspect Enterprise and connectivity licensing

The standalone WebInspect scanner is only part of the dynamic analysis story. When an organization scales dynamic testing across teams, it usually deploys WebInspect Enterprise, which introduces a central management layer, distributed sensors, and a set of connectivity components that are licensed and measured in their own right. A finding that prices the enterprise deployment by importing standalone scanner assumptions, or that treats every connected component as a separately chargeable unit, overstates exposure. Understanding WebInspect Enterprise and connectivity licensing is what keeps a finding on this part of the portfolio honest.

This article explains how the enterprise deployment is structured, where the connectivity components create counting traps, and how a buyer reconstructs the position against the actual entitlement. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What WebInspect Enterprise actually deploys

WebInspect Enterprise is not simply many copies of the desktop scanner. It is a managed deployment with a central console, a database, and one or more scan engines or sensors that carry out the dynamic tests. Operators interact with the console, schedule scans, and review results, while the sensors do the work against running applications. Because the architecture separates the people who direct scanning from the machinery that performs it, the licensed unit matters enormously. A finding that counts every console login, every sensor, and every connected integration as if each were a separate full price entitlement is double counting the same deployment.

Where connectivity components inflate a finding

The connectivity layer is where measurement most often goes astray. The recurring errors are familiar once you see them:

• Counting sensors as operators. Distributed scan engines exist to spread workload, not to represent users. A deployment with several sensors does not imply a large operator population.
• Counting integrations as seats. Connections to issue trackers, build systems, or a software security center are integration points, not human users, and should not be priced as named seats.
• Counting console access as full scanner licenses. Reviewers and managers who read results through the console are not necessarily licensed the same way as the operators who submit scans, a distinction we examine in Fortify Software Security Center user counting traps.
• Carrying non production and evaluation sensors into the sustained count. Test deployments and proof of concept sensors should not enter the production measurement.

Reading the enterprise metric correctly

The defensible approach is to read the specific entitlement that governs the enterprise deployment and apply its actual unit. Where the entitlement is expressed in operators or named users, the count is the people who direct scanning, not the sensors that execute it. Where it is expressed in scan engines or capacity, the count is the licensed engine capacity, not the integrations wired into it. The scanner and the enterprise framework are distinct, and a finding that blends them is applying the wrong metric. The broader contrast between the desktop scanner and the dynamic deployment is set out in WebInspect license metrics and scan counting.

Separating the connectivity layer from the chargeable units

A useful discipline is to map the deployment before pricing anything. List the console, the database, each sensor, and every integration, then ask which of these the entitlement actually charges for and under what unit. In most deployments the chargeable units are far fewer than the total component count, because integrations and infrastructure exist to support a defined number of operators or a defined engine capacity. Once the map is drawn, the connectivity points fall out of the chargeable count and the finding shrinks to the units the entitlement names. This mapping is part of reconciling Fortify entitlements before an audit.

Evidencing the real picture

As with every Fortify line, the buyer reconstructs the position from its own records before any vendor measurement script runs. The enterprise console maintains operator records, scan schedules, sensor inventories, and integration configurations. From these the buyer assembles the operator count under the correct unit, isolates the sensors as capacity rather than users, separates non production and evaluation components, and documents which integrations are machine connections rather than seats. The result converts a component count narrative into a metric based one, and the metric based figure is materially smaller. The same evidence discipline appears in defending a Fortify developer seat finding line by line.

A representative outcome

In a recent engagement, a finding on a WebInspect Enterprise deployment priced every console user, every sensor, and every integration as a separate full price entitlement, producing a number far above what the deployment represented. By mapping the architecture, showing that the sensors were shared capacity rather than users, and reclassifying the integrations as machine connections, we reduced the chargeable count to the operator population the entitlement actually defined. The enterprise 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 developer seat side, where a technology company brought a developer seat overclaim down by 80 percent.

Keeping the components in their lanes

The discipline on a WebInspect Enterprise finding is to refuse the conflations the connectivity layer invites. Sensors are capacity, not operators. Integrations are machine connections, not seats. Console review access is not the same entitlement as scan submission. And the enterprise framework is not the standalone scanner. Each unit has a defined metric, and the buyer is entitled to be measured by that metric and no other. For the wider question of how the vendor assembles its measurement, see how OpenText measures Fortify usage in an audit, and to start a structured reconstruction you can always open a case with our team.

How the four Rs apply to the enterprise deployment

Our method maps directly onto a WebInspect Enterprise finding. In the respond stage, across the first seven days, we take over the channel so the audit team is not handed a raw component inventory to interpret as it pleases. In the reconstruct stage we map the console, the sensors, and the integrations independently and build the operator count under the correct unit, before any vendor measurement script runs. In the rebut stage we challenge every line that prices a sensor as a user or an integration as a seat, and in the resolve stage we settle on the metric based count and convert forward into an agreement whose component definitions are explicit. The deployment map is the foundation, and the earlier it is drawn the cleaner the defense.

Infrastructure, capacity, and people

The clearest way to keep an enterprise finding honest is to sort every component into one of three buckets: infrastructure, capacity, and people. The console and database are infrastructure that supports the deployment. The sensors are capacity that executes the scans. The operators are the people the seat metric counts. Integrations sit alongside infrastructure as machine connections, not users. Once the components are sorted this way, the chargeable units stand out clearly, and the connectivity layer falls out of the count. A finding that prices infrastructure and capacity as though they were people is the error the buckets are designed to expose, and the sorting is something the buyer can document from its own deployment records.

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