Skip to main content

​
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 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: Toggle settings display their current effective state, accounting for the inheritance cascade. If a toggle has not been explicitly set at the repository level, it shows whether the value is inherited from the organization or tag level and what the current effective value is.

​
Key Settings

​
Full Scan Settings

​
PR Scan Settings

​
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: Templates support the following placeholders: Jira placeholders are populated automatically when the finding has a linked Jira ticket. If no Jira ticket is linked, the placeholder is omitted.

​
Scan Scheduling

Configure recurring scans using cron expressions:
  1. Navigate to your repository’s scanner settings.
  2. Under Scan Schedule, click Add Scan Schedule to create a new schedule.
  3. Select a target branch from the dropdown (defaults to the repository’s default branch).
  4. 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. If a scheduled scan is blocked due to insufficient credits and your organization has credit auto top-up configured, ZeroPath automatically attempts to purchase additional credits before blocking the scan. If the top-up succeeds, the scan proceeds normally. If it fails, the scan is blocked and the error message includes details about both the credit shortage and the top-up failure.

​
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. A severity filter is also available, letting you narrow the scan list to only scans that contain findings at specific severity levels (Critical, High, Medium, Low, or Info).
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.

​
Application Filtering

You can filter by application in two places:
  • Issues page — use the application filter in the issues toolbar to narrow the issues list to findings associated with specific applications. This is particularly useful for monorepos and repositories where ZeroPath discovers multiple distinct applications (services, modules, or entry points) during scanning.
  • Dashboard — the main dashboard includes an Issues by Application chart and an application filter in the filter controls. Select one or more applications to scope all dashboard widgets (severity breakdown, top issues, issues by repository, etc.) to only the selected applications. Your application filter selection is persisted per organization and restored when you return to the dashboard.
Application filters are scoped to the current organization. Switching organizations automatically resets the application filter.

​
Repository List

The repository list supports sorting by name, scan count, last scan date, and issue count. Clicking the issues count for a repository navigates directly to that repository’s issues tab for quick access.

​
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 discovery-affecting 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. Toggling post-processing settings — such as Automatic Runtime Validation, Auto-Provision Runtime Validation, or Codex-enhanced differential scanning — does not invalidate carry-forward, because those settings only prune or annotate findings that discovery already produced. Only changes to settings that affect which vulnerabilities the scan discovers (enabled modules, custom rules, confidence filter, models, etc.) require a fresh scan. 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.
  • Per-category settings invalidation: Settings changes are tracked per scanning category. When only rollover-safe settings change (such as dependency analysis configuration, model tier/performance mode, or enabling inventory modules), ZeroPath re-runs the affected category fresh while carrying forward results from other categories like SAST, avoiding a full re-scan. For example, changing an SCA-related setting or enabling an inventory module on an unchanged commit triggers a fresh dependency analysis and inventory pass but preserves prior code findings, rather than re-running the entire scan pipeline. Similarly, changing the model tier or toggling high-performance mode is applied lazily — the new setting takes effect on each repository’s next natural scan (code change or scheduled rescan) rather than forcing an immediate full re-scan across all repositories. Prior findings are carried forward in the meantime, so no findings are lost during the transition.
  • 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.
  • Automatic PR scan cancellation: When you push a new commit to a pull request or merge request, ZeroPath automatically cancels any in-progress PR scans for older commits on that same PR. This prevents wasted work on outdated code and ensures only the latest commit is scanned. This applies across all supported version control platforms (GitHub, GitHub Enterprise Server, GitLab, Bitbucket, and Azure DevOps Services).
  • Responsive full scan cancellation: When you cancel a full scan, the cancellation takes effect during long-running phases such as repository model building and call graph construction, not only between phases. This means cancellation requests are honored within seconds rather than waiting for an entire phase to complete.
  • 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.
  • SCA warning consistency across scan types: SCA-related warnings — including missing lockfile notifications, dependency resolution failures, unresolved transitive dependencies, and zero-results anomalies — are surfaced after both full scans and standalone SCA scans. Full scans additionally detect zero-results anomalies, where a manifest file was discovered but dependency resolution produced no results, which may indicate a misconfigured or empty dependency file. Any SCA warnings detected during a scan are reconciled and visible in the dashboard immediately, and warnings that no longer apply are automatically cleared on the next successful scan.
  • Finding preservation on resolution failure: When dependency resolution fails for a manifest file during a scan, ZeroPath carries forward existing SCA findings from that manifest instead of marking them as resolved. This prevents confirmed or open dependency vulnerabilities from being incorrectly auto-resolved due to a transient resolution error. The same protection applies when a scan path does not execute the dependency analysis pipeline — SCA findings are only resolved when the SCA analyzer actively confirms they are no longer present. Similarly, when a SAST deep investigation is skipped for a file (for example, during an abbreviated or lightweight scan), existing SAST findings on that file are carried forward rather than auto-resolved. Files whose analysis could not complete during any scan mode — including abbreviated and lightweight scans — are tracked and protected from auto-resolution, even when the full investigation pipeline did not run. Findings are only resolved when the investigation pipeline actively confirms they are no longer present, so scan modes that skip deep analysis cannot silently drop real vulnerabilities. Confirmed true-positive findings that are carried forward also have any stale auto-resolution state cleared, ensuring they appear with the correct status on the dashboard rather than being incorrectly shown as resolved.
  • 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. Large code ranges are also capped at a total character limit, so requesting a wide line range from a dense file does not blow out the analysis budget. 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.

​
Patch Variants

When regenerating a patch using the Adjust Patch workflow, you can request multiple alternative fix approaches at once. ZeroPath generates up to three distinct patch variants — each using a different strategy to resolve the vulnerability — and presents them as candidates for you to review. You select the variant you want to promote, which creates the patch and discards the alternatives. This is useful when the initial patch does not fit your codebase’s patterns or when you want to compare trade-offs between approaches before committing to one. You can also provide free-form feedback (up to 4,000 characters) when requesting regeneration to guide the patch agent toward a specific approach. SCA fixes (version bumps in dependency manifests) always produce a single patch regardless of how many variants are requested, since the correct version is deterministic.

​
Remediation Guidance

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. For container image findings, ZeroPath can generate fix patches by editing the repository’s Dockerfile. When a vulnerable package originates from the base image, the patch bumps the FROM tag to a newer stable release of the same distribution that ships the fixed package. When the package was installed by an application build step (a RUN instruction), the patch upgrades or pins the package version in that step. If no Dockerfile can be located or no safe edit is possible, remediation instructions are provided instead.

​
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 the actual 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). Error messages from all scan stages — including SAST and SCA sub-scans — are surfaced directly, giving you full visibility into what failed without needing to contact support.

​
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. Transient database errors during result persistence are automatically retried with exponential backoff before surfacing a failure, further reducing the chance of scan errors caused by brief connectivity issues. This recovery works reliably even for large repositories with thousands of findings. If a scan worker becomes unavailable (for example, due to scaling or a transient failure), any scans that were assigned to it are automatically reassigned to a healthy worker. This reassignment runs continuously, so scans do not remain stuck waiting for a worker that is no longer available. Active scans that cannot be safely reassigned are marked as errored so they can be retried. Full scans that are interrupted by worker restarts can automatically recover up to three times, replaying the scan pipeline from the beginning on each attempt. If a full scan exhausts its recovery budget, it is marked as errored so you can re-trigger it manually. Additionally, if the scanning pool is scaled down and a full scan was assigned to a worker that no longer exists, the platform automatically detects the stranded scan after a grace period and marks it as errored with a clear message, rather than leaving it stuck indefinitely. Stale full scans that remain unfinished beyond the configured threshold are also automatically cleaned up, consistent with existing PR scan behavior.

​
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. Findings with pending auto-generated patches correctly reflect a Patching status rather than being downgraded to Informational, and carry-forward scans recompute issue statuses from the final finding state to prevent stale status values from persisting across scans. 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.

​
Triage Feedback Tab

Each repository includes a Feedback tab that surfaces every human triage rationale recorded against the repository’s findings. This gives you a centralized view of all triage decisions — not just false positives, but every disposition including non-exploitable, true positive, accepted risk, severity changes, and more. You can filter the feedback list by disposition type using the filter chips at the top of the tab. By default, all disposition types are shown, and you can narrow the view by toggling individual filters. Each feedback entry displays the disposition, the rationale provided by the triager, the associated finding, and when it was recorded. You can click through to the linked finding for full details. You can also edit any feedback entry inline to re-word the rationale or change the disposition. Saving an edit records a new audit-safe triage entry, preserving the full history of triage decisions. A rationale is required when saving edits.

​
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.
  • Findings outside a partition’s directory scope are filtered out before AI validation, so out-of-scope findings do not consume validation budget. Cross-partition data flows are preserved when the entry point of the flow originates within the partition’s scope.
When deleting a monorepo configuration, you can choose to keep one partition as a normal repository or delete all partitions at once. If only one partition remains, the platform offers to convert it back to a normal repository automatically. Monorepo deletion is performed as a single atomic operation, so partial failures (such as a network interruption mid-deletion) cannot leave your repository in an inconsistent state.

​
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

  1. Navigate to Scanner in the ZeroPath dashboard.
  2. Select the Organization, Tag, or Repository level.
  3. Modify settings as needed.
  4. 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: