> ## 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 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. 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 preserved with their pre-screen severity score when one is available, ensuring they still appear in your results at the pre-screen confidence level rather than being silently dropped. 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). 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. 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 encounters repeated internal errors during a scan, ZeroPath automatically stops launching new agent investigations 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. Any natural-language rules you've defined are evaluated per-application, catching organization-specific security policies. If you delete a custom rule while a scan is in progress, any findings tied to that rule are gracefully dropped before results are persisted — the scan completes normally rather than failing. 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, and EOL findings bypass SAST consolidation entirely because each represents a distinct issue — for example, two IaC misconfigurations in the same file (such as a public storage bucket and missing encryption) are independent problems, not duplicates. 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. 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. When validation could not run at all (for example, because the analysis depth limit was reached during the validation attempt), the finding is instead shown as **Pending Review** so you can distinguish between findings that were inconclusive and findings that were never fully evaluated. Findings that reach the **Pending Review** state still carry the severity score from the initial pre-screen, so they appear in ranked lists and can be triaged based on their known severity even without a reachability verdict. 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 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. 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](/platform/custom-rules), [custom sources](/platform/scanner-settings#custom-sources--sinks), or [custom sinks](/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. Settings changes that affect SAST discovery (such as custom rules, sources/sinks, or enabled modules) still trigger a full rescan to ensure complete coverage. 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. For findings where validation could not run (shown as **Pending Review**), confidence is not set because no true-positive assessment was produced. These findings still receive a priority score derived from severity alone so they appear in ranked lists and exports rather than being hidden. ## 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. 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](/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. 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. 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. 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. Code snippets for secrets findings are always returned in redacted form via the API and exports — the raw secret value is never included in snippet fields, replaced instead by a masked placeholder. 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. 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. * **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. 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 match a known advisory but have not yet been investigated for exploitability. If validation could not run at all during the investigation attempt, the finding is instead labeled **Pending Review**. 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. 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. ## Adoption Checklist Add your repo via GitHub App, GitLab, Bitbucket, Azure DevOps Services, 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. You can also filter by **runtime validation verdict** (Confirmed, Disconfirmed, Untestable, or Agent Error) to quickly surface findings based on their dynamic testing outcome. 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. 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).