Engagements
Research scoped to the system it protects
Every engagement starts with a short conversation about your target and what you need to learn. From there we agree a scope, a cadence and a handoff before any work begins.
A critical target, deeply understood.
For a release, codebase, binary or security question that needs disciplined adversarial research and a clear answer.
- Scope workshop
- Proof package for every confirmed finding
- Direct handoff to your engineers
Best for: a single repository, binary or web application.
A research loop inside your delivery cycle.
For teams that want security context to keep pace with their code instead of arriving as a periodic report.
- Diff-aware re-evaluation
- Integration with your workflow
- Ongoing review of findings
Best for: teams that ship often and want coverage to follow.
Research across complex systems.
For organizations coordinating several targets, teams or business-critical attack surfaces.
- Program design
- Custom environments and a dedicated researcher
- Cross-team reporting
Best for: a portfolio of systems under one program.
Find your starting point
Two questions, one recommendation
There is no price grid to decode. Tell us the shape of your situation and see which engagement we would start with.
How many systems are in scope?
How often does the code change?
We would start with Focused.
A time-boxed engagement on one repository, binary or web application, ending in a proof package your engineers can act on.
Worth bringing to the first conversation
- Where the code lives and how it builds
- How often you release or review
- Past reports or known issues
- Any confidentiality or disclosure limits
What shapes the scope
Six things we ask about first
Hover, tap or tab through them. Together they decide the shape of an engagement.
The target
Source code, compiled binaries or both. A single repository and a platform with many components call for different approaches.
Size and complexity
Languages, dependencies and how much of the code is reachable from outside. This decides how deep each pass can go.
Exposure
What an attacker can actually touch: parsers, protocol handlers, authentication, update paths. We start where the risk is.
Cadence
A one-time question before a release, a review at every release, or coverage that follows every change.
Environment
How the software builds and runs, and what an isolated test environment needs to reproduce real behavior.
Handoff
How findings reach your engineers: the report format, your tracking tools and any disclosure coordination.
How an engagement runs
From first call to retest
Scope
A short call maps targets, threat model and timeline before any work begins.
Reconnaissance
Attack-surface enumeration: entry points, trust boundaries and the code paths that actually matter.
Hunt
Researchers and tooling work the same codebase: manual review for logic, automated reasoning for scale.
Validate
Every finding is reproduced in isolation before it is written down. Nothing speculative is reported.
Report and retest
Root cause, impact and remediation guidance your engineers can act on, plus retesting after patches land.
Side by side
Three shapes, one standard of evidence
Swipe sideways to compare →
| Feature | Focused | Continuous | Enterprise |
|---|---|---|---|
| Best for | A release, codebase, binary or specific question | Teams that ship often and want coverage to follow | Several targets, teams or critical systems |
| Scope | One repository, binary or web application | One or more targets, re-evaluated as they change | Multiple targets with custom environments |
| Cadence | Time-boxed, agreed at scoping | Ongoing, aligned with your release cycle | A program planned with your teams |
| Proof for every finding | Included | Included | Included |
| Integration | Handoff to your engineers | Workflow integration for development, triage and fixes | Cross-team reporting and program design |
| Retesting | After fixes land | Diff-aware, on every change | Across the program |
| Dedicated researcher | Not part of this shape | Not part of this shape | Included |
In every engagement
What you get whichever shape you choose
Proof for every finding
Each confirmed finding comes with reproducible evidence, held to the evidence standard.
Reviewed by people
Researchers verify the evidence and the reasoning before anything is delivered.
Private by default
Findings from a client engagement stay private to that client.
Isolated environments
Analysis and validation run in isolated, ephemeral sandboxes.
Engineering handoff
Root cause, impact and remediation guidance, written for the people who will fix it.
Retesting
Fixes are retested after patches land, so a closed finding is a verified one.
Questions worth asking first
Before you get in touch
Is there a price list?
No fixed price list. The right shape depends on the target, how often it changes and the handoff you need, so a proposal follows a short conversation rather than a grid.
How is an engagement scoped?
We start with the target, its exposure and the outcome your engineering team needs. From there we recommend the right research shape and operating cadence.
What does a Vorthix handoff include?
Each confirmed finding comes with reproducible evidence, root-cause context and remediation material designed for the people who will fix it.
Can Vorthix work with our existing security workflow?
Yes. Continuous engagements are designed around the systems your team already uses for development, triage and remediation.
What happens to our findings?
Findings from a client engagement stay private to that client. Vulnerabilities in third-party open-source software are reported to the maintainers first and disclosed in coordination with them.
Can an engagement change shape later?
Yes. A focused engagement can be extended, or a continuous one narrowed, as your priorities change. The scope is agreed with you before any work starts.
Request access
See how Vorthix works on your code
Access is currently by request for security teams and researchers.
- Working proof of concept
- Sanitizer-backed trace
- Suggested patch and regression test