Haxset Engine

Haxset Engine

The engine behind everything we ship. One LLM core, six modules: SAST, DAST, API fuzzing, CI/CD scanning, ASM, and agentic pentesting. It reads code the way an attacker reads it — and everything it finds is checked by two independent models, validated against the real code path, and scored for confidence before you ever see it. Self-hosted on infrastructure we operate — deployable in your region, so your code never leaves your country.

What the engine does

Haxset
Engine

LLM core

self-hosted models2 models per classconfidence 1–10validated findings

  • SASTReads your source code

    cross-file · framework-aware · 25+ classes

  • DASTAttacks your running app

    authenticated · WAF-aware

  • API FuzzingFuzzes & exploits your APIs

    REST & GraphQL · schema-aware · safe exploitation

  • CI/CDSecurity-reviews every PR

    vuln scanning · SCA · secrets · IaC & containers

  • ASMMaps everything you expose

    subdomains · cloud assets · continuous

  • Agentic PentestChains findings like an operator

    reachability · impact validation

25+

vulnerability classes

2

models per class

1–10

confidence per finding

< 6

never ships

Watch it run

How a scan runs

Six phases, in order, every time. The demo on the right is the same pipeline that runs in production, on a real open-source codebase — hover a finding for its evidence trail.

github.com/juice-shop/juice-shop

SAST · thorough · 25+ vulnerability classes

Scanning

Characterizing codebase

7%

Findings appear here as classes complete…

Every finding is scored 1–10 and checked by a second model before it reaches your report.

01

Characterizing

The engine maps the codebase first — languages, frameworks, entry points, and trust boundaries — so every later phase reads code in context instead of in isolation.

02

Scanning

25+ vulnerability classes, each scanned by two independent models working across the whole codebase. A finding that only one model can see starts life with less confidence.

03

Validating

Every candidate finding is checked against the actual code path: does the input really reach the sink? Findings that don't survive are marked false positives and dropped.

04

Deduplicating

The same root cause reported two ways is merged into one finding, so your queue reflects real work — not the same bug counted three times.

05

Reviewing

A final review pass scores each finding 1–10 for confidence, backed by the validation evidence. Below 6, it never reaches you.

06

Reporting

What ships is a report your engineers can act on: exact location, the evidence trail, and a code-level fix — delivered straight to your dashboard.

Data sovereignty

Self-hosted models.
Zero data leakage.

The engine's models run on infrastructure we operate — never third-party AI APIs. We are present in multiple regions and can deploy in yours, so your source code, prompts, findings, and reports never leave your country.

Self-hosted AIIn-country data residencyKSA · Jordan · your region

  • Self-hosted LLMs

    Every model behind the six modules runs on hardware we operate. Nothing is sent to third-party AI providers — and nothing is ever used for training.

  • Deployed in your region

    We operate in multiple regions — including Saudi Arabia and Jordan — and can deploy in your region or on-premises, so data residency follows your rules.

  • Regulation-aligned

    Reporting maps to the frameworks that apply to you — PDPL and NCA ECC in the Kingdom; GDPR, SOC 2, and ISO 27001 internationally.

Accuracy

Why you can trust what it reports

Any scanner can produce findings. The engine's job is to make sure that what reaches you is real, deduplicated, and worth your engineers' time.

Multi-model consensus

Every vulnerability class is scanned by two independent models. Agreement earns confidence; disagreement costs it. No single model's opinion ships unchecked.

False-positive elimination

A dedicated validation phase confirms each finding against the real code path before it reaches your queue. Noise is the engine's problem, not yours.

Whole-codebase context

The engine reads your repository the way a senior reviewer does — cross-file, framework-aware, and diff-in-context when it's reviewing a pull request.

Confidence scoring

Every finding carries a 1–10 score backed by validation evidence, so your team can triage by trust — and anything below 6 never ships at all.

In your pipeline

The same engine, on every pull request

The PR Security Scanner runs the engine against every diff — vulnerability detection, SCA, secret scanning, and IaC & container checks, all in the context of your whole codebase — and posts findings with a suggested fix directly on the pull request. Try the tabs to see what a review looks like.

PR Security Scanner — Reviews every pull request before it merges.

SAST — Full static analysis of your source code.

DAST — Runtime testing of your deployed application.

DevSecOps products

feat: payment flow updates

#482

src/lib/stripe.ts

·import Stripe from "stripe";

-const stripe = getStripeClient();

+const stripe = new Stripe("sk_live_51HxT…9fKq");

haxset-securitybot

Critical

A live Stripe secret key is committed in this change. Rotate the key and load it from an environment variable instead.

Suggested fix

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

Recheck passed after fix — 4 of 5 free rechecks left on this PR

Want the engine on your codebase? Point it at a repository and see what it finds — findings triaged by a consultant before delivery.

Request a scan