The model
Start free. Pay when it is worth paying for.
We are a new company, and the pricing says so. Find out whether there is anything wrong with your software before you spend anything — then decide whether the detail is worth two thousand dollars.
Scan
$0
one target
Scores and counts by severity, so you know whether there is anything worth acting on. No invoice, no commitment.
Start with a free scanFull report
Most useful$2,000
one target
Everything we found, how to reproduce it, and how to fix it.
Request a full report| What you get | Scan$0 | Full report$2,000 | Continuous$10,000 |
|---|---|---|---|
| Security scoresOverall posture, scored by severity. | Included | Included | Included |
| Vulnerability counts by severityHow many we found, and how bad they are. | Included | Included | Included |
| Interactive reportThe paid deliverable. The free scan returns the summary above, not the report. | Not included | Included | Included |
| Full finding detailCWE, CVSS 3.1, affected endpoint, evidence. | Not included | Included | Included |
| Reproduction script per findingRe-run it after your fix to prove the fix landed. | Not included | Included | Included |
| Proposed fix as a diffWhite-box engagements. Formatted for a pull request. | Not included | Included | Included |
| Scans at least twice a month | Not included | Not included | Included |
| Delta testing in your pipelineChanged code gets tested as it merges. Diff-scoped testing needs source access, so this part is white-box. | Not included | Not included | Included |
| Testing modeWhite-box needs source access and an hour of your engineers' time — at every tier, including the free one. | Black-box or white-box | Black-box or white-box | Black-box or white-box |
Prices in USD. One target means one application, repository, or binary. Talk to us about scope if you have several — we would rather size it properly than surprise you. Every tier begins the same way: a signed agreement and authorisation before anything runs, and a first report anywhere from a day to several weeks later depending on the application. How an engagement works →
Modes
Black-box or white-box
The tier decides what you receive. The mode decides how we work — and it has a real effect on what we find.
Black-box
No access to your code.
We work the way an outside attacker does — from the outside in, against your running application. It is how demos run, because it needs nothing from you but a URL and permission.
- Nothing required from your team but a target and written authorisation
- Findings are exploit-validated against the live application
- Lower efficiency than white-box — no source to reason about, so coverage depends on what is reachable from outside
White-box
We read your source, and we talk to you.
Source access plus a one-hour interview with your team — the same way any manual penetration testing firm starts an engagement. Static and dynamic analysis run together, and findings come back with a proposed fix.
- Static analysis and live testing correlated against each other
- One hour of your engineers' time to walk us through the architecture
- Findings arrive with a proposed fix as a diff, ready to drop into a pull request
Demos run black-box, because it needs nothing from you but permission. It is also the weaker of the two: with no source to reason about, coverage is limited to what is reachable from outside. If a demo looks good, white-box will look better.
Questions
The ones worth asking
- What do you need from me to start?
- A signed agreement and a signed authorisation to test, first — without both we have no legal basis to touch anything, and nothing runs. After that: the target address and test credentials for the roles we need to exercise. For white-box, add source access and one hour of your engineers' time. By default there is no agent to install and nothing to deploy; an in-your-environment run is possible on request.
- How long until I get the first report?
- Anywhere from a day to several weeks. A contained application tested black-box is quick; a large system, a white-box engagement, or findings that need a chain built and re-tested before we will put them in writing all take longer. You get a real estimate after the discovery call rather than a guess before it.
- What does the free scan actually tell me?
- Security scores and a count of what we found, broken down by severity. That is enough to know whether there is anything worth acting on, and whether it is urgent. It is a summary, not the interactive report — the finding detail, the reproduction scripts and the fixes all start at the paid tier.
- Can the free scan be white-box?
- Yes. Any tier can run either mode. If you are willing to give us source access and an hour of your engineers' time, the free scan will find more than a black-box one would — you still get the summary rather than the report, but it will be a better-informed summary.
- Why does white-box need an hour of my time?
- The same reason a manual penetration testing firm asks for it. Source tells us what the code does; it does not tell us what it is supposed to do. Which roles exist, which tenants must never see each other, which endpoint is deliberately public — that comes from you, and business-logic flaws are invisible without it.
- Is my code retained or used for training?
- No. Your source is copied into an isolated container that is destroyed when the engagement ends, along with the captured traffic and the exploit code. The interactive report is the only thing that leaves it — there is no artifact bundle and no platform holding a copy of your code. None of it trains a model. If you need this in writing before anything runs, it goes in the agreement.
- Can you run it inside our environment?
- Yes — the scanner is a self-contained tool rather than a hosted service, so it can run where your code already lives. Bring it up on the call; it is a common requirement and it changes nothing about the deliverable.
- What if you find nothing?
- Then the free scan cost you nothing and you have a summary saying so. We would rather tell you that than pad a report to justify an invoice. If you need something an auditor will accept, that is the paid report — and we will say in it exactly what we tested and what we did not.
- What is not covered?
- Web findings are exploit-validated — we ran the exploit and observed the effect. Analysis of compiled binaries is static: findings are recovered from decompilation and pinned to the exact function, but they are not runtime-proven, and we label them that way in the report. We will not pretend otherwise on a sales call either.
- Why is this so much cheaper than a manual pentest?
- Because most of the labour in a manual engagement is machine work that a person was doing by hand. We are also new, and the pricing reflects that — it will not stay here forever.
Something not answered here? info@ria-labs.com
Start with the free one
Nominate a target and we will run it. If nothing comes back, you have lost nothing but an email.