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 |
| Codex-enhanced differential scanning | Off | When enabled, uses an advanced AI model for differential scanning and final validation of findings, improving accuracy for incremental scans |
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 comment | On | Post a summary comment on the PR |
| 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. |
| 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 |
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, enter a cron expression (e.g.,
0 2 * * 1 for every Monday at 2 AM).
- Optionally specify a target branch (defaults to the repository’s default branch).
The scheduler only creates new work when the branch’s head commit has changed since the last scan, avoiding redundant processing.
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.
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.
- 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. Note that differential rescans do not re-run dependency analysis — new CVEs disclosed between full scans are caught by 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.
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.
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 cleans up any partial results from the previous attempt before resuming. This ensures you do not see duplicate findings after a scan retry.
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.
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.
Path Whitelist / Blacklist
Use glob patterns to focus or exclude specific paths from scanning:
- Whitelist patterns — only scan files matching these patterns.
- Blacklist patterns — exclude files matching these patterns.
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.
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"}'
