Fortify SSC role based access and consumer counts

Fortify Software Security Center, or SSC, uses roles to control what each account can see and do. Those roles are a governance feature, but in an audit they become a counting battleground. A finding that treats every role assignment as a licensed consumer, without distinguishing the people who submit scans from the people who only read results, inflates the headcount. Understanding Fortify SSC role based access and consumer counts is what lets a buyer map roles to the actual license metric instead of accepting a count built from raw role membership.

This article explains how SSC roles work, where role membership inflates a consumer count, and how a buyer challenges the number. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What SSC roles actually do

SSC roles assign permissions: who can submit scans, who can review and audit results, who can administer projects, and who can simply view dashboards. These roles exist to enforce least privilege, not to define the license unit. A viewer role and a developer role are very different things in licensing terms, even though both appear as accounts in the same system. A finding that flattens these distinctions and counts every role holder as a consumer is reading an access control structure as if it were a billing structure. The broader user counting traps in SSC are examined in Fortify Software Security Center user counting traps.

Where role membership inflates the count

The recurring overcounts on SSC role data are consistent:

• Counting viewers as consumers. Read only roles assigned to managers and stakeholders are not scan submitters and frequently fall outside the seat metric.
• Counting auditors and reviewers as developers. Security reviewers who triage findings are doing a different job from developers who submit code, a distinction tied to Fortify SCA seat overclaim repository access versus scan submitters.
• Counting service and integration roles as people. Automation accounts hold roles too, but they are machine identities, covered in CI pipeline service accounts counted as Fortify seats.
• Counting dormant role holders. Accounts that retain a role but have not acted within the measured window should not enter the sustained count.

Mapping roles to the license metric

The defensible approach is to map each role to its place in the license model. Where the metric counts scan submitters, only the roles that submit scans contribute to the count. Where the metric distinguishes named users from concurrent users, the role mapping feeds into that structure rather than overriding it, a point developed in Fortify named user versus concurrent user definitions. The role data is useful precisely because it lets the buyer sort accounts into the categories the metric cares about, rather than lumping them into a single consumer total.

Challenging an overstated headcount

The challenge is methodical. The buyer takes the audit team's consumer list, attaches each account's role, and then tests each role against the metric. Viewers, reviewers, administrators with no scanning activity, service accounts, and dormant holders fall out. What remains is the population the metric actually counts. The role data the vendor used to inflate the number becomes the same data that deflates it once it is read against the entitlement rather than as a flat headcount. This mirrors how to challenge a Fortify repository access headcount.

Evidencing the real picture

The buyer reconstructs the consumer count from SSC role exports combined with scan activity logs. The role export shows who holds what permission; the scan logs show who actually scans. Crossing the two produces a defensible count of consumers under the metric, with viewers and reviewers documented as the non submitting population they are. This reconstruction is part of reconciling Fortify entitlements before an audit, and it converts a role membership total into a metric based figure.

A representative outcome

In a recent engagement, a finding counted every SSC role holder as a licensed consumer, sweeping in managers with view access, security reviewers, and several service accounts. By mapping each role to the seat metric and crossing the role data with scan activity, we showed that the true consumer population was a fraction of the role holder total. 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 reduced a developer seat overclaim by 80 percent.

Reading roles for what they are

The discipline is to read SSC roles as access controls and to let the entitlement define the consumer unit. A role tells you what an account can do; the metric tells you whether that account counts. Keeping the two separate is what stops a governance feature from becoming a license liability. For the line by line method, see defending a Fortify developer seat finding line by line, and to map your roles against the metric you can open a case with our team.

How the four Rs apply to role data

Role data is reconstructed and rebutted in the same disciplined sequence. In the reconstruct stage we export SSC roles and cross them with scan activity to build a defensible consumer count under the actual metric, before any vendor script runs. In the rebut stage we challenge every account the finding counts that holds only a viewing or reviewing role, or that shows no activity in the measured window. In the resolve stage we settle on the metric based count and convert forward into an agreement whose consumer definition is explicit. The role export the vendor used to inflate the number becomes the same evidence that deflates it once it is read against the entitlement.

Administrators, integrations, and the edge cases

A few categories deserve specific attention. Administrators often hold powerful roles but may never submit a scan, so their inclusion in a consumer count depends entirely on the metric. Integration and automation accounts hold roles to function but are machine identities, not people. Shared or generic accounts used by a rotating group raise their own questions about how the metric counts them. Each edge case is resolved the same way: by mapping the role to the entitlement and testing it against actual activity. The buyer does not guess; it documents, and the documentation settles the edge cases the finding would otherwise resolve in the vendor's favor.

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