How to scope Fortify non production scanning

A large share of Fortify activity happens outside production. Developers scan code in test and staging, pipelines run scans on every build, and security teams probe non production environments before anything ships. When an audit treats all of that activity as if it were production usage, the finding inflates fast. Knowing how to scope Fortify non production scanning is what lets a buyer separate the activity the license treats differently and hold the finding to the production reality.

This article explains why non production matters to the license, where findings sweep it into the production count, and how a buyer scopes it cleanly. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Why non production is a separate question

Non production use is frequently treated differently under a license, and even where the terms are silent, the volume of non production activity tells a misleading story if it is read as production demand. Test scans, staging scans, and pipeline scans exist to catch issues before release, not to serve end users. A finding that counts every scan, regardless of environment, as evidence of production scale usage is conflating two different things. The broader exposure question is set out in Fortify non production use and license exposure.

Where findings sweep non production into production

The recurring errors on environment scoping are familiar:

• Counting CI pipeline scans as production. Automated build scans run constantly and produce high volume, but they are non production by nature, tied to CI pipeline service accounts counted as Fortify seats.
• Counting staging and test scans as live usage. Pre release scanning is part of the development cycle, not production operation.
• Counting scan farm capacity as production seats. Shared build infrastructure serves non production work, examined in Fortify scan farm and build server license questions.
• Counting evaluation and proof of concept scans. One off scans against retired or trial targets should not enter the sustained measurement.

Scoping the environments cleanly

The defensible approach is to label every scan by environment before any number is built. A buyer maps its environments, tags scan history as production, staging, test, or CI, and isolates evaluation activity. With the tags in place, the production count stands on its own, and the non production volume is visible as the development activity it is rather than as production demand. This environment mapping is part of reconciling Fortify entitlements before an audit, and it is the same discipline that separates burst activity from sustained use.

Reading the metric against the right environment

Once environments are scoped, the seat metric applies to the population that genuinely operates in production, while non production activity is documented separately. A developer who only scans in test, or a pipeline that only scans on build, does not necessarily add to the production seat count. The error the buyer corrects is the assumption that scanning anywhere equals production licensing everywhere. The wider measurement frame is set out in how OpenText measures Fortify usage in an audit.

Evidencing the real picture

The buyer reconstructs the scope from its own records: environment inventories, scan history tagged by environment, pipeline configurations, and the deployment map. From these it shows which scans ran where, separates non production from production, and documents the production population under the correct metric. The reconstruction converts an undifferentiated scan total into an environment scoped figure, and the production count that survives is materially smaller. The same evidence approach appears in reducing a Fortify finding with commit and scan evidence.

A representative outcome

In a recent engagement, a finding counted a high volume of scans, most of them generated by CI pipelines and staging tests, as evidence of large scale production usage. By tagging scan history by environment, isolating the pipeline and staging activity, and removing evaluation scans, we showed that the production scanning population was a fraction of the raw scan total implied. 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 brought a developer seat overclaim down by 80 percent.

The scoping discipline in one line

Tag every scan by environment, isolate test, staging, and CI, and let the production count stand alone. That is how scoping non production scanning protects a buyer from a finding built on undifferentiated volume. For the static and dynamic split that often accompanies this, see Fortify static versus dynamic analysis license scope, and to scope your environments with us you can open a case with our team.

How the four Rs scope the environments

Environment scoping runs through the method end to end. In the reconstruct stage we tag scan history by environment and isolate non production activity, independently and before any vendor measurement script runs. In the rebut stage we challenge every line that counts CI, staging, or test scanning as production demand. In the resolve stage we settle on the production scoped count and convert forward into an agreement whose terms address non production use explicitly. The scoping work is what converts an undifferentiated scan total into a production figure the buyer can defend, and the earlier the tagging is done, the cleaner the separation.

Burst pipelines and sustained production

Pipelines are bursty by design. A single commit can trigger a cascade of scans across services, and a busy release window can generate enormous volume in a short period. None of that is sustained production demand. A measurement that takes a peak pipeline moment and treats it as the steady state overstates what the estate actually runs. The buyer reads the scan timeline rather than the flat total, isolates the release driven bursts, and establishes the sustained production figure on its own. Separating burst from sustained, like separating non production from production, is how a scan total built for development hygiene stops masquerading as production scale usage.

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