Reducing a Fortify finding with commit and scan evidence

Most Fortify findings inflate because they count the wrong thing: access, infrastructure, or history, rather than the developers who actually submitted code for analysis. The way to bring the number down is not to argue, but to replace the vendor's proxy with the record of what really happened. Reducing a Fortify finding with commit and scan evidence means attributing every scan to the developer whose commit triggered it, so that the seat count reflects the active scanning population and nothing else. This is the evidentiary backbone of a strong rebuttal, and it is referenced across our Fortify work.

This article sets out where the evidence lives, how the attribution works, and how the resulting count is anchored to the entitlement. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Why evidence beats the proxy

An audit measurement reaches for whatever is easy to extract: a source control access list, a project inventory, a count of scanning nodes. Each of these is a proxy for usage, and each overstates it, because access, infrastructure, and history all expand faster than actual scanning. The remedy is to discard the proxy and build the count from two records the organization already keeps: the scan history in the Software Security Center and the commit history in source control. Where those two records agree, you have a developer who actually used Fortify. This replaces the assumptions behind how to challenge a Fortify repository access headcount with a positive demonstration of who scanned.

Where the evidence lives

Two systems hold what the rebuttal needs. The Software Security Center records every scan: when it ran, which project it belonged to, and which account submitted it. The source control system records every commit: who authored it, when, and against which branch. The build pipeline ties the two together, because a scan is usually triggered by a build, and the build is triggered by a commit. By joining these records across the review period, the buyer reconstructs the chain from a developer's code to the scan that analyzed it. This is the same dataset that lets us isolate automation, as in CI pipeline service accounts counted as Fortify seats, and to separate infrastructure from people, as in Fortify scan farm and build server license questions.

The attribution, step by step

The method runs in a defined order so that the result is reproducible:

• Fix the review period. Everything is measured within a defined window, so that retired work is excluded, the discipline in decommissioned Fortify projects still on the audit.
• List the scans. Pull every scan in the period from the Security Center, with its submitting account and timestamp.
• Attribute each scan to a commit. Join the scan to the build that produced it and the commit that triggered the build, identifying the human author.
• Remove automation and service identities. Submissions made by pipelines and integrations are credited to the authors they acted for, not counted as seats.
• Count distinct active authors. The surviving set of developers who authored scanned commits is the active scanning population.

That population is then counted under the applicable metric, whether named or concurrent, as set out in Fortify named user versus concurrent user definitions.

Anchoring the count to the entitlement

The evidentiary count means little until it is read against what the buyer actually licensed. Before any vendor measurement script runs, the buyer reconstructs its effective license position from purchase records and the applicable terms, the work described in reconciling Fortify entitlements before an audit. The attributed scanning population is then compared to that entitlement, and the gap, if any, is the real exposure, not the inflated proxy the audit opened with. This positive count is what makes the line by line rebuttal in defending a Fortify developer seat finding line by line persuasive rather than merely contrary.

A representative outcome

In a recent engagement, a Fortify finding rested entirely on proxies: a source control access list, a full project inventory, and a count of scanning infrastructure. By fixing a review period, pulling every scan from the Security Center, attributing each to the commit and author that triggered it, and removing the automation that had submitted on behalf of teams, the buyer produced a count of developers who had actually scanned code. That figure was far below the proxy based claim, and because it was built from records the vendor could verify, it held. The finding settled well under its opening position, consistent with the reductions we see across Fortify matters and with our E-02 case file, where a developer seat overclaim of $4.5M settled at $0.9M, an eighty percent reduction.

Holding the evidentiary line

The discipline is to make the vendor meet a count built from its own product's records rather than to accept a count built from convenient proxies. A scan has an author, and the author is a developer who used Fortify; everyone else is reach, infrastructure, or history. Each can be removed with evidence, and the result is a figure that survives scrutiny. For the broader measurement context, see how OpenText measures Fortify usage in an audit.

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