Fortify non production use and license exposure

One of the most defensible reductions on a Fortify finding comes from a question the vendor rarely asks first: how much of the measured usage was non production. Scanning that happens in development, test, build, and proof of concept environments often carries different license treatment than production use, and a finding that counts all of it as production exposure overstates the claim. Understanding Fortify non production use and license exposure lets a buyer separate the usage that genuinely needs a license from the usage that does not.

This article explains where non production use sits, why it is routinely overcounted, and how to scope it correctly. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What non production use means for Fortify

Application security analysis happens across many environments. Engineers scan code on developer workstations, build pipelines run automated analysis on every commit, test environments validate fixes, and proof of concept work evaluates new configurations. Not all of this activity carries the same license weight. The Additional License Authorizations and the specific entitlement terms determine which environments and which kinds of use require a paid seat, and a careful reading often shows that some non production activity is either covered differently or not chargeable as additional seats at all.

Why non production use is overcounted

Measurement that draws on repository access or on raw scan counts cannot tell production from non production on its own. A build pipeline that scans every commit generates a large volume of analysis activity, but that activity is automation in a non production context, not a population of human production users. When a finding counts pipeline activity as production seats, it inflates the claim with usage that the license treats differently. The same happens with developer workstations used purely for local testing and with short lived proof of concept deployments that were never promoted to production.

Scoping non production use correctly

Scoping is reconstruction work. The buyer maps each scanning context to an environment and to the license treatment that applies to it. The categories that typically need separating are:

• Build and continuous integration scanning. Automated analysis triggered by commits, covered in CI pipeline service accounts counted as Fortify seats.
• Developer and test environment use. Local and test scanning distinct from production analysis.
• Proof of concept and evaluation deployments. Short lived work that never reached production.
• Decommissioned projects. Analysis history for applications that no longer exist, treated in decommissioned Fortify projects still on the audit.

Each category is then matched to the relevant license term. The result is a finding that prices production use as production and treats non production use under its actual terms, which is materially smaller than a finding that assumes everything is production. The detailed method is in how to scope Fortify non production scanning.

The evidence that supports the scope

As with seat counting, the argument rests on the buyer's own records. Build pipeline logs show which scans were automated. Environment tagging in Software Security Center distinguishes test projects from production ones. Deployment records show which proof of concept work was retired. Assembling this evidence before the vendor script runs is part of reconciling Fortify entitlements before an audit, and it converts a vague non production claim into a documented scope the vendor must engage with.

A representative outcome

In a recent engagement, a meaningful share of the claimed Fortify usage turned out to be build pipeline automation and test environment scanning rather than production analysis by individual developers. By scoping the non production activity correctly and presenting the environment evidence, we removed that portion of the claim from the production seat calculation. Combined with the seat overclaim work, the finding settled well below its opening figure, in line with the reductions we see on Fortify matters. This is consistent with the path our E-02 case file followed.

Holding the position

Non production use is not a loophole. It is a category the license already recognizes, and a buyer is entitled to have each environment treated under the terms that apply to it. The discipline is to scope it deliberately and evidence it thoroughly, so the vendor cannot collapse the whole estate into a single production assumption. For the related metric work, see what counts as a Fortify developer seat in an audit.

Building the environment map

Scoping non production use only works if the buyer can show, environment by environment, where each scan ran and why. That map is the deliverable, and it is built from the systems the buyer already operates. Build pipeline configuration shows which jobs invoked the analyzer and in which stage. Project and application tagging in Software Security Center distinguishes test and staging projects from production ones. Deployment and change records show which environments were transient and which proof of concept work was retired without ever reaching production. Laid side by side, these sources let the buyer assign every block of scan activity to an environment and to the license treatment that applies to it.

The map matters because it converts a category argument into an evidenced one. Telling the vendor that some usage was non production is weak. Showing that a defined set of scans originated in a build pipeline stage, against test tagged projects, on infrastructure that was decommissioned on a documented date, is strong. The vendor must then engage with the evidence rather than fall back on a blanket production assumption. The same map also protects the buyer going forward, because it establishes the environment boundaries that a clean agreement can codify. Treating environment scoping as a one time audit exercise wastes that value. The buyer who maintains the map turns it into a standing record that makes the next review faster and the next finding smaller. For the related seat work that the map supports, see what counts as a Fortify developer seat in an audit.

The broader point is that environment is a license variable, not a technical footnote. Where a scan ran, in which stage of a pipeline, against which class of application, all bear on whether and how it is licensed. A finding that flattens every environment into a single production assumption is making a pricing choice, not stating a fact, and a buyer is entitled to contest that choice with an environment map drawn from its own systems. The reductions available from careful non production scoping are among the most durable in a Fortify defense precisely because they rest on the license terms the vendor itself wrote, applied honestly to each environment rather than collapsed into the most expensive reading.

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