Roles-based access control

The ShiftLeft dashboard allows you to collaborate with others regarding any security vulnerabilities identified. You can view vulnerabilities on a per-application basis, assign findings for review/follow-up, communicate with one another regarding specific vulnerabilities, and more.

Depending on their assigned roles, users can view different data and perform various actions in ShiftLeft.

Roles-based access control (RBAC)

Roles-based access control (RBAC) is the practice of assigning permissions to users based on their role within an organization. Because RBAC eliminates the need to set permissions individually, you get a more straightforward access management approach that's less error-prone.

RBAC in ShiftLeft CORE

There are several concepts you should be familiar with when working with ShiftLeft CORE's role-based access control (RBAC) feature:

  • A team is a group of users and applications (e.g., Team A consists of Alice, Bob, and Charlie and App1, App2, and App3).

  • All users must have a role in your organization

  • A user can belong to one or more teams. If a user belongs to more than one team, they must be assigned a role in the context of each team to which they belong. The roles do not have to be the same (e.g., Alice is an admin for Team A, whereas she is a member in Team B).

  • Roles that you assign to users are additive; this means that the user can do everything their organization role permits and their team roles permit.

  • Organization roles allow users to perform actions on an organizational level (e.g., log in to the organization and read basic information about the organization). However, this does not grant access to apps by default; the user must be assigned to one or more teams to see apps.


There are organization roles and team roles available.

Organization roles

Super AdminPermitted all actions except deleting the organization and deleting/demoting other super admins. Can add applications.
Power UserPermitted all app-related actions (including adding and deleting apps). Can add apps.
MemberPermitted all finding-related actions. Cannot destroy data (e.g., delete apps) and is limited to updating findings metadata.
GuestCan view findings-related information.
Team DefinedCan log into the organization, but cannot access any data unless added to a team.
CollaboratorDeprecated. Orgs created after the release of RBAC will not be shown this option. Can perform any non-destructive action.

Team roles

Team AdminPermitted all app-related actions (including deleting apps) for their team. Can add apps to their teams and move apps from one team to another, as long as they are a team admin for both teams.
Team MemberCan perform findings-related actions, but cannot destroy data (e.g., delete apps). Can update findings metadata.
Team GuestCan view findings-related data.

Sample usage

The following examples will show how organization roles and team roles work and how the permissions granted to a user are additive.

Example 1

Alice is assigned to the ExampleCo org as team definedin this example. In this case, she can log into ShiftLeft, but she will not be able to see any applications, findings, and so on.

RBAC Example 1

Example 2

Alice is assigned to the ExampleCo org as a memberin this example. She can see all applications, including findings data, but she can only modify the findings metadata.

RBAC Example 2

Example 3

In this example, Alice is granted a team defined role, granting her permission to log in to the organization. She is also a member of Team A, allowing her access to Apps A and B.

RBAC Example 3