Fortify burst scanning and capacity definitions

Application security scanning is not a steady stream of work. It comes in waves. A release window triggers a cascade of scans across dozens of services, a single large commit kicks off a fan out of pipeline jobs, and a quiet sprint produces almost nothing. When a finding takes the highest point on that timeline and treats it as the estate's permanent capacity requirement, it overstates what the buyer actually runs. Understanding Fortify burst scanning and capacity definitions is what lets a buyer separate a peak moment from the sustained demand a license should be measured against.

This article explains why scanning bursts, where a finding confuses burst with capacity, and how a buyer establishes the sustained figure that should drive the number. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Why Fortify scanning is bursty by design

Modern application security is wired into the development cycle, and the development cycle is uneven. Scans cluster around releases, merge events, and scheduled pipeline runs, then fall away. A continuous integration trigger can launch a wide fan of scans in minutes, and a release freeze can drive a short period of intense activity that bears no relation to the normal week. This is healthy engineering behaviour, not evidence of large scale capacity. The same burst pattern drives the service account question examined in CI pipeline service accounts counted as Fortify seats.

Where a finding confuses burst with capacity

The recurring errors on capacity measurement follow a familiar pattern:

• Taking peak concurrent scans as the licensed requirement. A release window spike is read as the steady state, inflating the capacity the buyer is said to need.
• Counting pipeline fan out as distinct sustained demand. One commit triggering many scans looks like many users, when it is a single automated event, related to Fortify scan farm and build server license questions.
• Reading a busy measurement window as typical. If the audit happens to sample a release heavy period, the captured volume misrepresents the normal cadence.
• Treating burst scanning as a separate consumer population. High volume gets translated into a high seat count, which is the same misread covered in the Fortify SCA seat overclaim between repository access and scan submitters.

Reading capacity against sustained demand

The defensible capacity figure is the demand the estate carries on a sustained basis, not the peak it touches under load. A buyer reads the scan timeline rather than the flat total, identifies the release driven and pipeline driven bursts, and establishes the steady state underneath them. Capacity definitions matter here: a license that speaks to concurrent capacity, throughput, or sustained scanning is not satisfied by pointing at a single high water mark. The buyer holds the measurement to the definition the contract actually uses and to the demand the estate actually sustains. The wider measurement frame is set out in how OpenText measures Fortify usage in an audit.

Evidencing the sustained figure

The buyer reconstructs the picture from its own scan history: timestamps, pipeline configurations, release calendars, and the mapping of scans to triggering events. From these records it shows which spikes were release or merge driven, isolates the burst periods, and establishes the sustained scanning demand on its own terms. The reconstruction converts a peak driven capacity claim into a sustained figure the buyer can defend, and the sustained figure is materially smaller. This is the same evidence discipline described in reducing a Fortify finding with commit and scan evidence, and it pairs naturally with environment scoping covered in how to scope Fortify non production scanning.

How the four Rs separate burst from capacity

The burst and capacity question runs through the method end to end. In the reconstruct stage the firm reads the scan timeline and builds the sustained demand figure independently, before any vendor measurement script runs, so the capacity baseline is the estate's documented reality rather than its busiest minute. In the rebut stage every line that treats a peak as the steady state is challenged against the timeline and the contract's capacity definition. In the resolve stage the settlement is struck on the sustained figure and converted forward into an agreement whose capacity metric is defined rather than left open to a peak reading. The earlier the timeline is reconstructed, the cleaner the separation between burst and sustained demand.

A representative outcome

In a recent engagement, a Fortify finding presented a capacity requirement built on a measurement window that happened to span a major release. Scan volume during that window was high, and the finding read it as the estate's permanent need. By reconstructing the scan timeline, mapping the spikes to release and pipeline events, and establishing the sustained demand across a representative period, the buyer showed that the genuine capacity requirement was a fraction of the peak implied. The matter settled well below its opening figure, consistent with our E-02 case file, where a technology company brought a Fortify developer seat overclaim down by 80 percent, and with the burst versus sustained discipline we apply across security product audits.

The capacity discipline in one line

Read the timeline, isolate the release and pipeline bursts, and measure capacity against sustained demand under the contract's actual definition. That is how Fortify burst scanning stops being mistaken for permanent capacity. For the seat side of the same problem, see what counts as a Fortify developer seat in an audit, and to put your scan timeline to work you can open a case with our team.

For the seat counting methodology behind the capacity question, read the Fortify seat counting white paper.