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 GitHub collaborators that could not be matched to a ZeroPath user account are surfaced in the Unmatched Contributors panel for manual linking. If a sync encounters an error, a notification is displayed when it finishes so you can investigate and retry.

​

GitHub Sync Permission Mapping

When GitHub access sync runs, each GitHub role (Pull, Triage, Push, Maintain, Admin) 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. If you need more control, click the Permission Mapping button in the GitHub Access Sync section, or navigate to Settings -> Teams -> Permission Mapping:

1. The permission matrix shows GitHub roles as columns and ZeroPath repository permissions as rows, organized into groups (Repository Access, Issue Triage, Issue Tracker Export, Scans, Patches & Fixes, Repository Settings, Scan Locations, Scan Schedule, Rules & Context, and Destructive & Bypass).
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: 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. Groups include: 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

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. 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.