Skip to main content

​
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:

Automated Scanning

Runs on push, PR, or schedule. Builds an architecture model, analyzes code, and validates every finding with AI.

Application-Aware

Identifies services and modules in your repo (e.g., /apps/payments) so findings are tied to the right team.

AI Validated

Reviews every candidate for exploitability and context, reducing false positives by up to 75%.

​
End-to-end Flow

1

Repository Checkout

ZeroPath clones your repository and pins the exact commit, ensuring repeatable results.
2

Application Discovery

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, ZeroPath prepares optimized summaries for each declaration at scan start so they can be evaluated efficiently alongside built-in detections throughout the scan.
3

Multi-Stage Pattern Analysis

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 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.
4

AI Validation & False-Positive Filtering

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 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.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). 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.
5

Deep Codebase Analysis

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.
6

Custom Rule Evaluation

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 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.
7

Deduplication & Scoring

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, 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. 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.
8

Results Delivered

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. 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, custom sources, or custom 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.

​
Vulnerability Categories

​
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.
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.
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

Python

JavaScript / TypeScript

Java

Go

Ruby

PHP

C / C++

C#

Rust

Swift / Objective-C

Kotlin

Scala

Dart

Elixir

Nim

AL (Business Central)

ObjectScript (InterSystems IRIS)

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

75% Fewer False Positives

AI validation reviews every finding in context, filtering out issues that aren’t actually exploitable.

Novel Vulnerability Detection

Deep AI analysis discovers vulnerabilities that pattern-matching alone cannot find, including business logic flaws.

Application-Aware Findings

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.

Data Flow Visualization

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 or custom sink 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.

Attack Step Breakdown

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.

Exploitability Preconditions & Setup

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.

Deterministic Results

Same codebase at the same commit produces the same findings, enabling reliable audits and compliance tracking.

Auto-Fix Capable

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.

Multi-Engine Secrets Detection

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.

On-Demand Investigation

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.

Issue Chat

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.

Issue Notes

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.

Branch-Aware Issue Tracking

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. 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 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. 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

1

Connect Your Repository

Add your repo via GitHub App, GitHub Enterprise Server, GitLab, Bitbucket, Azure DevOps Services, or direct URL. See Quick Start.
2

Confirm SAST Is Enabled

SAST is enabled by default in scanner settings for all repositories.
3

Run Your First Scan

Trigger a full scan from the dashboard or wait for the next scheduled scan.
4

Review Findings

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. 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.
5

Configure Thresholds

Adjust confidence filtering and PR check failure thresholds to match your team’s tolerance.
6

Enable PR Scanning

Turn on PR scanning to catch vulnerabilities before they reach your main branch.
7

Set Up Integrations

Route findings to Jira, Linear, Slack, or webhooks. 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.
8

Define Custom Rules

Add natural-language rules for organization-specific security policies. See Custom Rules.