AI-Powered SAST and DAST: How LLM Agents Find & Validate Vulnerabilities in Your Code and Running Apps
TL;DR: Haxset's AI SAST maps your codebase, then runs a separate agent for each web or mobile vulnerability class. In thorough mode, a second model scans each class too, and validators check the findings before the report is built. AI DAST tests the running app through a per-scan intercepting proxy, with AI probers for access-control and business-logic bugs.
This is for you if your rule-based SAST tool reports hundreds of findings per scan and your developers have stopped reading them. Skip this if you only need a dependency check; a standalone software composition analysis (SCA) tool covers that.
Key points
- Each AI SAST finding is scored from 1 to 10. Agreement between two models (thorough mode only) and a validator's confirmation each add 1, and findings below 6 are dropped.
- Dependency, secret and infrastructure-as-code checks use no model, and a secret finding never contains the raw secret.
- AI DAST's default safe mode never sends PUT, PATCH or DELETE, and a class the scan did not test is listed as skipped, with the reason.
Why does rule-based SAST produce so much noise?
Pattern-based SAST rules, and taint rules that cannot model sanitizers or authorization checks, flag code that an attacker may not be able to reach. Someone then has to read each alert to find the real ones.
Ghost Security, a vendor that sells AI code analysis, scanned 2,856 public GitHub repositories in Go, Python and PHP.1 It used one open-source SAST engine with a single rule per test, two of them its own, and a human analyst checked its AI triage labels. Of 2,116 findings, 180 were true positives and 1,936 (91.5%) were false positives.12 The study covers three rules in three frameworks, so its 91.5% describes those rules only. OWASP also lists "High numbers of false positives." among the weaknesses of source code analysis tools.3
In "Sifting the Noise" (arXiv:2601.22952v1, a January 2026 preprint), large language model (LLM) agents reduced "an initial FP detection rate of over 92% on the OWASP Benchmark to as low as 6.3% in the best configuration".4 The authors warned that aggressive filtering risks "suppressing true vulnerabilities". Haxset's confidence cut-off, described below, is such a filter.
How does Haxset's AI SAST pipeline work?
Haxset's AI SAST maps the codebase, gives each vulnerability class its own agent, then validates, scores and clamps the findings. An agent here is a model that works inside a copy of the source tree, using file-reading and search tools over many steps. A scan takes a zip or 7z archive, an Android APK or a Git repository. The .git folder is removed first, so the Git history is not scanned.
A model first profiles the codebase (languages, frameworks, authentication model, entry points), and the profile goes into every later prompt. In thorough mode, two models scan each class. A validator that can also read the code judges each finding as a true positive, a false positive or "needs investigation", and can raise or lower its confidence. Findings that are not yet settled (confirmed, found by both models and with a starting confidence of at least 8) get a second validation pass.
Each class also has a baseline severity, and a finding's severity can move at most one step from it. Reflected XSS (baseline medium) can be low, medium or high, never critical. Thorough is the default; fast mode uses one model per class and one validation call at the end.
Example vulnerability classes, with CWE IDs
Each scan uses one platform's class catalog, web or mobile. Every class maps to a CWE (Common Weakness Enumeration) entry5 and has a baseline severity. Classes example:
| Class | Platform | CWE | Baseline severity |
|---|---|---|---|
| SQL injection | web | CWE-89 | critical |
| Stored XSS | web | CWE-79 | high |
| Insecure direct object reference (IDOR) | web | CWE-639 | high |
| Server-side request forgery (SSRF) | web | CWE-918 | high |
| Insecure deserialization | web | CWE-502 | critical |
| Server-side template injection (SSTI) | web | CWE-1336 | critical |
| Insecure local data storage | mobile | CWE-922 | high |
| Missing or bypassable certificate pinning | mobile | CWE-295 | high |
| Exported component exposure | mobile | CWE-926 | high |
| WebView misconfiguration | mobile | CWE-749 | high |
The mobile classes are aligned with OWASP MASVS and MASTG.6 iOS source code is accepted; compiled .ipa files are not.
Two models, one verdict: how agreement raises confidence
In thorough mode, two different models scan each class separately. The scorer starts from the model's confidence (1 to 10), as revised by the validator by up to 5 points either way. It adds 1 when both models found the finding and 1 when a validator confirmed it, and subtracts 1 for "needs investigation". Findings below 6 are dropped, and so is any finding a validator marked false.
A finding that one model reports at 5, with no confirmation, is dropped. The same finding from both models, confirmed with no change to its confidence, scores 7 and stays.
Agreement is evidence, not proof. Two models can share a blind spot, and the gain depends on the model and the weakness type.4 Before you act on a high-severity finding, read its code snippet and exploit scenario.
Update, November 2026: a SQL injection our SAST found in Mautic
Haxset's AI SAST found a SQL injection in Mautic, an open-source marketing automation platform, and Haxset reported it to the maintainers. Mautic published the advisory GHSA-fj8v-c9c3-7q26, "SQL Injection in Contact Lookup AJAX Endpoint", on October 26, 2026, with the ID CVE-2026-115191. 7 A request parameter that chooses which contact field to search reaches a database query without validation. Any signed-in Mautic user, whatever their role, can use it to run blind SQL queries and read the database, including user password hashes.
The advisory rates the flaw high, with a CVSS 3.1 score of 7.1, and Mautic 5.2.12, 6.0.10 and 7.2.2 fix it. Haxset is one of the reporters the advisory credits. Other vulnerabilities Haxset has found and reported are not public yet; we will describe them after the maintainers release fixes.

The SQL injection that became CVE-2026-115191, as Haxset's SAST reported it. The fix is released, so the code is shown here.
SCA, secrets and IaC scanning are built in
Each SAST scan also runs scanners that use no model. Software composition analysis (SCA) reads lockfiles and looks up each package in public vulnerability databases, reporting CVE or GitHub Security Advisory (GHSA) IDs and fixed versions. It covers npm, PyPI, Maven, Go, crates.io, RubyGems, Packagist, Pub and Swift Package Manager, but not CocoaPods. An APK contains no lockfile, so dependency results need the source code.
Secret detection scans the current files, and a finding carries a masked snippet and a one-way hash, never the raw secret. For web code, infrastructure-as-code (IaC) checks, including rules Haxset wrote, cover Terraform, CloudFormation, Azure Resource Manager templates, Kubernetes, Helm and Dockerfiles. Container image CVE scanning is off by default.
How does AI DAST test a running application?
Haxset's AI DAST (dynamic application security testing) crawls the running application, then runs deterministic checks and AI probers. The probers are agents that send test requests with Haxset helper tools. Deterministic classes include SQL injection, XSS and XXE, and the probers cover classes such as IDOR and broken function-level authorization.
The crawler, tools and probers send their traffic through a proxy dedicated to the scan. It enforces the scope you chose (one page, one path or the whole host) and the HTTP methods the safety mode allows.
Safe mode, the default, sends GET, HEAD and OPTIONS requests plus POST requests with marker values, and never PUT, PATCH or DELETE. In both modes, the proxy blocks routes with destructive names such as logout, delete, register or payment. Matching is by name only, so a POST can still create a record or send a message on an unlisted route. Test a non-production copy where you can; it must also be on a public address.
You supply session cookies or headers for up to two accounts. With none, authorization classes are skipped and the results say so; with two, the scan compares what each account sees.
A DAST finding is "confirmed" only when an oracle, a deterministic check on the target's response, fired, and only the deterministic checks can reach that tier. It is "validated" when a model reviewer confirmed it, and "suspected" otherwise. With one account, the cross-session oracle must answer inconclusive, so a single-account IDOR test is recorded as inconclusive, not clean. A class that was not tested is listed as skipped, with the reason.
Like SAST, DAST keeps most findings within one severity step of their class baseline, and it applies that limit after the model reviewer. A missing security header, such as Strict-Transport-Security or Content-Security-Policy, is a security misconfiguration (CWE-16) with a low baseline. It can be reported as info, low or medium but never high, even when the model reviewer rates it higher.

A missing security header, confirmed by a deterministic check and rated low.
Matching SAST and DAST findings by hand
SAST and DAST run as separate scans, and the platform does not link their results, so a person matches them by CWE ID. SQL injection (CWE-89), XSS (CWE-79) and IDOR (CWE-639) appear in both catalogs. A SAST finding and a DAST finding on the same weakness and route give you the line to fix and evidence that it is reachable. A missing DAST match does not make a SAST finding false if the DAST class was skipped or inconclusive.
What you get: reports, exports and share links
Each scan produces a PDF report and a Markdown or Excel export. Each PDF you download has a fresh one-time password, while the exports are plaintext and leave out secret snippets. Share links go to up to 50 recipients; each works for one download, expires after 3 days and is stored only as a hash.
Disclosure, and how Haxset can help
Haxset offers a product in this category. To run both scans against one of your applications, contact us with the repository type and whether your test environment has a public address.
FAQ
Does AI SAST reduce false positives?
Research says it can, with limits. The "Sifting the Noise" preprint reports large reductions on the OWASP Benchmark and warns that aggressive filtering can suppress true vulnerabilities.4 Haxset drops findings that score below 6 out of 10 after model agreement and validator verdicts. We have not published a false-positive rate for Haxset's own SAST.
Can AI replace rule-based security scanners?
Not for every job. Haxset uses models where a check needs judgment, such as access control and business logic, and deterministic tools where an exact answer exists, such as vulnerability-database lookups for dependencies. In DAST, only a deterministic oracle can mark a finding confirmed; AI-class findings carry a reviewer's verdict instead.
Does Haxset's AI SAST support iOS apps?
It accepts iOS source code and scans it with the mobile classes, whose prompts name iOS equivalents for Android features such as exported components. It does not accept compiled .ipa files, and SCA checks Swift Package Manager dependencies as well.
References
-
Ghost Security, Exorcising the SAST Demons: How Ghost is Replacing Rule-Based Scanning with AI-Powered Triage and Detection, vendor report, April 2025. ↩ ↩2
-
Mirko Zorz, 91% noise: A look at what's wrong with traditional SAST tools, Help Net Security, 19 June 2025. ↩
-
OWASP Foundation, Source Code Analysis Tools. ↩
-
Yunpeng Xiong and Ting Zhang, Sifting the Noise: A Comparative Study of LLM Agents in Vulnerability False Positive Filtering, arXiv:2601.22952v1 (preprint), 30 January 2026. ↩ ↩2 ↩3
-
MITRE, Common Weakness Enumeration (CWE). ↩
-
Mautic, SQL Injection in Contact Lookup AJAX Endpoint (GHSA-fj8v-c9c3-7q26, CVE-2026-115191), GitHub security advisory, October 26, 2026. ↩
Interested in how this research applies to your organization?
Get in Touch