> ## 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](/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](/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. 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 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. 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. 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. Any natural-language rules you've defined are evaluated per-application, catching organization-specific security policies. 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. 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, and a **security impact** label summarizing the real-world attacker outcome (for example, "Account Takeover" or "Remote Code Execution"). 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. 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. 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. ## Running Scans Comprehensive analysis of your entire codebase. Triggered manually, on schedule, or when code is pushed to monitored branches. 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. When the changes since the last scan are small, 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. 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. 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. 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](/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. **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. ## Language Coverage Each finding is tagged with the detected language of the affected file, enabling language-aware filtering and remediation guidance. ## 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. 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](/platform/custom-sources) or [custom sink](/platform/custom-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. 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. 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. Secrets scanning runs multiple detection engines in parallel, cross-referencing results to maximize coverage while deduplicating overlapping findings from different engines. 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. 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. 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. * **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. * **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 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. 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. Findings confirmed as exploitable display a prominent banner with 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 match a known advisory but have not yet been investigated for exploitability. 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. ## Adoption Checklist Add your repo via GitHub App, GitLab, Bitbucket, or direct URL. See [Quick Start](/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, and EoL — to focus on what matters most to your team. 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](/integrations/jira), [Linear](/integrations/linear), [Slack](/integrations/slack), or [webhooks](/webhook/introduction). You can export individual findings or bulk-export multiple findings at once to Jira or Linear directly from the issues list. 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](/platform/custom-rules).