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. Enter a Team Name and click Create Team.
4. Click the new team in the list (or choose Manage Team from its row menu) and add members on the Members tab.
5. Assign repositories on the Repositories tab, and choose what the team can do on the Permissions tab.

​

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. Personal GitHub account installations (as opposed to organization installations) do not support teams. ZeroPath detects this automatically and skips the team sync step for those installations, so they do not interfere with the sync for your organization installations. The sync section is shown only when your organization has a GitHub App installation. It 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.

If loading the sync status fails, an error message appears with a Retry GitHub sync status button.

​

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.

​

Directory Team Sync

If your organization uses a directory provider (such as an identity provider that exposes groups), you can map directory groups to ZeroPath teams. This keeps team membership in sync with your directory automatically, so access follows your organization’s group structure without manual updates.

​

Configuring directory sync

1. On Settings → Teams, find the Directory group mappings panel. It appears once your organization has a connected directory.
2. Check Enable directory team mappings.
3. Choose a Directory, a Group, and a Team, then click Add mapping. Repeat for each group you want to map.
4. Click Save mappings to persist your mappings. While mappings are enabled, you must have at least one mapping to save.

Only manually created teams can be mapping targets. The default team and teams imported from version control cannot be selected.

​

How it works

• Automatic sync — once configured and enabled, ZeroPath periodically syncs group membership from your directory. When a user is added to or removed from a directory group, their ZeroPath team membership is updated on the next sync.
• Manual sync — click Sync now to trigger an immediate sync without waiting for the next scheduled run. The button is available once mappings have been saved and while there are no unsaved changes.
• Member sources — when viewing a team’s members, each member shows how they were added. Members added through directory sync display the directory group they came from (for example, “Directory: Engineering”), while manually added members show “Manual access” and members added through the default team show “Default team”. A member can have more than one source. This makes it easy to audit which memberships are directory-managed and which were set by hand. Members whose access comes entirely from a directory group cannot be removed from the team directly; use Keep manual access to add a manual grant alongside the directory one.
• Conflict prevention — a team with active directory mappings cannot be made the default team. Remove its directory mappings first. Deleting the last mapped team requires disabling directory sync first.

The configuration panel shows the current sync status, including whether sync is enabled, the last successful sync time, and any errors from the most recent run. Users with the team management permission see the full error text; other users see a notice that the sync failed and that an organization administrator can view the details.

​

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, changing member roles, 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. The sidebar entries Repositories, Containers, Issues, Scans, Assistant, Code Governance, Reports, SLA, and Audit log, and the pages in the Settings menu, are only shown when the user has at least one relevant permission for them. Integrations and Settings are always shown. In the sidebar’s + menu, Start scan is hidden for users who lack the scan-start permission and Add repository for users who cannot create repositories (see Navigation). 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 Settings pages such as Rules, Repository context, Scan locations, Sources & sinks, Members, Notifications, and Repository 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 Settings menu entry is visible. If a user cannot see the Rules or Sources & sinks page in the Settings menu, 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 repository tags. When you select a tag, the team receives the configured repository permissions on every repository that belongs to that tag. Access follows the tag’s membership as repositories join or leave it, so the team needs no changes 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.

The Tags section lists each tag by name. A team granted a Default tag gets access to every repository, including repositories added later, except repositories excluded from the tag. Which repositories belong to a tag is set on the Repository tags page: by hand, by GitHub custom property filters, or as a Default tag, with pins and exclusions that keep your choices in place when properties change. Because a tag that grants team access controls what the team can see, any save that can change its membership shows a Confirm access change step listing the repositories that will join and leave. A team’s Repositories tab lists the tags granted to the team under Access via tags, as read-only chips that show each tag’s name. You can’t remove a repository the team reaches through a tag from this list. To revoke tag-based access, remove the tag in the Permissions tab.

​

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 lifecycle that maps to team workflows. You change a finding’s status from the status menu on the issue page and in the issue panel, or by moving its card on the Issues Board view. Moving a finding to a closing status opens a dialog for the reason first, and accepting risk also asks how long the risk is accepted. See Issues for the board, the dialogs and the permission each move needs. The Issues page groups these statuses as Open (Needs review, Backlog), In progress (Reviewing, Patching) and Closed (Resolved, Non-exploitable, False positive, Accepted risk).