Teams and roles
How teams separate data, what each role can do, and the team settings.
ScanSuite separates work into teams. Products, scans, findings, assets, credentials, rules, reports, schedules and integrations all belong to exactly one team. A person sees and changes only what belongs to the teams they are a member of, with the permissions of their role in each one.
An upgraded installation starts with one team that holds all of its existing data. See Upgrading to teams.
How teams are separated
- Every page and every API request works in exactly one team. Pages show which team they belong to, and anything they change is sent for that team only, so switching team in one browser tab never redirects the work of another tab.
- The database enforces the separation as well as the application: the application connects with a restricted database role, and row-level security returns only the current team's rows.
- Background work (scans, schedules, report imports, proof-of-concept runs) is admitted for a team and runs in that team only. A scan whose team is suspended, or whose targets the team's policy no longer allows, stops.
- Stored reports and files are reachable only by the team that owns them.
Working in several teams
Someone who belongs to more than one team switches between them from the user menu at the top right (Switch team). The menu also shows the role they hold in the current team. A link with ?team=<team> opens a page in that team.
Roles
A person's role applies to one team only; they can be a team admin in one team and a reader in another. There are four roles:
| Capability | Team admin | Operator | Vulnerability operator | Reader |
|---|---|---|---|---|
| View products, scans, findings, assets and reports | Yes | Yes | Yes | Yes |
| Export discovered credentials | Yes | Yes | Yes | Yes |
| Edit assets, credentials and findings; run proofs of concept | Yes | Yes | Yes | — |
| Start, stop and delete scans; schedules and rules | Yes | Yes | — | — |
| Manage products, integrations, target policies, AI and scan credentials | Yes | Yes | — | — |
| Manage members, sign-in and service accounts; read the audit log | Yes | — | — | — |
The same table is shown on each team's Members page. The server checks every action against it, whatever the page shows.
Vulnerability operators triage and verify findings without being able to start scans or change what scans target, which suits a remediation or AppSec review team.
Team settings
Team admins and operators configure their team in two places in the user menu:
| Where | What |
|---|---|
| Team integrations | DefectDojo, scanner accounts (Acunetix, OpenVAS, Snyk, Shodan, Dehashed, Securitm), email and Telegram notifications, and the Git repository settings. These belong to the team; another team never sees them. |
| Teams → Team settings | AI provider and monthly token budget, target policies, scan credentials, single sign-on, members and invitations, service accounts and API tokens, and the security audit log. |
AI provider
Each team chooses Use platform default (the AI configured by the platform administrator), Team override (its own OpenAI-compatible or Vertex AI configuration and key), or Disable AI. Test AI configuration checks the saved choice. A team may also set a monthly token budget; see AI providers and cost.
Target policies
Web application and infrastructure scans may only target what the team's policy allows. Each scan type has its own policy:
| Mode | Effect |
|---|---|
| Restrict to whitelist | Only the listed targets. A new team starts with an empty list, so nothing can be scanned until entries are added. |
| Restrict, and enforce during scans | As above, and every connection a scan makes is checked too, including redirects and addresses a hostname resolves to. Scanners that run in their own container cannot be checked this way and are refused. |
| Allow any target | No restriction. Use only where scanning anything is intended. |
Entries are a hostname (exactly that host), subdomains (any host under a domain, not the domain itself) or a network (an IPv4 or IPv6 CIDR range). Check targets shows, without saving anything, which targets the saved policy would accept. Tightening a policy also stops running scans whose targets it no longer allows.
Scan credentials
Scans use the team's approved credentials, never a person's own:
- Repository key: the private SSH key used to clone the team's repositories for static analysis. See Git repository authentication.
- Server account: the user name with an SSH key or password used by authenticated infrastructure checks. A credential found by a scan can also be approved as the server account from the Credentials page.
Values are never shown again once saved. A scan keeps using the version it started with; revoking a credential stops scans that still need it.
Service accounts and API tokens
For automation such as CI pipelines, a team admin creates a service account with a role and issues API tokens for it. Each token gets only the permissions chosen for it, within its account's role, and expires after at most 90 days. It acts only in its team, in an Authorization: Bearer header on the team API, and is shown once. Scheduled scans run as the team's built-in scheduler account rather than as the person who created the schedule.
Access problems
When a page is refused, ScanSuite says why to people who are, or were, members of the team: their membership is suspended or removed, the team is suspended or archived, the team requires single sign-on, or their role does not allow the action. Anyone else only sees that they have no access, so the page does not reveal which teams exist.
Last reviewed 2026-09-19