Documentation Index
Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
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
- Navigate to Settings → Teams in the dashboard.
- Click “Create Team”.
- Give the team a name and optional description.
- Add members by email or username.
- 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.
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:
- Click “Configure Defaults” to open the Default Team Permissions editor.
- Set the baseline permissions you want every new synced team to receive across three categories (see below).
- Click “Save Defaults” to persist your changes.
- 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:
| Group | Permissions |
|---|
| Member Management | Edit member roles, invite members, remove members |
| Team Management | View teams, create teams, manage teams |
| Installations | View, create, and delete VCS installations (GitHub, GitLab, etc.) |
| API Tokens | View, create, and delete API tokens |
| Alerts & Monitoring | View, edit, create, and delete security alerts |
| Custom Reports | View, create, and delete saved custom reports |
| Group | Permissions |
|---|
| Repository Access | View repository |
| Security Scans | View scans, start scans, cancel scans |
| Issue Management | Archive issues, mark as true/false positive, require context for false positives, open/close issues, edit priority, delete issues |
| Patches & Fixes | Generate patches, create pull requests |
| PR Security Checks | Bypass pull request security checks |
Permissions
ZeroPath uses role-based permissions at the organization level. Key permission categories include:
| Category | Permissions |
|---|
| Issues | View, manage, mark as false positive, require context for false positives, archive |
| Scans | Start scans, cancel scans, view scan history |
| Repositories | Add, remove, configure repositories |
| Agent | View, manage, and run the AI AppSec Assistant |
| Integrations | Connect and manage Jira, Linear, Slack, Wiz |
| API Tokens | Create, view, delete API tokens |
| Patches | Generate patches, approve patches, create PRs |
| Settings | Manage organization settings, scanner settings |
| Teams | Create, edit, delete teams |
| Custom Reports | View, create, delete saved custom reports |
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
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
Member Status
Organization members can be in an active or inactive state. Inactive members — for example, users deprovisioned through your identity provider — appear in the members list with an Inactive badge next to their name. Inactive members cannot have their role changed or be removed from the organization through the dashboard. This prevents accidental modifications to deprovisioned accounts while still giving admins visibility into who previously had access.
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.
| Status | Meaning |
|---|
| Pending Review | New finding, awaiting triage |
| Reviewing | Under active review by the team |
| Patching | Fix is being developed |
| Resolved | Fix has been applied (manually or via merged PR) |
| False Positive | Confirmed not a real vulnerability. Teams can optionally require that users provide a justification when marking findings as false positive (see Require Context for False Positives permission). |
| Accepted Risk | Known issue accepted by the team |
| Non-Exploitable | Technically present but not exploitable in context |
| Backlog | Acknowledged but deferred for later |
