GitGuardian makes it easy for teams of any size to manage code security. The platform makes it simple to add secret detection, IaC scanning, and honeytokens into your defense strategy, no matter how large to code base or how many developers are involved. We also make it simple to manage access to the GitGuardian dashboard as your security team grows and you need to assign roles and permissions. Let's start by understanding the basic roles users can have in a GitGuardian Workspace. When we say Workspace, we are referring to the GitGuardian dashboard and all the incidents and tools it contains. There are 4 main roles for workspace members, The owner The Manager The member. And Restricted members Let's take a closer look at these roles, starting with The Owner If you created your GitGuardian account, then this is likely the role you have. It is the most powerful role, allowing you to full access to add or remove members, create and manage teams, and manage SSO settings and even delete the whole workspace. The Manager role is nearly as powerful as the Owner role, with the big exception that managers can not delete the workspace. This makes it easy to assign trusted team members full access to invite others, change workspace settings, and for customers on the Business plan or higher, create and manage API service accounts. The Member role is intended to let individuals access incidents and act on them accordingly but without the ability to add or remove other members themselves or modify any workspace settings. The fourth role is the Restricted member role. These are folks who have been invited, generally temporarily and with very limited access, only able to access specific assigned incidents on the platform. This is a very safe way to work with developers who need to be involved to close multiple incidents where they were the author or responsible for the remediation process. You can find a full matrix view of what actions each role can take listed in our documentation. You can quickly jump there by searching the docs for the keyword "role" For larger and more complex organizations, there is often a need to further group users by project. And some orgs also want to employ finer-grain access controls for Members, allowing only edit or view options. GitGuardian makes these goals easy to accomplish as well, thanks to Teams Teams let you group users to work on specific incidents related to specific repositories. They are also a way to give individual members fine-grain permissions for handling incidents or granting workspace members specific admin abilities within the team. By default, each account starts out with an All Incidents team already created, so let's start there for our explanation. As the name implies, members of this team can access all the incidents in your GitGuardian workspace. The owner is be default the first member of this team. All Managers in your workspace are part of the "All-incidents" team and cannot be withdrawn from it. From there it is up to Owners and Managers to invite other team members. Workspace members who are outside All-Incidents, like Members 1 and 6 in this example, will not be able to see this team under their settings and will need to be invited to it. As we will show in the demo section, they can be invited to this or other teams at the same time they are invited to your Workspace Once a workspace member accepts the invitation to join a team, the team managers can then set their permissions at a granular level For Incidents, Member's permissions can be set to: Full Access, allowing them to edit or share incidents with other workspace members outside the team The Can edit setting lets them resolve, ignore or comment on incidents. The most restricted permission level is "Can View" AS the name suggest team members can see incident details but can not otherwise interact with the incident. Teams Members can also be granted permission to administer the team. This is a great way to let team leads get their work done within the organization without granting them full Manager permissions for the whole workspace. The "Can manage" settings lets members edit team settings and add, remove members, and alter their permissions. Of course, the opposite is true as well; the "Cannot manage" setting removes these abilities GitGuardian allows anyone with Owner or Manager workspace roles to create custom teams. Custom teams give you a very granular way to divide the workload between the appropriate team members. In our example, we see the workspace owner is a member of Team X and Team Y but not part of Team Z. Unlike with the All Incident team, there is no requirement for Owners and Managers to be part of all custom teams, Just like with All Incident teams, though, each individual member can have finer-grain permissions granted or revoked. Each team can also customize which monitored repositories comprise its Permiter. For example, Team X might only care about one specific project, and Teams Y and Z might be managing the code security of different but related repositories in a microservices architecture. We really do make it easy to empower your team to handle incidents at scale. Next, Let's take a look at the dashboard to walk through how to add or remove workspace members and adjust their roles and then explore how to leverage teams. Let's start with Workspace member permissions: In the GitGuardian dashboard, click on settings towards the bottom of the left sidebar menu. Then click on Members in the WorkSsace Settings From here, you can see all the existing team members, any pending invitations, and at the top, the fields we need to invite a new user. When inviting them, you can choose to assign them to any existing teams. If they don't already have an existing GitGuardian account, they will be invited to create one and then will be able to accept your invitation. In the Members section, you can search for specific workspace members or filter by role or what teams they are assigned to. Here I am promoting one workspace team member to manager, and let's demote our existing manager to a member. This will not affect their team membership nor rights on that particular team. If needed, you can dismiss a workspace user from here using the trash bin icon on the right side of the screen. If you do so, they will also remove them from any associated teams. Next, let's move to look at managing teams In the Workspace settings menu, click on Teams From here, you can create a new team by clicking on the Create team button in the top right of the screen. All you need to get started is a new team name and optionally, you can provide a description, which we recommend to make it easier for others to understand why this team exists. Once created, your new team will appear in the My Teams section. Clicking on it or any other listed team will take you to the team management screen. Here you can manage your team members, inviting any Workspace member and assigning them incident and team permissions. In the perimeter section, Team managers can define the specific repositories they need to focus on, and all team members can quickly see which repos are in their perimeter. Anyone with the Can manage role can rename the org or update the description. GitGuardian also provides a full log of the changes made to the Team And Finally, and dangerously, Anyone with the Can manage role can delete the team. Back on the top level for Teams settings, There is a section for Other Teams. Anyone outside of a team can see all the available teams in a WorkSpace, excluding the special case of the default All-Incidents team. Workspace members can request to join one of the listed teams, which then prompts the team's managers to accept or deny their request. Thanks for watching and learning about GitGuardian workspace roles and teams management No matter how large your security team grows, how many developers you work with, or how many repositories you work to keep safe, GitGuardian can help make your life a lot easier when it comes to code security and secrets management.