How Orvanta finds and fixes vulnerabilities
We build in the open where we can. This is a plain-language account of how the engine works, why it is designed the way it is, and what we are publishing for the wider community.
Most AI security tools ask a model to read code and hope it flags the right things. That produces confident-sounding output you cannot audit and cannot reproduce. Orvanta is built the other way around: a deterministic engine decides what is wrong, and the model is only used to explain and repair what the engine already found, grounded in that finding.
A deterministic, taint-aware engine
Detection runs 28 rules across the OWASP Top 10 categories — 11 critical, 10 high, and 7 medium by default severity. The rules are line-oriented with lightweight cross-line context, the same shape a security engineer greps for first in review. Each matcher favours precision over raw recall: a finding is produced only when a dangerous sink is being fed something dynamic, not merely because a dangerous API name appears. Taint tracking is heuristic — request-derived identifiers, string interpolation, and concatenation — which keeps a full scan fast enough to run inside a single serverless invocation.
Because the engine is deterministic, the same code always produces the same findings. You can read every rule, cite it, and reproduce it. We publish the whole set as an open rule catalog (human-readable) and as machine-readable JSON at /api/rules, under MIT.
The AI layer is grounded, then adversarially reviewed
For each finding, the model receives the exact code, the rule that fired, and its CWE context, and is asked to do three concrete things: explain the attack in real terms, write a production-ready patch, and justify why the patch preserves legitimate behaviour. Every generated patch then passes a second, adversarial review pass that checks it actually resolves the vulnerability without breaking the code. The model never invents a vulnerability the engine did not find, and it never sees a fix ship without that check.
Scoring that rewards fixing, not just finding
A codebase gets a single security score on a diminishing-returns curve, so resolving real issues moves the number visibly rather than getting lost in a wall of alerts. The goal is to make the gap between “we found a vulnerability” and “we fixed it” as short as possible, because that gap is where breaches live.
What we are opening up
- The full rule catalog, human-readable and as MIT-licensed JSON, so anyone can inspect or build on our detection taxonomy.
- Orvanta for Open Source: free Team-tier access for maintainers of public repositories and small OSS teams.
- Methodology notes like this one, updated as the engine and the fix-review loop evolve.