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 Team Sync

You can map your GitHub team structure onto your ZeroPath organization’s access-control teams. 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 hourly schedule. You can toggle this on or off from the GitHub Team 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.

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.

After a sync completes, any GitHub contributors that could not be matched to a ZeroPath user account are surfaced in the Unmatched Contributors panel for manual linking.

​

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 are applied universally, meaning synced teams receive these permissions across every repository in the organization. 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

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.