Repository Context

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 Settings → Repository context (under Scanner in the Settings menu).
Click “Add Context”.
Optionally enter a title — a short label (up to 120 characters) that identifies the context rule in the list. If you leave it blank, the context list displays a preview of the context body instead.
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), specific repositories, or selected tags.
Optionally expand Advanced Settings to configure which scan phases the context applies to. Source types can be configured through the API or MCP. See Targeting below for details.
Expand Tags to select tags. The context also applies to repositories assigned to those tags; tag scope requires at least one tag.
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 Repository context page.

This workflow is the fastest way to teach ZeroPath about patterns specific to your codebase.

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. In the dashboard, these appear as checkboxes under Advanced Settings. New dashboard entries select all phases below except File Filtering and Patch Generation. The API defaults are listed separately. 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
Runtime validation	Validating potential vulnerabilities against a running application
File filtering	Deciding which files to exclude from analysis
Patch generation	Generating fixes for identified vulnerabilities

If you are unsure which phase to select, keep the defaults and adjust them as you refine where the context is relevant.

Input Types

Limit context to specific types of data entry points with applicableSourceTypes through the API or MCP. This is useful when your context only applies to certain kinds of input handling:

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

New context applies to all input types by default. Supply specific source types to narrow the scope. Dashboard edits preserve this selection.

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

Organization-scoped context automatically applies to newly added repositories without any manual update. Context rules stack across levels — a repository receives its own context plus any tag-level and organization-level context that applies to it. More specific scopes do not replace broader ones.

Managing Context

Using the API or MCP

Repository context can also be managed through the public v2 API and the local or remote MCP server. Both use the same context definitions as the dashboard.

POST endpoint	MCP tool	Purpose
`/api/v2/contexts/list`	`contexts.list`	List contexts, optionally filtered by repository
`/api/v2/contexts/get`	`contexts.get`	Read one context by `contextId`
`/api/v2/contexts/create`	`contexts.create`	Create context and return its `id`
`/api/v2/contexts/update`	`contexts.update`	Update an existing context by `contextId`
`/api/v2/contexts/delete`	`contexts.delete`	Atomically delete entries in `contextIds`

For REST requests, supply your API token ID and secret in the X-ZeroPath-API-Token-Id and X-ZeroPath-API-Token-Secret headers. Supply organizationId explicitly when needed to select an organization. Local MCP can inject it from ZEROPATH_ORG_ID; remote MCP binds it to your authorized organization. Create context for a repository:

{
  "organizationId": "your-organization-id",
  "repositoryIds": ["your-repository-id"],
  "title": "Gateway authentication",
  "context": "All endpoints in src/api require JWT authentication at the API gateway.",
  "globPattern": "src/api/**",
  "applicableSourceTypes": ["HTTP_HANDLER"],
  "scanPhases": ["TECHNICAL_VULNERABILITY_INVESTIGATION"]
}

Creation returns { "id": "created-context-id" }. Omit scope fields to apply to all current and future repositories, pass repositoryIds for direct assignments, or pass nonempty tagIds alone for tag scope. You can also set scope explicitly to allRepositories, repositories, or tags. Tag assignments stack with direct repository and organization assignments. Conflicting selectors, empty repository selections, and empty tag-only selections are rejected. Creation requires nonblank context. The default glob is **; omitted or empty applicableSourceTypes applies to all source types. Omitted scanPhases uses the existing default phases: application identification, source identification, sink identification, technical vulnerability investigation, file AST blacklisting, logic vulnerability investigation, natural language rule investigation, and patch generation. Add RUNTIME_VALIDATION explicitly when that phase should receive the context. Update only the text without changing scope or other targeting:

{
  "contextId": "created-context-id",
  "context": "The API gateway validates JWT signatures and audiences before forwarding requests."
}

Updates preserve omitted fields. Send an empty title to clear it, or allRepositories: true to move context to organization scope. Updating tagIds replaces direct tag assignments while preserving scanner-setting assignments; use scope: "tags" with nonempty tagIds to switch to tag-only scope. Unknown IDs return 404 instead of creating a new entry. List with { "repositoryId": "your-repository-id", "limit": 20 } to include direct context plus inherited organization and matching tag context. Each entry appears once. Results contain items, hasMore, and nextCursor; pass nextCursor as cursor to fetch the next page. The maximum limit is 100. Returned repositoryIds are direct assignments; allRepositories and tags describe broader applicability. Delete with { "contextIds": ["created-context-id"] }. Every ID must exist and be authorized; a failed bulk request deletes nothing. Concurrent assignment changes return 409 so you can reload before retrying. Reads require permission to view repository context. Writes and deletes require the corresponding context permission over the entire affected scope, including both old and new assignments when scope changes. Remote MCP additionally requires read consent for list/get and write consent for create/update/delete. Changes take effect on subsequent scans.

Using the dashboard

From the Repository context page you can:

View all context rules for your organization in a table showing the title (or a preview of the context body if no title is set), 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.

Getting Started

Assets

Findings

Scanning

SCA

Platform

Developer Tools

Integrations

Authentication

Overview

Why Use Repository Context

Reduce false positives

Improve accuracy

Tailor to your stack

Creating Repository Context

From the Dashboard

From a False Positive

Targeting Context

File Patterns

Scan Phases

Input Types

Context Scope

Managing Context

Using the API or MCP

Using the dashboard

Best Practices

​Overview

​Why Use Repository Context

Reduce false positives

Improve accuracy

Tailor to your stack

​Creating Repository Context

​From the Dashboard

​From a False Positive

​Targeting Context

​File Patterns

​Scan Phases

​Input Types

​Context Scope

​Managing Context

​Using the API or MCP

​Using the dashboard

​Best Practices

Overview

Why Use Repository Context

Creating Repository Context

From the Dashboard

From a False Positive

Targeting Context

File Patterns

Scan Phases

Input Types

Context Scope

Managing Context

Using the API or MCP

Using the dashboard

Best Practices