CI pipeline service accounts counted as Fortify seats

Modern application security runs inside the build pipeline. Scans are triggered automatically on every commit, pull request, or scheduled build, and those scans are submitted not by a person but by a service account that the pipeline uses to authenticate. When an audit reads the user directory, those service accounts look exactly like everyone else, and a measurement that does not distinguish them counts machinery as people. The pattern of CI pipeline service accounts counted as Fortify seats is one of the most common ways a developer seat finding inflates, and it is also one of the most straightforward to correct once the accounts are identified.

This article explains why pipeline automation produces accounts that should not be counted as seats, how to identify them, and how their removal brings the finding down. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Why automation produces phantom seats

The Fortify developer seat metric counts the people who submit code for analysis. A continuous integration pipeline submits scans on behalf of the whole development organization through one or a handful of service identities. Those identities may account for an enormous share of total scan activity, because automation runs constantly, but they represent infrastructure, not a population of developers. A measurement that counts each service account as a seat, or that reads the high scan volume those accounts generate as evidence of many users, inflates the count in two directions at once. This is the same conflation of access and activity with entitlement that we trace in Fortify Software Security Center user counting traps.

Identifying the service accounts

Service accounts are usually identifiable from their characteristics rather than their labels. Several signals mark an account as automation rather than a person:

• Naming and ownership. Accounts tied to a build system, a robot user, or a shared functional mailbox rather than an individual.
• Submission pattern. Scans submitted on a regular schedule, at machine speed, or in volumes no individual could produce.
• Authentication source. Logins originating from build agents and pipeline hosts rather than developer workstations.
• Token based access. Authentication through API tokens or service credentials rather than interactive login, a context developed in Fortify token based and floating license models and in how Fortify integration and API users are counted.

Mapping scans back to people

Removing the service accounts is only half the work; the count then has to be rebuilt around the people the automation acts for. The defensible figure is the developers whose code the pipeline scans, counted under the developer seat metric, not the service identity that submits on their behalf. In practice this means attributing pipeline scans back to the commits and contributors that triggered them, which the source control and build systems record, and counting the distinct active contributors rather than the automation. This attribution is part of reducing a Fortify finding with commit and scan evidence and ensures the corrected count reflects real developers without double counting the pipeline.

Reconstructing the position

As with every Fortify line, the buyer rebuilds the position from its own records before any vendor measurement script runs. The Software Security Center directory and scan history are exported, service and pipeline accounts are classified and set aside, and the remaining activity is mapped to the active contributor population. The result distinguishes the small number of automation identities, which are not seats, from the genuine developer count, which is. This work sits inside reconciling Fortify entitlements before an audit and is what converts an automation inflated total into a defensible developer figure.

A representative outcome

In a recent engagement, a finding counted several CI service accounts as developer seats and additionally read the very high scan volume those accounts generated as evidence of a large user base. By identifying the automation identities from their naming, submission cadence, and token based authentication, the buyer set them aside and rebuilt the count from the active contributors whose commits the pipeline scanned. The corrected developer population was far below the claimed figure, and the finding settled well below its opening number. The path tracked our E-02 case file, where a Fortify developer seat overclaim of $4.5M settled at $0.9M, an 80 percent reduction, once automation and access were separated from actual code submitters.

Holding the distinction

The discipline on a pipeline driven finding is to keep machinery and people apart. A service account is not a seat, and the scan volume automation produces says nothing about how many developers exist. Both conflations are correctable from records the build and scan systems already hold, and both corrections bring the number toward the figure the entitlement supports. For the broader measurement context, see how OpenText measures Fortify usage in an audit.

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