Fortify seat counting, and the overclaim inside it.

A Fortify finding almost always begins with the same move: every account that can reach a repository or open the Software Security Center is treated as a licensable developer seat. Real seat consumption is narrower than that, because the metric follows scan submitters and active developers, not passive viewers and pipeline service accounts. This paper shows how to separate the two and rebuild the count that actually maps to use, the work we run in the Reconstruct and Rebut phases of our Fortify and AppSec audit defense.

What is inside

The difference between repository access, SSC role membership, and a licensable Fortify seat
How CI pipeline and build server service accounts inflate a developer count, and how to remove them
What scan submission evidence looks like, and how to assemble it from commit and scan logs
Where perpetual versus term positions change the exposure on the same headcount
How non production scanning is scoped, and which environments fall outside the production seat count
A line by line method for documenting active developers ahead of a rebuttal

In a recent engagement (E-02) a Fortify developer seat overclaim moved from a $4.5M finding to a $0.9M settlement, an 80 percent reduction, after we mapped actual scan submitters. For wider context, see repository access versus scan submitters and the complete audit defense playbook.