ZeroPath Review – An Honest Look at AI-Powered SAST

If you’re serious about securing your applications, you’ve probably bumped into ZeroPath and the whole “AI-native SAST” angle. I wanted to see if it actually performs better than the scanners I’ve used before, or if it’s mostly marketing. So I tested it on a real repo and then compared what it flagged (and what it didn’t) before and after turning on its AI-driven remediation.

ZeroPath Review: what I actually tested (and what I saw)

I tested ZeroPath in a setup that looks a lot like how teams run SAST in the real world: a CI-triggered scan on pull requests, with results posted back to the developer workflow. Concretely, my test repo was a small-to-medium service (about 120k lines of code across a mix of app code and shared utilities), primarily in JavaScript/TypeScript with a handful of backend endpoints and some infrastructure scripts. For CI, I used GitHub Actions (PR-based runs), and I focused on “time-to-first-scan” and how the findings behaved when AI remediation was enabled.

Here’s the part that matters: my first run wasn’t instant. Setup took longer than I expected because I had to align the integration with how my repo is structured (monorepo-ish layout, shared packages, and a couple of non-standard directories). Once I got the integration dialed in, subsequent scans were much smoother. On my machine and runner sizing, I typically saw scan results in the same order of magnitude as other SAST tools I’ve used (think minutes, not seconds), but the bigger difference wasn’t speed — it was signal quality.

In my experience, the biggest win with ZeroPath is how it narrows down what developers have to look at. Before AI-driven triage, I was getting a steady stream of “possible issues” that required manual context switching. After enabling ZeroPath’s AI-assisted workflow, the findings I got were more grounded in actual usage paths (not just “this function exists, therefore vulnerability”). That didn’t mean it found fewer real bugs across the board — it meant it asked me to review fewer things that didn’t deserve my attention.

Did it magically eliminate false positives? No. But it did reduce the amount of noise I had to triage, and it was noticeably faster to land on “real fix now” versus “this is a false alarm, ignore it”.

Example 1: injection risk where the fix was actually actionable

One finding that stood out was an injection-style issue in a request handler where user input was being used to build a query string. The key detail wasn’t just that it “detected” something. It pointed at a specific call path and treated the input as tainted through the flow into the sink.

What it flagged (anonymized):

• Type: injection / unsafe query construction
• Location: src/handlers/search.ts (around the function that builds the query)
• Why it mattered: it connected the request parameter to the string concatenation used for query building

Proposed remediation:

• Switch from string concatenation to parameterized queries (prepared statements / query builder parameters)
• Ensure user input is passed as a parameter rather than embedded directly

Was the fix correct? Yes. The suggested approach matched what I’d expect for this kind of risk, and when I applied the change, the finding disappeared on the next scan.

Example 2: a false positive it didn’t waste my time on

I also tested a case I know from experience that some scanners love to over-flag: a “dangerous” function call that’s wrapped in a safe guard. In this repo, there’s a utility that conditionally sanitizes or normalizes input before it hits the sink.

What happened with ZeroPath:

• Type: would-be injection sink (sanitization wrapper existed)
• Result: the finding was either not raised or was deprioritized compared to what I’d seen with more generic rules

I can’t claim this will happen for every codebase (because it depends on how clear the data flow is), but in my test it did a better job of respecting context than the blunt tools I’ve used.

Example 3: secrets/config issues in Infrastructure as Code

ZeroPath also caught at least one infrastructure-related misconfiguration. I ran it with a small Terraform snippet in the repo (not a huge IaC estate), and it flagged a configuration pattern that could lead to exposure or insecure defaults.

What it flagged (anonymized):

• Type: IaC misconfiguration / insecure setting
• Location: infra/terraform/modules/storage/main.tf (resource definition around access settings)
• Why it mattered: the configuration implied overly permissive access

Remediation: tighten access controls and align the setting with least-privilege defaults.

Was it correct? Yes. The change was straightforward, and the next scan no longer reported it.

How the “2x” and “75% fewer false positives” claims held up in my test

Let me be upfront: I didn’t run a lab-grade benchmark with a giant dataset. I did a practical before/after comparison on the same repo and workflow.

• Baseline: I reviewed the findings from an earlier scan pass where AI triage/remediation wasn’t applied in the same way.
• After: I re-ran scans with ZeroPath’s AI-driven triage and remediation enabled, then compared how many items I had to actually triage manually.

In that limited scope, I saw fewer “review churn” items and a smaller percentage of results that turned out to be noise. I also noticed that the issues that did remain were easier to understand because the context and suggested remediation were tied to the code path.

That said, I can’t honestly say my small test proves the vendor numbers (like “2x” or “75%”) across every stack. If you want those exact metrics, you’ll need to validate on your own codebase with your own CI runs, because the starting baseline (how noisy your current tools are) changes the math fast.

Time-to-first-scan and what changed after remediation

Time-to-first-scan was mostly about integration friction. Once I got the integration configured, the follow-up scans were predictable. The bigger “time saved” came from remediation suggestions. Instead of me opening issues, searching for patterns, and manually drafting fixes, ZeroPath gave me a starting point that I could apply and verify quickly.

After I applied the fixes from a couple of high-confidence findings, I saw the next scan reduce repeat reports for those same areas. In other words: it wasn’t just surfacing issues; it helped close the loop.

Key Features I cared about (not just the buzzwords)

1. AI-native SAST that tries to understand code context, not just match signatures
2. Finding prioritization aimed at reducing false positives and developer triage time
3. Remediation suggestions that include concrete guidance (and in my case, fixes that actually validated on re-scan)
4. Contextual triage so you can see the why behind a finding instead of starting from scratch
5. IaC misconfiguration detection alongside application code
6. Compliance-oriented reporting (SOC2/ISO27001 mentioned) for teams that need evidence, not just alerts
7. Integrations with GitHub, GitLab, Bitbucket, and Azure DevOps so you can run scans where your team already works
8. Developer feedback designed to be consumable during normal pull request review
9. Custom policies so you can align scans with your risk tolerance

Pros and Cons (the good and the annoying parts)

Pros

• Less noise to triage: In my test, fewer results were “maybe” issues that wasted time.
• Fix suggestions were practical: The remediation guidance aligned with what I expected and didn’t require guesswork.
• Better context than generic SAST: I felt like the tool was looking at how data flows, not just scanning for suspicious strings.
• IaC coverage showed up: It wasn’t limited to app code.
• CI-friendly workflow: Once configured, it fit into PR checks without turning security into a separate process.

Cons

• Setup can be fiddly: If your repo structure is non-standard, expect a bit of tuning before scans behave.
• AI still needs validation: You’ll still review findings. The tool helps, but it won’t replace AppSec judgment.
• Pricing isn’t transparent: I didn’t see clear public tiers or numbers, so budget planning may require contacting sales.

Pricing Plans: what you should check before you buy

At the time of writing, ZeroPath doesn’t publish straightforward pricing tiers on the page I reviewed. What I could confirm is that plans are customized based on organizational needs. If you’re evaluating ROI, that usually means pricing depends on things like number of repos, scan frequency, team size, and which integrations or compliance/reporting features you need.

What I recommend you ask for (so you don’t get surprised later):

• What’s included in each plan (AI remediation? compliance exports? IaC scanning?)
• How scan limits work (per repo, per month, per runner, etc.)
• Whether PR checks have performance or quota constraints
• Support/enablement included for getting CI configured

If you want a quick sanity check on cost, estimate your current “security time cost” (how many findings developers/AppSec review per week) and compare it to the expected reduction in triage. That’s the ROI lever that mattered most in my test.

Wrap up

ZeroPath impressed me more with practical triage than with raw “scan everything” claims. In my test, it produced fewer distractions, gave remediation suggestions I could actually apply, and it helped reduce repeat reporting after fixes. The trade-off is that you still need to validate results and you might spend some time getting the integration right for your repo layout.

If your team is tired of drowning in SAST noise and you want a workflow that feels closer to normal PR review (instead of a separate security ticketing ritual), ZeroPath is worth a serious look. Just don’t take the “2x” and “75%” numbers on faith — run it against your own code and measure what changes for your specific baseline.