> ## 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. # SAST Overview > Find business logic vulnerabilities like broken auth, IDOR and more with fewer false positives. ## How It Works ZeroPath's Static Application Security Testing (SAST) uses a multi-stage AI-powered analysis pipeline to discover vulnerabilities that traditional pattern-matching scanners miss: Runs on push, PR, or schedule. Builds an architecture model, analyzes code, and validates every finding with AI. Identifies services and modules in your repo (e.g., `/apps/payments`) so findings are tied to the right team. Reviews every candidate for exploitability and context, reducing false positives by up to 75%. ## End-to-end Flow ZeroPath clones your repository and pins the exact commit, ensuring repeatable results. An AI-powered analyzer maps your codebase's services, modules, and entry points so each finding can be attributed to the right application and team. If you have defined [custom source or sink declarations](/docs/platform/scanner-settings#custom-sources--sinks), ZeroPath prepares optimized summaries for each declaration at scan start so they can be evaluated efficiently alongside built-in detections throughout the scan. Broad static analysis rules run across all supported languages, producing an initial set of candidate findings. Source-to-sink analysis identifies external data entry points (sources) and sensitive operations (sinks) in your code — including any [custom sources and sinks](/docs/platform/scanner-settings#custom-sources--sinks) you have declared. Custom declarations are evaluated in the same pre-screen and deep inspection passes as built-in detections, so custom-declared patterns receive the same analysis depth as standard vulnerability classes. In addition to the source-to-sink axis, ZeroPath runs two complementary candidate-generation axes on every full scan to catch vulnerability classes that the taint-flow model structurally misses: * **Convention-deviation detection**: ZeroPath maps every data-access and authorization operation in your codebase and groups comparable operations by resource. When the majority of comparable operations apply a security control — such as scoping a database read to the authenticated tenant, or enforcing a field allowlist on writes — but a small subset do not, those outliers are flagged as candidates. This catches missing controls (e.g., a database query that forgot the tenant filter) where there is nothing dangerous to point at, only a control that is present everywhere else. The AI agent reasons over the actual function source and the helper/guard functions each operation calls, so it can see scoping enforced through a helper call that a surface-level analysis would miss. * **Authorization-predicate analysis**: For each resource-access site, ZeroPath reasons directly about whether object-level authorization is broken — checking whether the scope value (such as `tenantId` or `ownerId`) filtering the query is derived from the authenticated caller's session rather than from attacker-controllable request input. This deductive check requires no conforming peer operations, so it catches broken access control on singleton endpoints and novel resources that the convention-deviation approach cannot reach. Both axes route their candidates through the same investigation, validation, and consolidation pipeline as all other findings, and their output is always additive — existing findings from source-to-sink analysis are never affected. ZeroPath also runs a **region-exhaustive triage** pass on every full scan: a lightweight classifier reads the source of every production function in the repository and flags any that plausibly contain an exploitable vulnerability, regardless of vulnerability class or access-surface membership. This class-agnostic pass covers memory safety, value-integrity, and other classes that the source-nomination model cannot reach, and escalates flagged functions through the same deep-investigation backend. Each candidate is reviewed in context. The AI evaluates exploitability, code flow, and surrounding logic to filter out false positives, reducing noise by up to 75%. File paths referenced in findings are validated against the actual repository contents, preventing hallucinated or incorrect paths from reaching your results. Before AI validation, deterministic false-positive filters remove findings that are known to be noise — for example, bidirectional Unicode markers in non-source-code files (such as JSON locales or markdown documents) are automatically excluded, since these are data files where such markers do not represent a security risk. Additionally, broad low-confidence rules that produce a large number of hits are automatically capped per rule before AI validation, preventing noisy rules from consuming validation budget and reducing overall scan time. Before full validation, every non-SCA candidate undergoes a lightweight severity pre-screen. Candidates below the severity threshold are filtered out early, reducing scan time and focusing the deeper validation pass on findings that are most likely to matter. Candidates above a high-severity threshold are always escalated to the full deep-agent investigation regardless of the pre-screen verdict — so a high-severity finding is never terminally dropped by the cheap pre-screen alone. When a validation batch partially fails — for example, because the model stopped producing output before answering every finding in the batch — ZeroPath recovers the verdicts that were fully emitted rather than discarding the entire batch. Findings whose verdicts could not be recovered are carried forward from previous scans rather than being auto-resolved, so no coverage is lost. When the number of candidates reaching the validation stage exceeds the internal validation budget, ZeroPath prioritizes the most severe candidates first. Higher-severity findings are validated before lower-severity ones, so the most impactful potential vulnerabilities always receive full analysis. Candidates that exceed the budget are withheld from the active findings queue rather than being shown as confirmed true positives, ensuring that only findings backed by a real validation verdict appear in your results. Each additive discovery axis (convention-deviation, authorization-predicate, and region-exhaustive) operates under its own separate validation budget, so findings from these axes cannot displace findings from the primary source-to-sink analysis. Each axis's candidates are fully validated through the same pipeline; the budget isolation simply ensures that a large additive tranche does not crowd out the base findings that ranked just below the global cap. To prevent a dense cluster of candidates in one area of the codebase from consuming the entire investigation budget and starving other files, ZeroPath guarantees each candidate-bearing region (file and enclosing function) at least one investigation slot before filling the remaining budget by severity rank. Candidates that overflow the primary budget are deferred to a bounded second pass rather than dropped, so real vulnerabilities in less-dense regions still receive a full investigation verdict. Secrets, IaC, and CI/CD findings use dedicated validation pipelines tailored to their finding type rather than the generic SAST reachability validator. Secrets are validated using a secret-specific process that includes live credential verification when possible, IaC findings are validated against deployment context (whether the resource is actually deployed), and CI/CD findings are validated against workflow trigger context (whether the workflow's trigger exposes the weakness). Each finding type uses the same validation agent regardless of which scan path triggered it (full scan, PR scan, or standalone), so a given misconfiguration or leaked credential receives the same verdict whichever way the scan was triggered. This ensures each finding type is evaluated with the right question — for example, "is this credential active?" rather than "is this exploitable from external input?" — improving accuracy across all scanning modules. A secondary validation pass then reviews all remaining true-positive findings before they are recorded. This pass can remove duplicate findings that share the same root cause at overlapping locations, mark non-exploitable findings (dead code, test fixtures, sanitized inputs), and correct inaccurate details such as title, description, or severity — further improving signal quality and reducing noise. The deduplication logic is conservative by design: a finding is only dropped when it is identified as a genuine restatement of another finding in the same file, so distinct co-located vulnerabilities are always preserved even when they touch the same code. A context-aware AI agent performs deeper analysis, examining authentication flows, authorization logic, business rules, and custom security policies. The agent can follow extended call chains and cross-file data flows, providing thorough coverage of complex vulnerability patterns. If the deep analysis agent or the validation stage encounters repeated internal errors during a scan, ZeroPath automatically stops launching new analyses for the affected files to preserve scan stability. Pre-screen results from earlier stages are retained for any skipped investigations, so you still receive findings at the pre-screen confidence level rather than losing coverage entirely. Findings in files whose analysis was skipped — whether during deep investigation or validation — are carried forward from previous scans rather than being auto-resolved, preventing confirmed vulnerabilities from being falsely marked as fixed when the scanner simply could not re-examine them. When an agent investigation reaches its analysis depth limit without converging on a verdict, ZeroPath now salvages a final structured result from the evidence already gathered rather than discarding the entire investigation. The salvage pass makes a single non-recursive call to produce a verdict from the accumulated transcript, so you receive a result for the vast majority of investigations that previously would have been dropped. Files where an investigation was incomplete are flagged with an **Investigation incomplete** warning so you can see exactly which files were affected; existing findings in those files are kept and will be re-checked on the next successful scan. Any natural-language rules you've defined are evaluated per-application, catching organization-specific security policies. The rule evaluation agent is given a full analysis budget so that large repositories with extensive codebases are not silently skipped — on previous versions, a rule could be dropped with zero findings if the agent exhausted its analysis depth before completing its investigation. If you delete a custom rule while a scan is in progress, any findings tied to that rule are preserved — the link back to the deleted rule is cleared, but the findings themselves are kept and the scan completes normally rather than failing. This means deleting a rule mid-scan does not silently discard real vulnerabilities that were already found. Findings are deduplicated across tools and historical scans. When a single file contains a large number of candidate findings — for example, from extensive custom rule sets — the consolidation step automatically splits them into manageable batches and runs a final cross-batch pass to catch duplicates across batches, ensuring reliable deduplication regardless of finding volume. When multiple discovery models run in parallel, findings that reference the same file, vulnerability category, and overlapping line range with similar titles are automatically collapsed into a single canonical finding. The most detailed description is preserved, and supplementary descriptions from other models are appended for reference. Secrets, IaC, CI/CD, EOL, and already-disconfirmed false-positive findings bypass SAST consolidation because each represents a distinct issue or has already been conclusively evaluated — for example, two IaC misconfigurations in the same file (such as a public storage bucket and missing encryption) are independent problems, not duplicates. All other findings — including those produced by the codebase agent, source-to-sink analysis, and pattern-match validation — are consolidated together so that the same vulnerability reported by multiple detection pipelines collapses into a single finding rather than appearing multiple times. Cross-source deduplication (where the same vulnerability is flagged by multiple scanning engines) now processes findings in file-boundary chunks. Each chunk is evaluated independently, so a transient failure in one chunk does not discard deduplication results from the rest of the scan — the affected chunk's findings are kept as-is while successfully deduplicated chunks proceed normally. Each confirmed finding receives a CVSS 4.0 severity score with AI-generated reasoning, step-by-step attack exploitation steps, a set of exploitability **preconditions** describing deployment-context factors the scanner could not fully verify, an **exploitation setup** describing what configuration or modification a running application would need before the finding can actually be exploited, and a **security impact** label summarizing the real-world attacker outcome (for example, "Account Takeover" or "Remote Code Execution"). The exploitation setup and preconditions together give you a complete picture of real-world exploitability: preconditions capture uncertain deployment factors while exploitation setup describes the concrete setup required. Severity scoring accounts for exploitation setup — a finding that requires extensive non-default configuration to exploit is scored lower than one reachable under the application's default configuration. The impact label is displayed prominently in the issue detail header alongside the vulnerability class, so you can assess real-world risk at a glance. For full scans, deduplication is scoped per-branch so each branch maintains independent findings — resolving an issue on one branch does not affect the same issue on another branch. For PR scans, deduplication is scoped to prevent cross-branch contamination — findings from one pull request are only deduplicated against full scan baselines and rescans of the same PR, not against findings from other pull requests. This ensures that each PR's results accurately reflect the code changes in that branch. When an existing finding is re-detected in a subsequent scan, ZeroPath automatically refreshes the contributor attribution and code location data to reflect the current state of the code, keeping blame information accurate as your codebase evolves. When a newly detected finding matches multiple historical issues (for example, near-identical findings at similar locations in the same file), ZeroPath now links the detection to every matched issue, not just the primary match. This prevents unlinked issues from being falsely auto-resolved as "no longer detected" when the underlying vulnerability is still present. Historical correlation — the process that matches newly detected findings against previously known issues — is resilient to transient errors: if one correlation batch fails, the remaining batches still complete and the scan proceeds normally. SCA findings are now correlated across scans based on package name, advisory identifier, and location, without depending on internal exploitation-path identifiers that can change between scans. This means that an existing SCA finding is reliably matched to its previous record on rescan rather than appearing as a new issue. Findings with an unknown validation state (where exploitability cannot be determined) are categorized as **Informational** rather than non-exploitable, giving you clearer signal about which findings need further investigation. This applies regardless of whether validation returned an inconclusive result or could not run at all — in both cases the finding has not been examined to the point of a confident verdict, so it is withheld from the default issue queue to avoid surfacing unverified findings alongside validated ones. If you have manually moved a finding to **Reviewing** or **Backlog** before a subsequent scan sets its validation state to unknown, the manual workflow status is preserved — the finding stays in your triage queue rather than being silently pulled out. Validated findings are written atomically and surfaced in your dashboard, API, and integrations. A final deduplication pass runs just before findings are persisted, catching any remaining duplicates that were accumulated across processing stages. This ensures that only unique findings are recorded, even when multiple detection paths produce overlapping results. Each full scan also records a **scan coverage** summary: the fraction of candidate-bearing regions (distinct file and enclosing function pairs) that received a full investigation verdict during the scan. Regions that overflowed the investigation budget are noted as deferred or capped rather than silently absent, giving you a transparent picture of how much of the codebase was deeply analyzed in each scan. ## Running Scans Comprehensive analysis of your entire codebase. Triggered manually, on schedule, or when code is pushed to monitored branches. You can scan all repositories at once using the **Select All** option in the Start Scan modal or via the API. When scanning all repositories, only VCS-attached repositories are included — uploaded repositories without a remote are excluded. You can also exclude specific repositories from a "scan all" request if needed. You can also start scans in bulk from the **Repositories** page by selecting multiple repositories and choosing **Start Scan** from the bulk actions menu. When scanning multiple repositories, individual repositories that cannot be scanned — because they are already scanning, have no configured branch, or are empty — are automatically skipped rather than blocking the entire batch. The remaining eligible repositories proceed normally. If every selected repository is ineligible, you receive a message explaining why no scans were started. For organizations on credit-based billing, a confirmation dialog shows the quoted credit cost for each repository before the scans begin, so you can review the total cost and confirm before any credits are deducted. If your account has insufficient credits, you are prompted to purchase more before proceeding. When a repository's usage estimate is still being computed at quote time, the scan is admitted immediately and billed at the pricing policy's minimum charge rather than being blocked — the estimated token count in the quote response will be absent in this case, and the final charge reflects the minimum. A fresh estimate runs in the background and prices subsequent scans accurately. On subsequent scans of the same branch, ZeroPath intelligently reuses results for unchanged files and focuses deep analysis only on changed files, significantly reducing scan time. Large vendored, generated, and fixture/test-data files are automatically identified and excluded from deep analysis — for example, files under `vendor/`, `node_modules/`, or `generated/` directories, files with generated-code suffixes (such as `.pb.go` or `_pb2.py`), and files whose headers contain `@generated` or `auto-generated` markers. This keeps scan time focused on your own code rather than third-party or machine-produced sources. When the changes since the last scan are small or moderate, ZeroPath can use a smart rescan mode that evaluates only the diff. An AI agent reviews whether existing issues are still present and whether the new code introduces any vulnerabilities, delivering results significantly faster than a full pipeline run. The rescan agent inspects issues on a per-file basis and resolves them by exact line range and behavior, so if one vulnerability in a file is fixed while another remains, only the fixed issue is marked as resolved. When the rescan agent determines that a finding is fixed, that verdict is persisted immediately — including for findings you have confirmed as true positives — so confirmed findings are reliably resolved rather than remaining open when the agent has already affirmed the fix. For larger diffs that exceed the single-pass threshold but are still within the differential rescan range, ZeroPath automatically splits the changed files into chunks and reviews them in parallel. Each chunk is analyzed independently by its own AI agent pass, and results are reconciled into a single set of findings after all chunks complete. This means more rescans stay on the fast differential path instead of falling back to a full pipeline, significantly reducing scan time for medium-to-large changesets. If you have configured [custom rules](/docs/platform/custom-rules), [custom sources](/docs/platform/scanner-settings#custom-sources--sinks), or [custom sinks](/docs/platform/scanner-settings#custom-sources--sinks), the differential rescan agent now applies them alongside its general security analysis. Natural-language rules are matched against their configured file globs, and custom taint sources and sinks are used during data-flow tracing through changed code — so incremental scans enforce the same organization-specific policies as full scans. The differential scan engine automatically classifies changed files to determine the most efficient scan strategy. When only code files change, ZeroPath runs the fast rescan path alone. When only dependency manifests or lockfiles change, a lightweight SCA pass runs while SAST findings are carried forward. When both code and dependency files change, ZeroPath runs the rescan and SCA together — without triggering a full pipeline. Non-code files such as lockfiles, source maps, images, and generated assets are excluded from the diff size calculation, so large dependency updates no longer force unnecessary full scans. When your scanner settings change between scans but the code itself is unchanged, ZeroPath evaluates which setting categories were affected. If only rollover-safe settings changed — such as dependency analysis configuration or model tier/performance mode — ZeroPath refreshes the affected category while carrying forward existing findings from other categories, avoiding an unnecessary full pipeline run. Model tier and high-performance mode changes are applied lazily: the new setting takes effect on each repository's next natural scan rather than forcing an immediate full re-scan, and prior findings are preserved in the meantime. When the only settings change is enabling or disabling scanning modules that do not affect rolled-forward findings — such as AI Inventory or SCA — ZeroPath also uses the fast rollover path instead of a full pipeline. SCA findings are recomputed fresh on every scan, and AI Inventory produces component data rather than security findings, so adding or removing these modules does not change the set of SAST, secrets, IaC, or EOL findings that are carried forward. This means fleet-wide module rollouts (for example, enabling AI Inventory across all repositories) no longer force a full re-scan of every unchanged repository. Enabling or disabling finding-producing modules (such as Secrets, IaC, EOL, or Container scanning) still triggers a full rescan to ensure complete coverage, as does any change to custom rules, sources/sinks, or SAST configuration. In monorepo setups, the rescan agent is scoped to the current repository partition. Only files and findings within the configured scan scope are evaluated, preventing cross-partition interference when multiple teams share a single repository. ZeroPath uses a three-tier regression detection pipeline to efficiently determine whether previously reported issues are still present after code changes: 1. **Deterministic fast-path** — if none of the files relevant to a finding changed between commits, the finding is carried forward instantly with no AI call. 2. **Structured diff review** — when relevant files did change, a single AI review examines the bounded diff and code evidence to decide whether the issue persists or was fixed. 3. **Deep-agent escalation** — only when the bounded evidence is insufficient does ZeroPath escalate to a full agentic investigation, keeping costs and latency low for the common case. Incremental, diff-focused scans that analyze only changed code in pull requests. Results appear as inline comments and check statuses directly in your VCS. When a PR scan determines that a previously reported issue has been remediated in the current pull request, ZeroPath automatically marks the original finding as resolved and records the reason, keeping your issue list up to date without manual triage. Findings that you have confirmed as true positives through investigation are never auto-resolved by PR scans. If a confirmed true-positive finding is not re-detected during a PR scan refresh, it is carried forward from the previous scan rather than being marked as resolved. If a finding that was previously resolved is detected again in a PR scan refresh, ZeroPath automatically re-opens it. Re-detection is treated as evidence that the vulnerability is still present — consistent with how full scans handle re-detected issues. Findings resolved because they were confirmed to pre-exist on the base branch are excluded from this re-open logic. When a PR is updated after a previous scan was skipped (for example, because the earlier changes were not security-relevant), ZeroPath correctly excludes the skipped scan from the refresh baseline, ensuring the incremental comparison covers the full set of PR changes. **Fix Verification:** You can reference existing ZeroPath issues in your PR description to verify whether the PR resolves them. Add references using one of these formats: * `ZP-ID: ` — reference a single issue * `ZP-ID: , , ` — reference multiple issues on one line * Paste a ZeroPath dashboard URL containing the issue (e.g., from the issue detail page) Multiple `ZP-ID:` lines are supported, and you can mix formats in the same PR description. When the PR scan completes, ZeroPath checks whether each referenced issue was still detected. If a referenced issue is no longer detected, the PR is confirmed to fix it. Results appear in a **Referenced Vulnerabilities** table in the PR comment, showing the status of each referenced issue. After the PR is merged, verified fixes are automatically marked as resolved. No additional configuration is required — fix verification runs automatically whenever issue references are detected in a PR description. See [PR Scanning](/docs/scanning/pr-scanning) for details. ## Vulnerability Categories | Category | Examples | | -------------------------------------- | ------------------------------------------------------------------------------------------------------ | | **Injection** | SQL injection, command injection, LDAP injection | | **Cross-Site Scripting (XSS)** | Reflected XSS, stored XSS, DOM-based XSS | | **Server-Side Request Forgery (SSRF)** | Internal service access, cloud metadata exfiltration | | **File Operations** | Path traversal, local file inclusion, arbitrary file read/write | | **Insecure Deserialization** | Object injection, remote code execution via deserialization | | **XML External Entity (XXE)** | External entity expansion, SSRF via XML | | **Template Injection** | Server-side template injection (SSTI) | | **Cryptography** | Weak algorithms, hardcoded keys, insufficient key length | | **Open Redirect** | Unvalidated redirect targets | | **CORS Misconfiguration** | Overly permissive cross-origin policies | | **CSRF** | Missing or bypassable cross-site request forgery protections | | **LLM Security** | Prompt injection, insecure output handling, system prompt leakage, excessive agency (OWASP LLM Top 10) | | **Denial of Service** | ReDoS, resource exhaustion, algorithmic complexity | | **Information Disclosure** | Sensitive data in responses, error message leakage | | **Reflection** | Reflected input flaws, unsafe reflection | | **Memory Safety** | Buffer overflows, use-after-free, out-of-bounds access | | **Input Validation** | Missing or improper input validation | | **Configuration** | Insecure defaults, debug mode in production | | Category | Examples | | -------------------------- | --------------------------------------------------------- | | **Authentication** | Missing auth checks, broken authentication flows | | **Authorization** | Broken access control, privilege escalation, IDOR | | **Session Handling** | Session fixation, weak session tokens, hijacking | | **Logic Flaws** | Race conditions, workflow bypass, state manipulation | | **Parameter Tampering** | Client-side price manipulation, hidden field modification | | **Data Validation** | Semantic validation failures, type confusion | | **Information Disclosure** | Logic-layer data leakage, excessive data exposure | ## Severity Scoring ZeroPath uses **CVSS 4.0** as its primary scoring standard, and also provides **CVSS 3.1** scores for compatibility with tools and workflows that require the older standard. Every confirmed finding receives a structured score with AI-generated reasoning tied directly to the code. Findings are also assigned one or more **CWE identifiers** for precise weakness classification. CVSS assessments are generated for nearly all security findings — only non-security issues like code quality or style problems are excluded. When a cloud security integration (such as Wiz) is connected, ZeroPath incorporates observed runtime deployment state into severity scoring. The scanning engine can see whether workloads built from the repository are currently running, whether they can access sensitive data, and whether they are reachable from the public internet. This evidence may raise severity when it shows real-world impact the code alone does not reveal — for example, a vulnerability in code that is confirmed to be running and accessible from the internet — or lower severity when no workload from the repository is currently deployed. Runtime evidence affects severity scoring only; it does not change whether a finding is considered a true positive. **LLM Security findings** (OWASP LLM Top 10) are scored conservatively: most receive a severity of 2.0–5.0 unless the LLM output flows directly into a dangerous sink (such as `eval`, SQL, or a shell command) with no validation, in which case the downstream sink impact is scored. System prompt leakage and excessive agency findings are typically scored 1.0–3.0. | Metric | Values | What It Captures | | ---------------------- | ----------------------- | ------------------------------------------------------------- | | Attack Vector | Network / Local | Whether exploitable remotely or requires local access | | Attack Complexity | Low / High | Reliability of exploit; whether special conditions are needed | | Attack Requirements | None / Present | Whether prerequisites (specific config/state) are required | | Privileges Required | None / Low / High | Privilege level the attacker needs | | User Interaction | None / Passive / Active | Whether a user must take action for exploitation | | Confidentiality Impact | None / Low / High | Impact on data secrecy | | Integrity Impact | None / Low / High | Impact on data or system integrity | | Availability Impact | None / Low / High | Impact on system availability | Each metric includes a written rationale tied to the specific code snippet and vulnerability context. In addition to CVSS 4.0, each finding also receives a **CVSS 3.1** score derived from the same analysis. The 3.1 vector includes the **Scope** metric (Unchanged or Changed), which indicates whether an exploit can affect resources beyond the vulnerable component. This dual-scoring approach lets you use CVSS 4.0 for modern risk assessment while retaining CVSS 3.1 compatibility for existing dashboards, compliance frameworks, and integrations that have not yet adopted 4.0. Older findings that were originally scored with CVSS 4.0 only are automatically backfilled with derived CVSS 3.1 vectors and severity scores, so you can filter and sort all findings by CVSS 3.1 without gaps in coverage. The overall **finding priority score** combines severity with confidence: `severity (0–10) × confidence (0–10)` = a **0–100 scale** for ranking and filtering. This means a high-severity finding with low confidence ranks lower than a medium-severity finding with high confidence — helping you focus on issues that are both impactful and reliably identified. For findings where validation could not run (shown as **Informational**), confidence is unset because no true-positive assessment was produced. These findings receive a priority score based on severity alone, on a 0-10 scale rather than the 0-100 scale of validated findings, so they always rank below findings that received a full validation verdict. This ensures that confirmed true positives are never pushed down by findings that no agent has examined. You can manually override a finding's severity in two ways: * **By raw score** — set the 0–10 severity directly. The ZeroPath priority score is recomputed automatically. * **By rating** — set the target rating label (Critical, High, Medium, Low, or Informational) and the platform derives the 0–10 severity that places the finding in that band, accounting for its confidence. This is useful when you want to downgrade a finding to a specific rating without calculating the numeric score yourself. Both methods update the finding's stored severity, ZeroPath priority score, and CVSS base score in lockstep, and record the change in the audit log. Low-confidence findings can be rated down but not up: if a finding's confidence is too low to reach the target band's score threshold, the platform rejects the request rather than silently clamping to a different rating. ## Language Coverage Each finding is tagged with the detected language of the affected file, enabling language-aware filtering and remediation guidance. Language detection covers common file extensions as well as less obvious ones — for example, C scanning includes `.inc` header files and Ruby scanning includes `.erb` templates — so findings in these files are correctly attributed and analyzed. ## Key Capabilities AI validation reviews every finding in context, filtering out issues that aren't actually exploitable. Deep AI analysis discovers vulnerabilities that pattern-matching alone cannot find, including business logic flaws. Each finding is tied to the specific service or module it affects, with tech stack and architecture context. You can filter the issues list by application using a dedicated **Application** filter in the toolbar, scoped to the repositories you have selected. This makes it easy to focus on findings from a specific service or module in a monorepo. Source-to-sink traces show exactly how tainted data reaches vulnerable operations. Every exploitable finding includes a mandatory data flow path. When a finding involves a [custom source](/docs/platform/scanner-settings#custom-sources--sinks) or [custom sink](/docs/platform/scanner-settings#custom-sources--sinks) declaration, the data flow details include the custom declaration name and description, so you can see exactly which custom-defined entry point or sensitive operation was matched. Source and sink previews display a **Custom Source** or **Custom Sink** badge when the finding originated from a custom declaration, and you can click through directly to view or edit the declaration from the issue detail pane. For SCA vulnerabilities, the data flow tree includes the manifest file where the affected dependency is declared, giving you direct visibility into which dependency file introduces the risk. The scan explorer includes repository and scan navigation dropdowns so you can quickly switch between repositories and compare results across recent scans without leaving the page. Findings that are linked to an application but not to a specific source handler appear under a **Standalone Findings** node in the scan explorer tree, so they are always visible and never lost. Each finding includes a step-by-step description of how an attacker would exploit the vulnerability, from prerequisites through impact — helping AppSec engineers quickly assess risk. An expandable Exploit Walkthrough shows the ordered sequence of actions an attacker would take. If exploit walkthrough generation encounters a transient error, the finding is still preserved without the walkthrough rather than being dropped — so you never lose a real vulnerability because a presentation-layer step failed. These attack steps are also available as structured data in the issue detail API response, making them easy to consume in automated workflows and integrations. When exporting issues via the API, you can include attack steps in the export by setting the `includeExploitWalkthrough` SARIF option. Every finding includes a list of **preconditions** — factors that affect whether the vulnerability is actually exploitable but that the scanner cannot fully verify from code alone. Examples include whether the endpoint is internet-facing, whether a WAF or API gateway filters malicious input, and whether authentication is enforced by middleware not visible in the scanned code. You can expand each precondition to view the supporting scanner evidence from your codebase, helping you quickly assess real-world risk without re-investigating the finding yourself. Preconditions are also available as structured data in the issue detail API response, making them easy to consume in automated workflows and integrations. When exporting issues via the API, you can include preconditions in the export by setting the `includePreconditions` SARIF option. Every finding also includes an **exploitation setup** — a single plain-language description of what configuration or modification a running application would need before the finding can actually be exploited (for example, an authenticated session, an enabled feature flag, or a non-default deployment mode). When no special setup is required, the finding states that it is exploitable under the application's default configuration. Exploitation setup is factored into severity scoring: the more setup an exploit requires, the lower its real-world severity score. Same codebase at the same commit produces the same findings, enabling reliable audits and compliance tracking. Qualifying findings can be automatically patched with AI-generated code fixes. When a patch is being generated, a step-by-step progress tracker shows the current stage — Assigned, Preparing repository, Generating fix, and Finalizing — along with a live elapsed timer, so you can monitor progress in real time. Once a patch is ready for review, you can click **Adjust Patch** to provide free-form feedback or request multiple alternative variants. When multiple variants are generated, a **Choose a Patch** panel lists each option with its full diff and description so you can pick the one that best fits your codebase — the chosen patch still goes through the normal approval gate before a PR is created. SCA findings use deterministic version-bump patches and do not support the adjust/variant workflow. The patch panel accurately reflects the current state at all times: if a patch has already been generated or a generation request is actively in progress, the panel shows the patch or its progress rather than a "patch generation skipped" message — even for findings whose exploitability is not yet fully confirmed. Secrets scanning runs multiple detection engines in parallel, cross-referencing results to maximize coverage while deduplicating overlapping findings from different engines. After deduplication, all findings from both engines go through a single unified validation pass, ensuring consistent verdicts and efficient use of the validation budget regardless of which engine originally detected the secret. Each secret finding includes a validation state — **Confirmed** (verified active), **Disconfirmed** (verified inactive or false positive), or **Unknown** (validation could not run) — along with a reason when validation is inconclusive. Confirmed and unknown secrets include attack steps and exploitability preconditions, just like SAST findings, so you can assess the real-world impact of a leaked credential at a glance. **Secret values are masked everywhere, including the dashboard.** No surface — the issue view, the highlighted code sample, the AI-generated analysis, the API, exports, PR comments, or Jira/Linear tickets — reproduces a detected secret. What you see is the last four characters of the value, or, for RSA/SSH key material, the key's algorithm label with a short head and tail, so you can tell which credential a finding refers to. Finding titles for secret findings are also redacted so that AI-generated titles that may reference the secret value are never displayed in any context. When multiple secrets appear near each other in the same file (for example, grouped credentials or `.env` blocks), all secret values in the surrounding context are masked — not just the one the finding refers to. A developer who needs the value itself opens the file in the repository, via the permalink on the finding. Organizations can additionally hide the AI-written description and exploit walkthrough for secret findings under **Settings → General → Secret Masking** — those are generated from the source line and can quote the value in prose. Request a deeper re-investigation of any finding using larger AI models for higher-confidence validation results. You can trigger investigations from the issue detail view — including via the **Reinvestigate** action in the issue actions menu — and monitor progress in real time. Ask questions about any finding directly from the issue detail view. A dedicated chat panel scoped to the specific issue can explain how the vulnerability can be exploited, suggest fixes, and assess reachability — all without leaving the dashboard. You can also delete chat threads you no longer need. While the assistant is running, a **Stop** button appears so you can cancel the in-progress response at any time without waiting for it to finish. Add free-form notes to any finding directly from the issue detail view. Notes are shared with everyone in your organization and persist alongside the issue, making it easy to record triage decisions, workaround details, or context for your team. Notes can be up to 5,000 characters and can be updated or discarded at any time. The global issues list displays the scan target branch for each finding, making it easy to see which branch a vulnerability was detected on. Combined with per-branch deduplication, you can track and filter findings across branches without confusion. ## Investigation You can request on-demand investigation of any finding to get a deeper, higher-confidence assessment. When you trigger an investigation, ZeroPath re-evaluates the finding using more powerful AI models: * **SAST findings** are re-validated with a larger model that examines exploitability with more context and nuance. The investigation uses the same application context and threat model that a full scan would — including your configured application structure, per-application threat models, and runtime evidence from your cloud environment — so severity scoring and exploitability assessment reflect your actual deployment context rather than operating without it. Because investigations run against the current HEAD of the finding's branch, line numbers in the original finding may have shifted since it was first detected. ZeroPath anchors the investigation to the originally reported code snippet and instructs the AI to locate the vulnerable code by its content rather than by raw line offsets — so if that code is no longer present, the finding is treated as fixed rather than confirmed against unrelated code. * **SCA direct dependency findings** undergo reachability analysis to determine whether the vulnerable code path is actually reachable in your project. Results are labeled as "Likely Reachable" or "Likely Not Reachable" to reflect the probabilistic nature of the analysis, and include a detailed reachability summary explaining the reasoning. When an SCA assessment encounters repeated analysis errors, failures are counted per package rather than per attempt, so a single package with many advisories that exhausts the analysis depth limit does not prevent other packages from being investigated. * **SCA transitive dependency findings** go through a two-phase process: first a triage step determines whether exploitability can even be assessed, and if so, a full reachability analysis traces the dependency chain to see if the vulnerability is reachable through parent packages. Transitive dependency resolution is supported for Java (Maven, Gradle), Scala (sbt), Python (pip), .NET, and Rust (Cargo). SCA findings also display **exploit intelligence** when available: a **CISA KEV** (Known Exploited Vulnerabilities) badge indicates that the vulnerability is actively exploited in the wild, including the date it was added to the KEV catalog and whether it is associated with ransomware campaigns. An **EPSS** (Exploit Prediction Scoring System) score shows the probability that the vulnerability will be exploited, displayed as a percentage alongside its percentile ranking. These indicators appear in the vulnerability detail pane and help you prioritize findings based on real-world exploitation risk. SCA findings also display the manifest file path with a direct link to view the file in your repository. When a dependency is detected from a compiled binary rather than a manifest file, this is indicated in the package details. The issue detail header for SCA findings includes direct links to the relevant security advisory and associated CVE (GHSA advisories link to deps.dev, CVE advisories link to NVD), so you can quickly access upstream vulnerability information without leaving the platform. **Container findings** are produced by running two independent scanning engines against each container image and cross-referencing the results. Vulnerabilities reported by both engines receive higher confidence, while findings unique to one engine widen coverage — giving you the benefits of multi-engine detection without duplicate noise. Container findings display the scanned container image reference and the vulnerable package (name and installed version) instead of a repository name. Each container finding aggregates the CVEs affecting that package, shown as an expandable list where each CVE row displays its severity badge, CVE identifier, CVSS score, and fix availability at a glance. You can expand any CVE to view its full details including the advisory link, CVSS vector, published date, and a summary. When a fixed version is available, an upgrade recommendation banner shows which version to upgrade to and how many vulnerabilities the upgrade resolves. When no fixed version has been published, the platform clearly indicates that no fix is available yet and recommends tracking the upstream advisory. Container findings are patchable directly without requiring a prior verification step, since they are based on deterministic vulnerability data rather than AI-inferred exploitability. When exporting container findings to Jira or Linear, the scanned image reference is used as the source label instead of an internal repository name. If the source branch for a finding no longer exists — for example, because it was merged and deleted — the investigation fails with a specific, actionable message explaining the cause and recommending a re-scan to refresh the finding, rather than a generic error. These failures are treated as non-retryable so you are not prompted to retry an investigation that cannot succeed without first rescanning. Investigation results update the finding's validation state (confirmed, disconfirmed, or unknown) and include a detailed security assessment explaining the reasoning. You can request investigations via the API, MCP tools, or directly from the issue detail view in the dashboard using the **Reinvestigate** option in the actions menu. While an investigation is in progress, the issue detail view shows a live status indicator, and results appear automatically when the analysis completes. When an investigation completes, the issue detail view displays a prominent banner with a color-coded **verdict** — **Confirmed** (exploitable), **Not Exploitable**, or **Unknown** — alongside the full security assessment, making it easy to identify high-priority issues at a glance. Findings with an unknown validation state are labeled as **Informational**, indicating they have not yet been investigated to the point of a confident exploitability verdict. For findings that have been dynamically tested through Runtime Validation, the issue detail view shows a dedicated Runtime Validation panel with context-aware outcome descriptions. The outcome heading adapts to the verdict: **Confirmed** findings show "What Was Confirmed", **Disconfirmed** findings show "Why It Was Not Exploitable", and inconclusive results show "Why It Could Not Be Validated". When a validated attack path is available, it is shown as a numbered sequence of steps; the full set of agent actions and observations can be expanded separately. Evidence narrative, tested targets, and tested roles are grouped in a collapsible "Evidence and scope" section. When Runtime Validation has already exercised a finding, separate PoC generation is not available for that result — instead, the runtime validation PoC and any run instructions are displayed directly in the issue detail view. When runtime evidence is available for a finding's repository, the issue detail view includes a **Runtime Evidence** tab showing the observed cloud workload state sourced from your connected cloud security platform. The tab displays up to two snapshots: the **current runtime state** (what your cloud environment looks like now) and the **evidence at detection** (the runtime state observed by the scan that produced the finding's severity score). Each snapshot shows whether workloads built from the repository were found, along with a per-workload breakdown including running status, access to sensitive data, internet reachability, and image attribution (whether the container image is built exclusively from this repository or shared with others). When the workload search was cut short before completing, the tab clearly indicates that the displayed counts are lower bounds rather than definitive totals. A direct link to your cloud security platform is included for further investigation. You can also request investigations in bulk across multiple issues at once, which is useful for triaging a batch of findings. When a finding cannot be automatically patched, the platform displays remediation steps with specific guidance on how to address the vulnerability manually. If a finding was previously determined to be unpatchable, you can use the **Force Generate Patch** button in the patch panel to request another attempt. A confirmation dialog explains the reason the issue was marked unpatchable before proceeding, so you have full context before retrying. For findings where a patch has been generated but you would like a different approach, the **Adjust Patch** button lets you supply free-form feedback or request several alternative variants at once — you then review the candidates and select the one you want to take through the approval flow. ## Adoption Checklist Add your repo via GitHub App, GitHub Enterprise Server, GitLab, Bitbucket, Azure DevOps Services, or direct URL. See [Quick Start](/docs/quickstart). SAST is enabled by default in scanner settings for all repositories. Trigger a full scan from the dashboard or wait for the next scheduled scan. Browse findings in the dashboard, grouped by severity, application, and category. You can filter findings by type — including SAST, SCA, Secrets, IaC, CI/CD, EoL, and Container — to focus on what matters most to your team. The scan source dropdown lets you choose between **All** (every source combined), **Full Scans**, **PR Scans**, **SCA Scans**, and **Container Scans**, so you can quickly switch between scan sources without adjusting individual detection type filters. The detection type facet counts include individual SCA and Container badges, so you can see at a glance how many supply-chain and container findings exist. The **All** category badge counts only code-related findings (SAST, Secrets, IaC, CI/CD, EoL), since the All tab links to the code-only default list — SCA and Container totals are shown on their own badges. You can also filter by **runtime validation verdict** (Confirmed, Disconfirmed, Untestable, or Agent Error) to quickly surface findings based on their dynamic testing outcome. When a cloud security integration (such as Wiz) is connected, an **Exposed** toggle appears in the issues toolbar, letting you filter for findings in repositories with runtime-exposed workloads. In monorepo setups, you can also filter by application to narrow the issues list to a specific service or module within a repository. Each issue has a shareable URL, so you can link directly to a specific finding when collaborating with your team. When filtering by repository on the Issues page, you can use the **Select All** toggle to select all repositories at once without enumerating each one individually. After selecting all, you can exclude specific repositories from the results by toggling them off — the filter tracks your exclusions compactly so the page remains fast even for organizations with many repositories. You can also exclude repositories from the results via the API using the `excludedRepositoryBranches` parameter, which is useful for omitting noisy or irrelevant repositories from a broad query. Adjust confidence filtering and PR check failure thresholds to match your team's tolerance. Turn on PR scanning to catch vulnerabilities before they reach your main branch. Route findings to [Jira](/docs/integrations/jira), [Linear](/docs/integrations/linear), [Slack](/docs/integrations/slack), or [webhooks](/docs/webhook/introduction). You can export individual findings or bulk-export multiple findings at once to Jira or Linear directly from the issues list. An **Export** button is available in the issues toolbar. When issues are selected, the button shows the count of selected issues so you know exactly what will be exported. The export dialog lets you choose between **Regular CSV**, **CASA Relevant CSV**, and **SARIF** formats. Before exporting, you can use granular controls to override the severity, category, and status filters independently from your current view — for example, exporting only Critical and High severity issues across all statuses without changing the filters on your dashboard. A live preview shows the exact number of issues that will be included in your export. For SARIF exports, you can optionally include preconditions and exploit walkthrough context in the output. Add natural-language rules for organization-specific security policies. See [Custom Rules](/docs/platform/custom-rules).