Teams & Permissions

​

Overview

ZeroPath uses a fine-grained authorization (FGA) system to control access to resources within your organization. Teams group users together and can be assigned to specific repositories, letting you control who sees what.

​

Team Management

​

Creating Teams

1. Navigate to Settings → Teams in the dashboard.
2. Click “Create Team”.
3. Give the team a name and optional description.
4. Add members by email or username.
5. Assign repositories the team should have access to.

​

Team Members

Teams can include:

• Users — people with ZeroPath accounts in your organization
• Contributors — code contributors identified from Git blame data (matched by email, name, or VCS username)

Contributors are automatically associated with teams when their git commit metadata matches a team member’s identity.

​

Linking Unmatched Contributors

When ZeroPath identifies code contributors that haven’t been matched to a user account, they appear in the Unmatched Contributors panel. From here you can:

• Search contributors by name, username, or email to quickly find the person you want to link.
• Search organization members within the assignment dropdown to find the right account.
• Link contributors individually — each contributor can be linked independently without blocking other link operations.

​

GitHub Access Sync

You can map your GitHub team structure onto your ZeroPath organization’s access-control teams. If your organization has multiple GitHub App installations (for example, one per GitHub organization or GitHub Enterprise Server instance), the sync covers all of them in a single pass so that every GitHub team and direct repository collaborator is represented. There are two ways to sync:

• Continuous (auto) sync — enable auto-sync to keep teams in step automatically. When enabled, ZeroPath syncs your GitHub teams on a recurring schedule. You can toggle this on or off from the GitHub Access Sync section in Settings -> Teams.
• One-off sync — click Sync now to run a single sync immediately, without enabling continuous sync. This is useful for a first-time import or a manual refresh.

Teams are matched by their stable GitHub identifiers, not by name. If a team or organization is renamed on GitHub, the corresponding ZeroPath team is automatically updated to reflect the new name on the next sync — no manual intervention required. When two GitHub organizations contain a team with the same name, ZeroPath automatically namespaces the display names to avoid collisions. If one of your GitHub App installations is temporarily unreachable during a sync, only that installation’s teams are left untouched. Teams from other installations are still updated normally, so a connectivity issue with one GitHub organization does not block the rest of the sync. The sync section shows:

• Whether continuous sync is currently enabled or disabled.
• The timestamp of the last completed sync, so you can confirm when team data was last refreshed.
• A progress indicator while a sync is in flight.

​

Direct Repository Collaborators

You can opt in to syncing direct repository collaborators — GitHub users granted access to a repository outside of a team. When enabled, these collaborators are synced alongside team members and appear with a “Direct Repository Access” badge in the unmatched contributors panel. To toggle direct collaborator sync, use the Enable Direct Access / Disable Direct Access button in the GitHub Access Sync section. Enabling it queues an immediate sync. Disabling it removes repository grants that were created from individual GitHub collaborator assignments. After a sync completes, any collaborators that could not be matched to a ZeroPath user account are surfaced in the Unmatched Contributors panel for manual linking. Each contributor shows a platform badge (GitHub or Bitbucket) so you can tell which VCS host the unmatched account came from. If a sync encounters an error, a notification is displayed when it finishes so you can investigate and retry.

​

Bitbucket Access Sync

If your organization has a Bitbucket installation, a Bitbucket Access Sync section appears in Settings → Teams. This section is only shown when a Bitbucket installation is present. It lets you import Bitbucket groups — both Bitbucket Cloud user groups and Bitbucket Server groups — as ZeroPath teams, and keep access in step automatically. There are two ways to sync:

• Continuous (auto) sync — enable auto-sync to keep Bitbucket group membership in step on an hourly schedule. You can toggle this on or off from the Bitbucket Access Sync section. Enabling it queues a first sync immediately.
• One-off sync — click Sync now (or Re-sync now) to run a single sync immediately without enabling continuous sync. Useful for a first-time import or a manual refresh.

The sync section shows:

• Whether continuous sync is currently enabled or disabled.
• The timestamp of the last completed sync.
• A progress indicator while a sync is in flight.

After a sync completes, any Bitbucket group members that could not be matched to a ZeroPath user account are surfaced in the Unmatched Contributors panel for manual linking, the same panel used for GitHub contributor matching.

​

Access Sync Permission Mapping

When access sync runs, each VCS role is translated into a set of ZeroPath repository permissions. By default, your organization follows ZeroPath’s built-in mapping, which improves over time without requiring any action on your part. The permission mapping editor is available for each connected VCS host:

• GitHub — roles are Pull, Triage, Push, Maintain, and Admin.
• Bitbucket — roles are Read, Write, and Admin.

If you need more control, click the Permission Mapping button in the relevant access sync section, or navigate to Settings -> Teams -> Permission Mapping:

1. The permission matrix shows VCS roles as columns and ZeroPath repository permissions as rows, organized into the same groups as the team permissions editor (Repository Access, Security Scans, Issue Management, Issue Tracker Export, Patches & Fixes, PR Security Checks, Repository Configuration, Scan Locations, Scan Schedule, Rules & Context, and Repository Deletion).
2. Click individual checkboxes to grant or revoke a specific permission for a role, or click the group header checkbox to toggle all permissions in that group at once.
3. Click Save Mapping to persist your changes. The custom mapping takes effect on the next sync.

To revert to ZeroPath’s built-in mapping at any time, click Use ZeroPath Defaults. This does not freeze the current defaults into your configuration — your organization resumes tracking any future improvements to the built-in mapping.

​

Default Team Permissions

You can configure baseline permissions that are automatically applied to teams created by GitHub team sync. This is especially useful when enabling access control for the first time, since newly synced teams start with no permissions by default. From Settings → Teams:

1. Click “Configure Defaults” to open the Default Team Permissions editor.
2. Set the baseline permissions you want every new synced team to receive across three categories (see below).
3. Click “Save Defaults” to persist your changes.
4. Click “Apply to All Teams” to backfill the configured defaults onto all existing teams in your organization. Existing permissions are preserved — defaults are added on top.

When you first enable access control, a warning banner explains that teams without configured permissions will have no access. You can dismiss this banner after configuring permissions for your teams or applying defaults.

​

Permission Categories

The default permissions editor organizes permissions into three categories, each shown with a summary count of how many defaults are currently selected: Organization Permissions — Controls what synced teams can do at the organization level, grouped into: Permissions reserved to the organization admin role (editing organization details or SAST configuration, billing, integrations, deleting members or repositories organization-wide, managing the assistant) are not offered, because a team grant of them is never honoured. Repository Permissions — Default repository permissions grant access across every repository in the organization. For teams created by GitHub team sync, default repository permissions are not automatically applied, because a GitHub-synced team’s repository access is derived from its GitHub repository grants. You can still apply repository defaults manually using “Apply to All Teams” if desired. The per-team editor, the defaults editor, and the VCS role mapping all use the same groups: Team Self-Management — Controls whether teams can manage their own settings and membership by default. Individual permissions include editing the team, adding members, removing members, and deleting the team. You can toggle entire permission groups at once by clicking the group header, or toggle individual permissions within a group. A Reset button lets you discard unsaved changes and revert to the last saved state.

​

Permissions

When you open a team’s permissions panel, all permission controls — including organization, repository, and team self-management toggles — are disabled until the current permissions have finished loading from the server. If loading fails (for example, due to a network error), an error message is shown with a Retry button so you can try again without leaving the page. The same applies to the tag list within repository access — if tags fail to load, you see an inline error with a Retry tags button, and any existing tag assignments are preserved. Users with the View teams permission can open a team’s detail modal to inspect its members, repositories, and permissions. If the user does not also have the Manage teams permission, the modal opens in read-only mode — all toggles, radio buttons, action buttons (Clear All, Select All, Reset), and member add/remove controls are disabled, so you can review the team’s current configuration without risk of accidental changes. The same read-only treatment applies to the permissions panel: all toggles and action buttons are disabled for users who lack manage permission. Adding and removing team members is governed by separate per-team permissions. When you open a team’s members list, the platform checks whether you are allowed to add members and whether you are allowed to remove members for that specific team. If either action is not permitted, the corresponding controls are disabled. Contributors (code committers identified from Git blame data who are not ZeroPath users) cannot be removed from teams directly — they must be managed through the identity provider or VCS sync. The platform’s navigation adapts to each user’s permissions. Sidebar links — including Scans, Issues, Repositories, Reports, Settings, and configuration pages — are only shown when the user has at least one relevant permission for that section. The Start Scan button is similarly hidden for users who lack the scan-start permission. This keeps the interface focused on the areas each user can actually access. On the Notifications settings page, all notification configuration controls — including channel toggles, event type checkboxes, vulnerability threshold inputs, repository and tag selectors, and Slack, Teams, and webhook channel checkboxes — are disabled for users who lack the edit alerts permission. You can still view the current notification configuration, but changes require the appropriate permission. Permission checks are also enforced server-side, so navigating directly to a page URL you do not have access to returns an Access Denied error rather than loading a blank or broken page. This applies to configuration pages such as Rules, Context, Locations, Custom Sources & Sinks, and settings tabs like Members, Notifications, and Tags. The error message tells you which permission to request from your organization admin. Read access to Custom Rules, Custom Sources, and Custom Sinks is gated by the same permission that controls whether the corresponding sidebar entry is visible. If a user cannot see the Rules or Custom Markers page in the navigation, the list and detail API endpoints for those resources also return an authorization error. API tokens and MCP admin sessions bypass this check, matching the behavior of write operations on the same resources. ZeroPath uses role-based permissions at the organization level. Key permission categories include:

​

Repository Access

Teams can be scoped to specific repositories. When assigning repositories to a team, you can search for repositories by name and the list supports pagination, making it easy to find the right repositories even in organizations with a large number of connected repos. When a team is assigned to a repository:

• Team members can view scan results and findings for that repository
• Notifications and alerts are routed to the appropriate team
• Git blame attribution links findings to team members who authored the affected code

​

Tag-Based Repository Access

In addition to selecting individual repositories, you can grant a team access to repositories through tags. When you select a tag, the team receives the configured repository permissions on every repository that belongs to that tag. Access updates automatically as repositories join or leave the tag — there is no need to manually adjust team membership when your repository set changes. To configure tag-based access:

1. Open a team’s settings and navigate to the Permissions panel.
2. Under Repository Access, select Selected repositories.
3. In the Tags section, select one or more tags to grant access to all repositories within those tags.
4. Save the team’s permissions.

Each tag shows the number of member repositories alongside its name. Tags that are auto-synced (membership is driven by GitHub custom properties) are labeled accordingly — team access follows automatically as the tag’s repository membership changes. Tags marked as default are automatically applied to every newly added repository, so teams granted access through a default tag receive access to new repositories without any manual step. When viewing a team’s Repositories tab, any tags that have been granted to the team are displayed as read-only chips at the top of the repository list. Each chip shows the tag name, the number of repositories it contributes, and whether the tag is auto-synced. Repositories inherited through a tag cannot be individually removed — to revoke tag-based access, remove the tag from the Permissions tab instead.

​

Managing Tag-Based Access via the API

When setting a team’s permissions through the API, you can include tagIds alongside repositoryIds to grant the team access to repositories through tags. The team receives the configured repoPerms on every repository that belongs to each listed tag. When reading a team’s permissions, the response includes:

• tagIds — the tags whose member repositories the team can access.
• repoAccess — a structured object with a mode discriminant ("universal" or "selected") that makes the team’s access model explicit. In "selected" mode, it includes repositoryIds (explicit per-repo grants) and tagIds (tag-scoped grants) alongside the granted perms.

​

Finding Details

When viewing a finding, ZeroPath displays contextual information to help your team triage effectively:

• Exploit steps — a step-by-step breakdown of how the vulnerability could be exploited
• Preconditions — conditions the scanner could not fully verify that may reduce exploitability. Each precondition includes a description and optional supporting evidence you can expand for more context. Preconditions help your team assess real-world risk by highlighting assumptions that must hold for the vulnerability to be exploitable.
• SCA vulnerability and reachability data — for dependency findings, package details and whether the vulnerable code path is reachable from your application
• Exploitation setup — when available, additional context about the conditions required to exploit the vulnerability is shown alongside preconditions, giving your team a more complete picture of real-world risk.
• Security Compass Countermeasures — when a finding was detected by a rule sourced from the Security Compass integration, a Countermeasures panel appears on the issue detail view. It surfaces the SD Elements countermeasures associated with that rule, giving your team the remediation guidance from Security Compass directly alongside the finding.
• Runtime Validation — when a finding has been tested dynamically, a Runtime Validation panel appears inline on the issue. It shows the verdict (e.g. Confirmed, Disconfirmed, or Unable), a timestamp, and a summary of the outcome. You can expand two collapsible sections for deeper detail:
  • Validated attack path / Validation path — for confirmed findings, step-by-step reproduction steps with numbered entries; for all tested findings, the sequence of agent actions and observed results.
  • Evidence and scope — a narrative summary of the evidence collected, plus the specific targets and roles that were tested. If the issue could not be tested dynamically, this section notes that testability was not possible.

​

Inviting Members

You can invite new members to your organization from Settings → Members. When adding invitees, you can assign each person a role — Member or Admin — at invite time, so they have the correct permissions from the moment they join. New invitees default to the Member role. You can add invitees one at a time or switch to bulk edit mode to paste a list of email addresses separated by commas or new lines. Bulk-added emails are assigned the Member role by default; switch back to the list view to adjust individual roles before sending invitations. If you re-enter an email address that is already in the invite list with a different role, the role is updated to reflect your latest selection.

​

Member Status

Organization members can be in one of the following states:

​

Issue Status Workflow

Findings follow a structured lifecycle that maps to team workflows. You can change a finding’s status directly from the issue detail view — status actions like marking as false positive, accepted risk, true positive, or resolved take effect immediately without a confirmation dialog, streamlining the triage process.