240 rules · 101 CWEs · reachability ranking

Find the vulnerabilities that actually matter.

Static security scanning that understands how your code is built, then ranks findings by whether a public route can reach them. No account. No database. No AI in detection.

Scan your repoSee how it works

src/routes/orders.tsscanning

// build order lookupconst customerId = req.body.customerId;const rows = await db.query( `SELECT * FROM orders WHERE id = ${customerId}`);return res.json(rows);

CriticalSQL injection· Exploitable

Scroll

InjectionSecretsBroken AuthXSSCloud MisconfigWeak CryptoIDORSSRFKnown CVEsSecurity HeadersCI/CDSSTIInjectionSecretsBroken AuthXSSCloud MisconfigWeak CryptoIDORSSRFKnown CVEsSecurity HeadersCI/CDSSTI

240

Detection rules

Vuln categories

101

CWEs covered

<60s

Typical web-app scan

/ The unified pipeline

One scan. Four passes.
One deduplicated list.

Every finding is reconciled across passes and labelled with how strong its evidence is, so you can tell a proven code path from a pattern that only looks risky.

01 — Sweep

Broad coverage

18 vulnerability categories (injection, secrets, auth, XSS, crypto, cloud, headers) checked in one fast pass over source, config, IaC and CI files.

02 — Confirm

Reads the code, not just the text

Each hit is checked against how the code is actually written. Constant strings, checksums and dead examples are dropped; real flows of user input are kept.

03 — Map

A map of your app

Routes, handlers, database access and outbound calls are mapped, so we can see where user input enters and where it ends up.

04 — Scoring

Exploitability scoring

A search from every public route checks which risky calls it can reach. Each finding is labelled confirmed, reachable or unknown with a 0–100 confidence and the reason. Unknown means no path was traced, not that it is safe.

Pass 1 · Sweep240 checks, one pass

app.use(cors({ origin: '*' })) cors-wildcard · MEDIUMcrypto.createHash('md5') weak-hash-md5 · MEDIUMsecretAccessKey: 'wJal…KEY' secret-aws-key · CRITICAL

injectionsecretscryptoheaders

Pass 2 · ConfirmKept or dropped, with the reason

db.query(`… $${req.body.id}`) kept · user input reaches the querydb.query('SELECT 1') dropped · constant stringcrypto.createHash('md5').update(file) dropped · file checksum, not a password

confirmed in codeuser input in SQL

Pass 3 · MapAttack surface & exploit paths

input: req.bodyreaches: db.query

Pass 4 · ScoringRanked by what an attacker can reach

91confidence

Exploitablereachable from POST /api/orders

Reachable ≠ theoretical.

Most scanners stop at "this pattern looks dangerous." SecureVibe traces from public entry points to the dangerous call and shows the path when it finds one, so you triage what an attacker can reach first.

/ What we detect

Coverage across every class of risk

From the OWASP Top 10 to leaked secrets, cloud misconfig, and known CVEs in your dependencies.

Authentication

Hardcoded creds, JWT issues, session flaws

Access Control

IDOR, mass assignment, CORS misconfig

Injection

SQL, NoSQL, OS command, SSTI, XPath

XSS

DOM-based, React, Vue, Angular, jQuery

Secrets

API keys, tokens, private keys, env files

Cloud

AWS, GCP, Azure, K8s misconfigurations

Dependencies

Known CVEs via OSV.dev integration

Cryptography

Weak hashing, broken TLS, insecure random

Misconfiguration

Debug mode, exposed endpoints, defaults

Security Headers

CSP, HSTS, X-Frame-Options, Referrer

CI/CD

GitHub Actions, Dockerfile, build scripts

Framework

Next.js, Express, NestJS, React, Vue

/ Ask the Graph

Query your codebase in plain language

The same map of your app that ranks findings answers questions. Ask where data flows, why a finding is reachable, or what an attacker can touch from a public route.

query — ask a question about the code
explain — a class, function or route + its neighbours
path — how one function reaches another
attack-surface — public inputs, risky calls, exploit paths

ask-the-graph · scan #a3f9

how can an attacker reach db.query in orders.ts?

Path found from POST /api/orders →
createOrder() → db.query()
User input req.body.customerId flows
unsanitised into a SQL template literal.
Exploitability: confirmed (91%)

structuralSQL injection via string concatenation Exploitable (91%)

const customerId = req.body.customerId; const rows = await db.query( `SELECT * FROM orders WHERE id = ${customerId}` );

source req.body.customerId · orders.ts:138

sink db.query(`… $${customerId}`) · orders.ts:142

/ Evidence, not alerts

Every finding ships its proof

Code frames, input→sink chains, the surrounding code, a CWE/OWASP tag and a confidence reason. You see exactly why it fired — and how to fix it.

Labelled structural, confirmed pattern, or pattern only
Git blame attribution per finding (opt-in)
Optional AI-assisted fixes, one click away

/ Risk grading

From a sea of findings to a single grade

Unified findings roll up into an A–F grade and a 0–200 risk score — strict mode grades on exploitable findings only.

score 0

1–18

19–46

47–74

75+

/ There's more under the hoodExplore the full feature indexA scroll-driven deep dive — the four passes, the app map, reachability ranking, AI fixes, and the benchmark receipts.

Scan your code in seconds.

Paste a Git repo URL or upload a ZIP. Free, no account, no database required.