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
Scanner settings control how ZeroPath scans your repositories — which tools run, how findings are filtered, how PRs are handled, and when scheduled scans execute. Settings follow a cascading inheritance model.
Settings Inheritance
Settings are applied in a three-level cascade:
Organization (lowest priority)
↓
Tag (medium priority)
↓
Repository (highest priority)
- Organization settings apply to all repositories as the default baseline.
- Tag settings override organization defaults for repositories with that tag. Tags have a priority order — higher priority tags override lower ones.
- Repository settings override everything for a specific repository.
Only explicitly set values override — unset fields fall through to the next level.
Scan Module Toggles
Each scanning module can be enabled or disabled independently for full scans and PR scans:
| Module | What It Scans |
|---|
| SAST | Static code analysis across all supported languages |
| SCA | Dependency vulnerability scanning (runs as part of full scans; SCA scans are configured separately via scan scheduling) |
| IaC | Infrastructure-as-code misconfiguration detection |
| CI/CD | CI/CD pipeline security analysis (GitHub Actions workflows, pipeline configurations) |
| Secrets | Hardcoded credentials and API keys |
| EOL | End-of-life / unsupported dependency detection |
Key Settings
Full Scan Settings
| Setting | Default | Description |
|---|
| Confidence filter | Strict | Threshold for including findings: Strict (fewer, higher confidence), Balanced, or Permissive (more findings) |
| Auto-patching | Off | Automatically generate patches for qualifying findings |
| Auto-PR creation | Off | Automatically open PRs for generated patches |
| Patch threshold | 80 | Minimum score (0–100) for auto-patching |
| PR threshold | 80 | Minimum score for auto-PR creation |
| Custom rules only | Off | When enabled, disables all built-in scanning modules (SAST, SCA, IaC, Secrets, EOL) and only runs your custom natural-language rules against identified sources. You can toggle this directly from the Scanner settings page at the organization, tag, or repository level, or via the API. |
| Differential scanning | Off | When enabled, small code changes are evaluated with an AI-powered differential rescan instead of re-running the full scan pipeline, significantly reducing scan time for incremental commits. Dependency manifest changes are evaluated separately from code changes, so a small code diff can still trigger a fresh dependency analysis pass when needed. |
| Codex-enhanced differential scanning | On | When enabled, uses an advanced AI model for differential scanning and final validation of findings, improving accuracy for incremental scans |
| AppSec Assistant | Off | When enabled, activates an AI-powered application security assistant that can help with security-related questions about your codebase |
PR Scan Settings
| Setting | Default | Description |
|---|
| PR scanning enabled | Off | Master toggle for PR scanning. You can view the current PR scanning and PR summary status for each repository directly in the repository detail view and API response. |
| Inline review comments | On | Post inline comments on affected diff lines |
| PR summary (issues found) | On | Post a summary comment on PRs when the scan detects security issues. This is separate from inline review comments. |
| PR summary (clean scan) | On | Post a summary comment on PRs when the scan finds no security issues. Useful for confirming that a PR was scanned. |
| Check failure threshold | 75 | Score at which the VCS check is marked as failing. Must be greater than or equal to the comment visibility threshold. |
| Detailed vulnerability info | Not set | Include vulnerability descriptions, severity scores, and remediation details in PR summary comments. When not explicitly set, downstream settings (tag or organization level) apply. |
| Comment visibility threshold | 0 | Minimum score for a finding to appear in PR comments. Only available when inline review comments or PR summary comments are enabled. Must be equal to or less than the check failure threshold. The platform validates this constraint at every settings level (organization, tag, and repository) when you save changes and returns an error if violated. |
| Scan timeout | 10 min | Maximum time before the scan times out |
| Auto-patching | On | Generate fix suggestions for PR scan findings |
| Confidence filter | Strict | Same as full scan, applied to PR scans |
| Scan draft MRs | Off | Whether to scan GitLab draft merge requests |
| Scan bot PRs | Off | Whether to scan PRs opened by automation |
Fix Verification
You can reference existing ZeroPath issues directly in your PR description to verify whether your changes resolve them. Add ZP-ID: <issue-id> (one or more, comma-separated) or paste a ZeroPath dashboard issue URL into the PR body. When the PR scan completes, ZeroPath reports whether each referenced issue was still detected or fixed by the PR. After merge, verified fixes are automatically marked as resolved. No additional settings are required — fix verification activates automatically when issue references are present. See the PR Scans tab in SAST Overview for reference format details.
PR Templates
Customize the appearance of auto-generated fix PRs:
| Template | Description |
|---|
| PR title template | Custom format for generated PR titles |
| PR description template | Custom format for PR descriptions |
| Branch name format | Custom format for fix branch names |
| Commit message format | Custom format for fix commit messages |
Scan Scheduling
Configure recurring scans using cron expressions:
- Navigate to your repository’s scanner settings.
- Under Scan Schedule, click Add Scan Schedule to create a new schedule.
- Select a target branch from the dropdown (defaults to the repository’s default branch).
- Enter a cron expression (e.g.,
0 2 * * 1 for every Monday at 2 AM), or use a preset (Weekly, Monthly, Quarterly).
You can create multiple schedules for a repository to scan different branches on different cadences. Each schedule is displayed with its target branch and the estimated time until its next run. When editing an existing schedule, only the cron expression can be changed — the target branch is fixed at creation time. You can also delete individual schedules directly from the schedule list.
The scheduler only creates new work when the branch’s head commit has changed since the last scan, avoiding redundant processing. For schedules that cover multiple repositories (such as organization-wide or tag-based schedules), each repository is evaluated independently — an in-progress scan on one repository does not delay or block scheduled scans for other repositories in the same schedule.
Bulk Scheduling
You can apply a scan schedule to multiple repositories at once from the repository list. Select the repositories you want to schedule, then configure a shared cron expression. Bulk schedules always run on each repository’s default branch.
If any selected repository has multiple scan schedules configured, bulk editing is disabled. You will see a warning identifying which repositories need to be managed individually.
SCA scans configured via scheduling run independently of full scans. Their results appear on the Supply Chain page but not on the Issues page. If you notice more SCA findings on the Supply Chain page than on Issues, this is expected — scheduled SCA scans may detect vulnerabilities between full scans.
History Cutoff
You can configure a history cutoff date for a repository to ignore all scan and vulnerability history before that date. This is useful when onboarding an existing repository and you want a clean baseline without inheriting legacy findings from older scans. When a history cutoff is active, full scans will only consider previous scan results created after the cutoff date. The cutoff is also applied during deduplication and dependency analysis, so new findings are not incorrectly matched against issues from before the cutoff.
Branch Filtering
When viewing issues or scan history for a repository, you can filter by branch using the branch dropdown in the toolbar. This lets you focus on findings from a specific branch without switching between scan results manually.
- On the Issues tab, clicking the branch indicator opens a dropdown listing all branches that have been scanned. Selecting a branch filters both the scan selector and the issues displayed to only those from scans on that branch.
- On the Scans tab, a branch filter appears in the toolbar when multiple branches have been scanned. You can select a specific branch or view all branches at once.
Branch selectors throughout the platform support server-side search and pagination, so repositories with a large number of branches load quickly and can be searched without loading the entire branch list upfront.
Scan Explorer
You can quickly open the scan explorer for a repository’s latest full scan directly from the repository list. Each repository row includes an Explore link that navigates to the scan explorer view, giving you a detailed breakdown of the most recent scan results without navigating through the scan history.
Scan Optimizations
ZeroPath applies several optimizations to reduce scan time without sacrificing coverage:
- Identical-commit carry-forward: When a full scan targets the same commit and scanner settings as the previous successful scan, all findings are carried forward instantly without re-running the scan pipeline. You will see these scans complete in seconds. The scan explorer automatically resolves carry-forward scans by displaying results from the most recent full analysis of the same commit, so you always see complete scan data even for carried-forward scans.
- Differential scanning: When enabled in scanner settings, small code changes since the last scan are evaluated using an AI-powered differential rescan rather than re-running the full pipeline. If the diff is too large or the scan is the first for that branch, the full pipeline runs as usual. Dependency manifests and lockfiles are evaluated separately from code changes — when the differential rescan handles the code side, a fresh dependency analysis pass still runs if dependency files have changed, so new CVEs are caught without waiting for the next scheduled full scan.
- Monorepo patch deduplication: In monorepos, when multiple SCA vulnerabilities affect the same package in the same manifest file, ZeroPath generates a single fix patch and links it to all related findings, avoiding duplicate fix PRs.
- Branch-scoped full scan deduplication: Full scan findings are deduplicated per-branch, so each branch maintains independent issue lifecycle. Resolving an issue on one branch does not affect the same issue on another branch.
- PR scan deduplication scoping: PR scan findings are deduplicated only against full scan baselines and rescans of the same PR — never against findings from other pull requests. This prevents cross-branch contamination where a finding from one PR could incorrectly suppress or inherit state from an unrelated PR.
- Contributor attribution refresh: When an existing finding is re-detected on a subsequent full scan, ZeroPath refreshes the git blame attribution and code location data for that finding. This keeps contributor information and line numbers accurate as your codebase evolves, without creating duplicate entries.
- Minified file handling: When code snippets from files with very long lines (such as minified JavaScript or bundled assets) are sent for AI analysis, ZeroPath automatically truncates individual lines to prevent them from consuming the analysis context window. The full, unmodified code is preserved in the database and UI — only the AI-facing copy is trimmed.
- IaC path correction: When an IaC scanner reports a finding with a file path that does not match the repository layout (for example, a Helm chart template path relative to the chart name instead of the repo root), ZeroPath automatically searches for the correct file and adjusts the path. If the path cannot be uniquely resolved, the finding is skipped rather than surfaced with an incorrect location.
- Manual scan prioritization: User-triggered scans are prioritized over scheduled scans in the processing queue. A large batch of scheduled scans will not delay your interactive scan requests.
When ZeroPath determines that a vulnerability cannot be automatically patched, it provides remediation instructions alongside the reason the patch could not be generated. You can find these instructions on the vulnerability detail page to guide manual resolution.
Initial Repository Indexing
When you add a new repository and trigger its first scan, the scan status displays as Indexing instead of the usual in-progress status. This indicates that ZeroPath is performing first-time analysis of the repository, which typically takes longer than subsequent scans because the full codebase must be processed from scratch. Once the first scan completes successfully, future scans display standard progress statuses.
Scan Error Reporting
When a scan fails, ZeroPath displays a specific, actionable error message describing what went wrong rather than a generic failure notice. You can view these messages in the scan status to understand whether the issue is transient (e.g., a timeout or connectivity problem) or requires action on your part (e.g., invalid repository configuration).
Scan Retry Resilience
If a scan is interrupted and needs to restart (for example, due to a transient infrastructure issue), ZeroPath automatically recovers from the previous attempt without creating duplicate findings. The platform detects which results were already persisted before the interruption and resumes from where it left off, so you do not see duplicate findings or missing data after a scan retry. When a batch of results encounters a conflict with previously persisted data, the platform retries each operation individually so that non-duplicate results still land successfully. This recovery works reliably even for large repositories with thousands of findings.
Issue Status Preservation
When a scan refreshes issue statuses, ZeroPath preserves manual workflow states you have set. If you move an issue to Reviewing or Backlog, subsequent scans will not reset it back to Pending Review. Statuses driven by automated actions — such as archived, silenced, false positive, or patching — continue to update normally based on the latest scan results.
When you resolve an issue, any silenced state on that issue is automatically cleared. If you need to reverse an accepted-risk (archived) decision, you must unarchive the issue before resolving it — resolving alone does not undo an archive.
False Positive Context Requirement
Organizations can require users to provide a reason when marking issues as false positives. When this requirement is enabled, the false positive dialog checks your team’s policy upfront and clearly indicates that context is required before you can submit. If you attempt to mark an issue as a false positive without supplying a non-empty reason, the submission is blocked. This ensures that triage decisions are documented and auditable, making it easier for other team members to understand why a finding was dismissed.
Scan Scope Controls
Directory Partitions (Monorepo Support)
For monorepos, configure directory partitions to scan specific sub-directories as independent applications:
- Each partition is analyzed separately with its own application discovery.
- PR scans route to the correct partition based on changed files.
Custom Sources & Sinks
You can define custom source and sink declarations to teach ZeroPath about security-relevant entry points and sensitive operations specific to your codebase. Manage these from the dedicated Custom Sources & Sinks page, which is organized into three tabs:
- Custom Sources — declarations for security-relevant data entry points in your code.
- Custom Sinks — declarations for sensitive operations where tainted data should not reach.
- Library — browse and enable pre-built Source Packs and Sink Packs published by ZeroPath that cover common frameworks and libraries.
Each declaration includes a name, a natural language description that the scanning engine uses to identify instances in code, an optional glob pattern for file scope, and a repository scope (all repositories or specific ones). You can also assign tags for organization.
When you create or update a custom source or custom sink declaration, ZeroPath automatically validates the description using AI to ensure it describes a legitimate security-relevant data entry point (for sources) or sensitive operation (for sinks). If the description is ambiguous, nonsensical, or does not match the declared type, the platform rejects the declaration with a specific reason. This validation runs on both create and update operations whenever the description field changes.
Deleting a custom source or sink requires confirmation. Existing findings from the deleted declaration retain their data but lose the link back to the declaration.
Path Whitelist / Blacklist
Use scan location sets to control which files are included or excluded during full scans. Each location set includes a name, optional description, and two pattern lists:
- Whitelist patterns — only scan files matching these patterns.
- Blacklist patterns — exclude files matching these patterns.
You can choose whether a location set applies to all repositories or specific repositories. Patterns can be entered one at a time or in bulk using the Bulk Edit toggle. Deleting a location set requires confirmation.
Configuring Settings
SCA Fix PR Conflict Resolution
When ZeroPath creates a pull request to fix a vulnerable dependency, the base branch may receive new commits that conflict with the fix branch. ZeroPath automatically detects and resolves these conflicts:
- Lock file conflicts are resolved by regenerating the lock file using a sandboxed package manager execution.
- Manifest conflicts are resolved by re-applying the version bump on the latest base branch and regenerating lock files.
- Code conflicts (non-dependency files) require manual resolution.
This keeps auto-generated fix PRs mergeable without manual intervention in most cases.
From the Dashboard
- Navigate to Scanner in the ZeroPath dashboard.
- Select the Organization, Tag, or Repository level.
- Modify settings as needed.
- Changes take effect on the next scan.
Issue Export Options
When exporting issues via the API, you can customize the output with additional options:
- Export filter overrides — narrow the export to specific severity levels, statuses, or detection types without changing your saved filter configuration. If any override array is empty, the export returns no results for that dimension.
- SARIF options — control whether the export includes
preconditions (exploitability factors the scanner could not fully verify) and attackSteps (step-by-step exploit walkthroughs) for each finding. Both are omitted by default to keep export payloads compact.
From the API
Scanner settings can be read and updated via the v2 API:
# Get settings for a repository
curl -X POST https://zeropath.com/api/v2/scannerSettings/get \
-H "Content-Type: application/json" \
-H "X-ZeroPath-API-Token-Id: your-token-id" \
-H "X-ZeroPath-API-Token-Secret: your-token-secret" \
-d '{"organizationId": "your-org-id", "repositoryId": "your-repo-id"}'
