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 different 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 on an individual basis, 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 that their organization role permits and everything that 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; to see apps, the user must be assigned to one or more teams.
There are organization roles and team roles available.
|Super Admin||Permitted all actions except deleting the organization and deleting/demoting other super admins. Can add applications.|
|Power User||Permitted all app-related actions (including adding and deleting apps). Can add apps.|
|Member||Permitted all finding-related actions. Cannot destroy data (e.g., delete apps) and is limited to updating findings metadata.|
|Guest||Can view findings-related information.|
|Team Defined||Can log into the organization, but cannot access any data unless added to a team.|
|Collaborator||Deprecated. Orgs created after the release of RBAC will not be shown this option. Can perform any non-destructive action.|
|Team Admin||Permitted all app-related actions (including deleting apps) for their team. Cannot add apps to their teams.|
|Team Member||Can perform findings-related actions, but cannot destroy data (e.g., delete apps). Can update findings metadata.|
|Team Guest||Can view findings-related data.|
The following examples will show how organization roles and team roles work and how the permissions granted to a user are additive.
In this example, Alice is assigned to the ExampleCo org as team defined. In this case, she can log into ShiftLeft, but she will not be able to see any applications, findings, and so on.
In this example, Alice is assigned to the ExampleCo org as a member. She can see all applications, including findings data, but she can only modify the findings metadata.
In this example, Alice is granted a team defined role, which grants her permission to log in to the organization. She is also a member of Team A, which allows her access to App A and App B.