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
Repository context lets you provide ZeroPath with information about your codebase that it cannot infer from code alone. These are natural language descriptions that ZeroPath factors into its analysis during scans. For example, you might tell ZeroPath that a particular endpoint sits behind an authentication gateway, that a seemingly dangerous function only runs in development, or that a specific module handles already-sanitized input. This additional knowledge helps make more accurate decisions and significantly reduces false positives.Why Use Repository Context
Reduce false positives
Eliminate recurring false alarms by giving ZeroPath the domain knowledge it needs to understand
your architecture.
Improve accuracy
Context about authentication layers, input validation, and deployment boundaries helps ZeroPath
focus on real risks.
Tailor to your stack
Target context to specific files, scan phases, and input types so it applies precisely where it
matters.
Creating Repository Context
From the Dashboard
- Navigate to Context in the ZeroPath dashboard.
- Click “Add Context”.
- Write a natural language description of what ZeroPath should know. For example:
- “All endpoints in this service require JWT authentication via the API gateway — unauthenticated access is not possible.”
- “The eval() call in src/sandbox/ runs inside a restricted Docker container with no network access.”
- “Rate limiting is enforced at the load balancer level for all public-facing routes.”
- Optionally set a file scope using a glob pattern (e.g.,
src/api/**,*.py) to limit the context to specific files. The default is all files. - Choose the repository scope: apply the context to all repositories (including any added in the future) or select specific repositories.
- Optionally expand Advanced Settings to configure which source types and scan phases the context applies to. By default, all source types and scan phases are selected. See Targeting below for details.
- Optionally expand Tags to assign tags for organization and filtering.
- Save the context. Changes take effect on the next scan.
From a False Positive
When you mark a finding as a false positive, ZeroPath offers to automatically generate a repository context rule so the same pattern does not trigger again in future scans.Mark as false positive
On any finding, click False Positive and provide a reason explaining why it is not a real
issue.
Generate context
ZeroPath presents an option to Generate & Save Context. Click it to have ZeroPath AI create
a context rule based on your false positive reason and the details of the finding.
Context saved automatically
The context is immediately saved and targeted to the relevant repository and input type. There
is no additional review step — it takes effect on the next scan. You can edit or delete it later
from the Context page.
Targeting Context
Repository context supports three targeting axes that control when and where it is applied. The more precisely you target, the more effective the context is.File Patterns
Use glob patterns to limit which files the context applies to. The default is**, which matches all files.
| Pattern | Matches |
|---|---|
** | All files (default) |
src/api/** | All files under src/api/ |
**/*.controller.ts | All TypeScript controller files |
services/auth/** | All files in the auth service |
Scan Phases
Choose which stages of ZeroPath’s analysis should see this context. By default, all phases are selected. Select specific phases when your context is only relevant to a particular type of analysis. In the dashboard, these appear as checkboxes under Advanced Settings. ZeroPath’s scan pipeline runs through several phases. When creating context, you can select one or more of these to control when your context is applied:| Phase | What ZeroPath Is Doing |
|---|---|
| Application identification | Understanding what your code does — identifying services, modules, and entry points |
| Source identification | Finding where untrusted data enters your application (e.g., HTTP requests, file uploads) |
| Sink identification | Finding where data flows to sensitive operations (e.g., database queries, shell commands) |
| Vulnerability investigation | Evaluating whether potential issues are real, exploitable vulnerabilities |
| Logic analysis | Analyzing business logic for security issues beyond typical code patterns |
| Custom rule evaluation | Evaluating your custom rules against the codebase |
Input Types
Limit context to specific types of data entry points. This is useful when your context only applies to certain kinds of input handling. In the dashboard, these appear as checkboxes under Advanced Settings:| Input Type | Description |
|---|---|
| HTTP Handler | Web API endpoints and HTTP request handlers |
| File Handler | File upload and file system input processing |
| Stdin Handler | Command-line stdin and pipe input |
| Browser Data | Client-side browser input (cookies, local storage, DOM) |
| WebSocket | WebSocket message handlers |
| Socket | Raw TCP/UDP socket connections |
| CLI Argument | Command-line arguments and flags |
| Mobile Inputs | Mobile application user input |
Context Scope
Context can be scoped at three levels, following the same inheritance model as scanner settings:| Scope | Applies To |
|---|---|
| Organization | All repositories in the organization (leave repos/tags unassigned) |
| Tag | All repositories with the selected tag(s) |
| Repository | Only the selected repository or repositories |
Managing Context
From the Context page you can:- View all context rules for your organization in a table showing the context text, file pattern, assigned tags, and repository scope. Context rules that apply to all repositories display “All Repositories” instead of a count.
- Edit any context rule by clicking its row — update the text, targeting, or scope.
- Delete context rules individually or in bulk. Deleting a context entry requires confirmation to prevent accidental removal.
Best Practices
- Be specific and factual — “The /admin endpoints require mTLS client certificates enforced by the Nginx ingress” is better than “admin is secure”. The more concrete your context, the better ZeroPath can use it.
- Use the false positive workflow — when you dismiss a finding, always generate a context rule. This creates a feedback loop that continuously improves scan quality.
- Target narrowly — apply context to specific file patterns, scan phases, and input types rather than leaving everything at the default. Narrow targeting prevents irrelevant context from adding noise.
- Use tags for shared architecture — if multiple repositories share the same authentication gateway or infrastructure pattern, create one context rule scoped to a tag instead of duplicating it per repository.
- Review periodically — as your codebase evolves, revisit context rules to ensure they still reflect reality. Outdated context can cause ZeroPath to miss real issues.