[ Documentation ]
Up and running in one pull request
Installation
1. Install the GitHub App
Add Hypervex to GitHub and choose which repositories it can review. Hypervex indexes them for codebase context — this takes a few minutes per repository.
2. Open a pull request
Any PR on a connected repository triggers a review automatically. No CI configuration, no YAML.
3. Findings appear on the PR
Within a couple of minutes, Hypervex posts a structured review comment: risk score, a file-by-file walkthrough, and a card for each finding — with Trace verdicts on the critical ones.
What Hypervex reviews
What it catches
- · OWASP Top 10 vulnerability classes in your diff
- · Auth and access-control gaps, with codebase context
- · Injection: SQL, command, template, XSS
- · Hardcoded secrets and credential handling
- · Regressions — a vulnerability fixed in an earlier PR that a new change reintroduces
- · Static-analysis findings (Semgrep) fused into the review and confirmed or dismissed by the AI pass
What it doesn't (honestly)
- · Runtime and infrastructure issues — misconfigured cloud resources, network policy, WAF rules
- · Full dependency auditing — it flags obviously vulnerable usage, but it is not a replacement for Dependabot
- · Business-logic fraud that requires understanding your product economics
- · A guarantee. Hypervex reduces the odds of shipping a vulnerability; nothing makes them zero
The finding format
Every finding is structured data — these fields exist on every finding record, not just in the comment text:
| Field | Type | What it's for |
|---|---|---|
| severity | enum | critical · high · medium · low. Critical and high mean a real exploit path; medium and low are hardening and best-practice issues. |
| confidence | int 0–100 | How certain Hypervex is that the finding is real and exploitable in your code — not a generic pattern match. 87% is “act now”; 34% is “read and decide.” |
| certainty | enum | definite (exploitable with no assumptions required) or potential (depends on context Hypervex couldn't fully confirm). |
| owasp_category | string | The OWASP Top 10 (2021) category, e.g. “A03:2021 — Injection.” Useful for compliance mapping and seeing where risk concentrates. |
| cwe | string | The specific weakness class, e.g. “CWE-89: SQL Injection” — the identifier security engineers and scanners share. |
| exploit_scenario | string | One or two sentences of “an attacker could…” in plain language. The why-you-should-care, written for a founder, not an auditor. |
| suggested_fix | code | A corrected code block that uses your codebase's existing patterns — if you already have a sanitiser or a parameterised-query helper, the fix cites it by file and line. |
| codebase_context_refs | string[] | The files (with line references) retrieved from your indexed codebase that explain the finding, e.g. ["lib/auth.ts:11"]. |
| trace_status | verdict | For critical/high findings with ≥80% confidence: “Trace verified” (the investigation pass confirmed the exploit path) or “Trace dismissed” (a mitigation blocks it), with the investigation notes. |
FAQ
Is my code sent to an AI?
Yes, to two providers. The pull-request diff plus relevant snippets from your indexed repository go to Claude by Anthropic to produce the review. Separately, code from repositories you index is sent to Google's Gemini API to be turned into the embeddings that make retrieval work — Google receives the code itself, not just the resulting vectors. Both run on paid API tiers where submitted content is not used to train models, and everything is sent per-review over encrypted connections. The full sub-processor list is in our Privacy Policy. If that boundary doesn't work for your team, Hypervex isn't the right tool — we'd rather say that here than in your security questionnaire.
What does the Trace do?
The Trace is a second investigation pass that runs on every critical or high finding with ≥80% confidence. It reads the finding, decides whether exploitability is provable from the diff alone, fetches the implicated files at the PR's exact commit if not, follows the call chain, and returns a verdict: verified (exploitable, with evidence) or dismissed (a mitigation blocks it). It's capped at 5 LLM calls per finding by design.
How is the risk score calculated?
The model assigns a 0–100 risk score for the whole PR based on the findings and their severity. Hypervex then floors that score to the worst finding's severity band (a PR with a critical finding can never score below 90) so a review can never read "clean" above a real issue. It's a triage signal, not a certified metric.
Can I review private repos?
Yes. Hypervex is a GitHub App — you choose exactly which repositories it can access during installation, and you can add or remove repositories at any time from your GitHub settings. Private repositories are the primary use case.
What languages are supported?
All of them, with a caveat. The review works on diffs and retrieved context, so it isn't gated on a per-language parser — TypeScript, Python, Go, Rust, Ruby, PHP, Java, and anything else GitHub can diff. Codebase indexing is deepest for languages with Tree-sitter support (the mainstream set); for others, reviews rely more on the diff itself.
How is pricing calculated?
By repositories and reviews per month. Free covers 1 repository and 10 reviews a month. Pro ($19/month) covers unlimited repositories, 100 reviews a month, and the Trace investigation pass. A review = one pull request analysed — pushes to the same PR re-review it without consuming a new review.
Do I need to change my CI?
No. Hypervex is webhook-driven — install the GitHub App and it reviews pull requests as they open. No YAML, no pipeline changes, no tokens to manage.
What happens on the first install?
Hypervex indexes the repositories you grant it (a few minutes for most codebases). Indexing is what gives reviews codebase context — findings can cite your existing helpers and patterns rather than generic advice.
Pricing details on the pricing page.