Developers, application security staff, engineering managers, and auditors all use SCA output, but they need different views. Developers need findings in their repositories, security needs the whole estate, and auditors need read-only evidence. Decide these roles before a trial, and test them, so seat counts and access rules do not surprise you later.
Start from the jobs, not the org chart
List what each group does with the tool.
| Group | Typical job | Access they need |
|---|---|---|
| Developers | Fix findings in code they own | Their repositories, with fix guidance |
| Application security | Set policy, triage, report | All repositories, policy editing |
| Engineering managers | Track backlog and trends | Read-only metrics for their teams |
| Auditors or compliance | Collect evidence | Read-only, time-bound, no editing |
| Platform or IT admins | Connect source control, manage SSO | Administration, not necessarily findings |
Notice that only two rows need to edit policy or connect systems. Everyone else is a reader, which matters when a vendor counts seats.
Questions to ask during evaluation
- Can roles be scoped to a subset of repositories or business units?
- Is there a read-only role for auditors, and can access expire?
- Does the tool sign in through your identity provider, and does removing someone there remove their access here?
- Can a developer see findings in the pull request without a separate login?
- Is there an audit log of who changed a policy or dismissed a finding?
- How are service accounts and API keys scoped and rotated?
Ask the vendor to show each item, not describe it.
The dismissal question deserves its own test
The riskiest permission in an SCA tool is the ability to dismiss or suppress a finding. A developer who can silently dismiss a critical issue defeats the program. Test this in your trial: log in as a developer-level user, dismiss a finding, and check whether a reason is required, whether a reviewer is notified, and whether the action shows in the log.
Common mistakes
- Buying seats for every engineer when most only need pull request comments.
- Giving auditors an admin login because a read-only role does not exist.
- Leaving trial accounts and API keys active after the evaluation.
- Skipping the access test and only comparing scan results.
A worked example: a 120 person engineering team
Consider a company with 120 engineers, a four person security group, two engineering directors, an internal compliance lead, and an external auditor each year. A first guess might be to buy 120 or more seats. Now walk through the jobs.
- Engineers consume findings in pull requests and tickets. Most never need the console.
- Two or three senior engineers act as security champions and triage findings for their teams. They need developer level access with triage rights.
- The security group edits policy, connects source control, and reports. They need administrator and policy roles.
- The directors read team metrics. Read-only access to dashboards is enough.
- The compliance lead needs read access to policies, history, and exports.
- The auditor needs time-limited read access during the audit window.
In this layout, perhaps ten to fifteen people need a full console login, and the rest are served by integrations. Whether a vendor counts the rest as users is a commercial question to settle in writing, so ask exactly what counts as a seat and what counts as a viewer.
Step by step: map roles before the trial
- Make a list of every person or team that will touch SCA output.
- For each, write the single most important thing they must do with it.
- Mark whether they need to edit, triage, or only read.
- Mark whether they can get what they need from a pull request comment or ticket instead of the console.
- Turn the result into a roles table and give it to each vendor before the demo.
- During the trial, log in as each role and try to do something outside it. The attempt should fail with a clear message.
Access control details that are easy to forget
Look at what scope a role can have. If your company has several business units, a role limited to one unit's repositories prevents a tidy, well meaning administrator from altering another team's policy. Check whether policies can be inherited with local overrides, and who can change the inherited part.
Look at API keys. They often carry broader rights than any person. Find out whether keys can be scoped, how they are rotated, and whether the audit log records actions taken with them.
Look at offboarding. When a person leaves, does single sign-on removal remove access here, or do local accounts linger? Local accounts and old tokens are the usual leftovers.
What to keep as evidence
Auditors often ask who can change security policy and who reviewed access. Keep an export of role assignments with dates, and a note of when you last reviewed them. A quarterly review is a common rhythm, though the right interval is a decision for your own risk process.
Cost and fairness
Seat models vary, and details change, so do not rely on assumptions from articles or assistants. Ask each vendor to describe in writing how users, viewers, service accounts, and integrations are counted. Then compare the vendors on your roles table, not on a headline number.
Try it yourself
Click through it at your own pace, or open it full screen.
As you click, ask who on your team would own each screen, and whether they would need to edit or only read.
Quick check
Should every developer have an SCA login?
Not always. If findings reach them in pull requests or tickets, a separate login may be unnecessary. Decide by how developers will actually consume results.
What is the minimum access an auditor needs?
Read-only access to findings, policies, and change history, ideally time-limited. Avoid sharing an administrator account.
How often should I review who has access to the SCA tool?
Many teams review quarterly and after any reorganization, and keep a dated export of role assignments as evidence. Pick a cadence that matches your own access review policy.
Last reviewed: 19 October 2026.
