Teams and roles

ScanSuite divides all work into teams. Products, scans, findings, assets, credentials, reports, schedules and integrations belong to exactly one team. People see and change only the data of their own teams, and in each team only what their role there allows. This page covers what each role may do and how a team admin sets up a team on the Teams page.

How teams keep data apart

• Every page shows which team you are working in. Lists, search and reports cover that team only.
• Scans, schedules and reports belong to the team they were started in. Suspending a team stops its running scans.
• Nobody outside a team can open its findings, reports or files. Even a system administrator sees them only after becoming a member of the team.

Working in more than one team

Your role in the current team is shown under your name at the top right. If you belong to several teams, switch between them in the same menu under Switch team. A link with ?team=<TEAM_SHORT_NAME> opens a page directly in that team.

zoom_inEnlarge

Roles

Roles are per team: someone can be an administrator in one team and a reader in another. There are four, from the most rights to the fewest:

• Vulnerability manager suits an analyst who triages results without running scans: they work findings, assets and credentials but cannot start scans, run exploits or delete anything.
• Readers see that credentials exist and where they were found, but not their values.
• Readers can download every report and export the pages offer.
• A service account can be an Operator or a Reader (Reader by default), never a team admin.
• Single sign-on groups map to the same four roles, see Single sign-on.

The team page

Everything about a team as a whole is on the Teams page, which opens from the user menu or from the Admin section of the sidebar. It has these tabs:

Members whose role does not allow a change see the settings read-only; each card says who can change it. Each card has its own Save button. Team settings are changed in the browser only: there is no command-line or API-token route for members, allowed targets, the team's AI or service accounts.

zoom_inEnlarge

Get a new team ready

A team admin works through Overview → Get this team ready. Each item has a button that opens the card where it is done:

Check: each item turns green as it is done, and the card's status reads Ready instead of N to do. Members are added as described in Members and accounts.

The team's AI

On the AI tab, in the AI provider card, a team admin chooses what to Use and clicks Save:

Test connection checks the saved choice. The fields of connections and models, and how to route each task, are described in AI providers and cost.

The Monthly token budget card shows the tokens used this month and caps them: Tokens a month, empty for no team limit. When the budget is reached, AI features pause until the next month. If a system administrator also set a limit, the lower one applies.

zoom_inEnlarge

How AI handles findings

Team admins and operators change this card on the AI tab:

Allowed targets

Web applications and infrastructure can be scanned only within the targets a team admin allows. The Web targets and Infrastructure targets cards on the Scanning tab each have a mode under Allow:

Click Add target for each entry, then Save:

Check: open Check whether targets are allowed, enter the addresses you plan to scan under Targets, one per line and click Check. Each line reads Allowed: <target> or Not allowed: <target>. Nothing is changed.

A team created in System Settings starts with an empty list and checking while the scan runs, so its administrator has to add targets before the first web or infrastructure scan. A scan whose target is not allowed is refused, and the scan names the target and the reason, see Managing scan execution. The rules for writing targets in the scan forms are in Web App Scanning.

zoom_inEnlarge

Scan credentials

Saved keys and passwords are stored encrypted and never shown again. Scans already queued keep the version they started with. Team admins and operators change these cards on the Scanning tab.

Team SSH key

The Team SSH key card holds the Private key that clones private repositories over SSH for schedules, pipeline scans, and members who have not saved a key of their own under My account. A key protected by a passphrase cannot be used. Once saved, the card shows the key's fingerprint; Remove deletes it. How repository access works as a whole, with the Git service in System Settings and each person's own key, is described in Git repository authentication.

zoom_inEnlarge

Server account

The account authenticated infrastructure scans sign in to hosts with:

Save stores it, Remove deletes it. A credential a scan discovers can also be approved as the server account on the Credentials page, see Credentials. The OpenVAS and Acunetix scanner engines on the same tab are described in API keys for external systems.

Findings and reports

Remediation deadlines

The Remediation deadlines card sets how many days a new finding of each severity may stay open: 7 days for Critical, 30 for High, 90 for Medium and 180 for Low by default, 0 for no deadline. How due dates and overdue findings work is described in Vulnerability Management.

Scanner findings in Vulnerabilities

Whether the findings of the classic scanners (Semgrep, KICS, Trivy, Nuclei, ZAP, Wapiti, Acunetix, OpenVAS and others) are stored on the Vulnerabilities page as well as in their reports and DefectDojo. CI/CD quality gates count only stored findings.

Management reports

How the PDF reports and slides exported from the Products and Vulnerabilities pages present your team (see Reports and exports):

Integrations

Issue trackers, alerts and enrichment services on the Integrations tab, and the scanner engines on the Scanning tab, are described in API keys for external systems. Team admins and operators change them.

Service accounts and API tokens

Pipelines and scripts work with a team through a service account's token, not a person's password. The card Automation and API tokens on the People tab also shows This team's name in pipelines and API addresses (SCANSUITE_TEAM).

1. 01
   Create the service account

   Under New service account enter a name such as gitlab-ci, pick the Role (Reader by default, or Operator to start scans) and click Create. The toast says "Service account <name> created."

2. 02
   Click New token in the account's row

   Enter a Token name and how many days it is Valid for (1 to 90, 30 by default), then choose what it can do (table below) and click Create token.

3. 03
   Copy the token from Your new token

   The dialog shows the token once, the team's name (SCANSUITE_TEAM) in its own row, and two ready-to-run test commands.

4. 04
   Test it

   Paste either command under Test the connection into a terminal. It answers with what the token may do, or says why the server refuses it. With a self-signed certificate, add -k to curl.

A token can never do more than its service account's role allows. It is sent as Authorization: Bearer <token>; how pipelines use it is in CI/CD and automation.

In the list, each service account shows its tokens with expires <date>. Revoke ends one token at once. Deactivate stops every token of the account until you Activate it again.

zoom_inEnlarge

When access is denied

When a page is not available, ScanSuite shows Access denied. Members and former members of the team are told why: their membership is suspended or revoked, the team is suspended, single sign-on is required, or their role does not allow it. The team's admin can help with those. Everyone else is only told that they have no access.

zoom_inEnlarge