[ Features ]
What Hypervex catches, and how it proves it
OWASP Top 10 coverage
Every review maps findings to OWASP categories and CWE identifiers — stored as structured data, not prose. What each category looks like in real code:
Broken Access Control
e.g. CWE-639An API route that checks login but never checks ownership — any user reads any account's data by changing an ID.
Cryptographic Failures
e.g. CWE-328Passwords hashed with MD5, tokens signed with a hardcoded secret, PII stored in plaintext.
Injection
e.g. CWE-89SQL built with f-strings, shell commands assembled from user input, unsanitised HTML rendered into the DOM.
Insecure Design
e.g. CWE-204A password-reset flow that leaks whether an email exists, or rate limits that live only on the client.
Security Misconfiguration
e.g. CWE-942CORS set to *, debug mode reachable in production, default credentials in a compose file.
Vulnerable Components
e.g. CWE-1104A dependency pinned to a version with a known CVE, flagged when your usage is actually affected.
Auth Failures
e.g. CWE-287Session tokens that never expire, JWT verification with algorithm none, missing checks on privileged routes.
Data Integrity Failures
e.g. CWE-502Deserialising untrusted input with pickle, auto-updating from an unverified source.
Logging Failures
e.g. CWE-532Auth failures that are never logged — or secrets and PII written into logs.
SSRF
e.g. CWE-918A URL fetched server-side from user input — reaching internal metadata endpoints your firewall can't see.
[ The Trace ]
Assessment → traversal → synthesis
Most tools stop at "this looks vulnerable." For every critical or high finding with ≥80% confidence, Hypervex runs a second investigation pass — the Trace — that follows the code path and returns a verdict.
01 — Assessment
The Trace reads the finding and the diff. If the vulnerability is unambiguous from the diff alone, it verifies immediately. If exploitability depends on code elsewhere, it lists the exact files to examine.
02 — Traversal
It fetches those files at the PR's exact commit and follows the call chain — looking for the validation, auth check, or sanitisation that would block the exploit path.
03 — Synthesis
The evidence becomes a verdict: Trace verified (exploitable, with the call-chain proof) or Trace dismissed (a mitigation blocks it). The verdict posts with the finding, capped at 5 LLM calls by design.
[ Merge gate ]
A control, not a comment
Hypervex posts a GitHub check run on every pull request, so you can mark it a required status check in branch protection. A tool that can be dismissed by clicking merge is advisory. A required check is a control, and it leaves an audit trail.
Blocks
A critical finding assessed as definite — exploitable with no assumptions required. On Pro, the Trace independently verifies these by following the call chain, and downgrades any it cannot confirm, so Pro blocks less often rather than more.
Does not block
Everything else — highs, mediums, and criticals the Trace could not confirm. They still appear in the review; they just don't stop your team. A gate that fires on maybes gets turned off within a week.
If we're down
The check reports action required, never a pass. If a review didn't finish we know nothing about your code, and reporting success would be a lie you'd act on.
[ Confidence ]
A confidence score you can triage by
Every finding carries a 0–100 confidence score as a first-class field, separate from severity. It changes how you spend your attention:
High confidence means the exploit path is visible in the code: input reaches the sink, no mitigation in between — and at this level the Trace has usually verified it through the call chain. Block the merge and fix it.
Low confidence means the pattern is suspicious but exploitability depends on assumptions Hypervex couldn't confirm — caller behaviour, deployment config, data provenance. Read it, decide, merge.
[ Findings ]
Structured findings, not prose
This is what posts to your pull request — live component, not a screenshot. Severity, taxonomy, confidence, an exploit scenario in plain language, a fix in your codebase's own patterns, and the Trace verdict:
⬡ HYPERVEX SECURITY REVIEW
Risk Score: 91/100 · 1 finding (1 critical)
SQL query in api/orders.py:42 interpolates user_id directly into the statement.
An attacker could pass 1 OR 1=1 to dump every order in the table — your checkout route passes this parameter straight from the query string.
Fix: use the parameterised db.execute() pattern already in lib/db.py:17.
Free for one repository · no credit card