Starter
€149/ month
For a small team with one product and a growing customer list.
- One web app and one API
- Unlimited repositories
- Daily testing
- Fixes raised as pull requests
- Full history of every issue
Continuous pentesting for teams without a security team.
Vallum finds real, reproduced vulnerabilities across your web apps and code, raises the fix as a pull request, and keeps a record you can hand to a customer.
- Web apps
- APIs
- Source code
- Pull requests
- Cloud accountsSoon
Web apps and APIs
Every issue comes with the proof.
Vallum doesn’t hand you a list of things that might be wrong. It tries them. When something works, you get the exact request that worked and the data that came back, so there is nothing left to argue about and nobody has to go and check.
The kinds of problems that cost you a customer: one account reading another’s data, a login that can be stepped around, an admin page reachable without an admin.
Code and pull requests
The fix arrives as a pull request.
Connect your repository and Vallum reviews what changes, finds the weak spots, and opens a pull request with the fix. Your team reviews it like any other change. Nobody has to learn a security tool to close a security issue.
It also watches for credentials committed by mistake and for dependencies with known problems — and it only raises the ones your code actually reaches.
From finding to fix
You hear about it once it's solved.
A traditional test ends with a document and a to-do list. Vallum keeps going: it proves the problem is real, writes the fix, and checks afterwards that the fix actually worked. What reaches you is a decision to approve, not a project to run.
Cloud and infrastructure — in development
Your accounts, next.
Misconfigured storage, over-permissive access, and ports open to the whole internet. Connect a read-only role and Vallum will check the same way it checks everything else.
- AWS
- Google Cloud
- Azure
- Kubernetes
Why this is different
What you'd expect from a security hire you can't afford yet.
Always on, not once a year
A booked pentest is accurate for about a week. Vallum re-tests continuously, so a problem introduced on a Tuesday is found on the Tuesday.
Nothing reported without proof
If Vallum can't demonstrate it, you don't hear about it. Every issue carries the request that worked and the response that came back.
A shortlist, not a queue
Most of what security tooling produces is noise. Vallum sorts it and explains the ranking, so what reaches you is small enough to act on.
Fixes, not just findings
Where the fix is clear, Vallum writes it and opens a pull request against your repository. You review a change, not a report.
Decisions that stick
Mark something as accepted risk and it stays accepted. Re-tests keep your notes and your history instead of raising it again next week.
A ceiling you set
Every run has a time limit and a spend limit you control. There is no scenario where a test runs away with your bill.
Built for your security review
The questions your customers will ask us.
You’re buying a product that looks at your source code and your production systems. It’s reasonable to ask how that’s kept safe, so here is the short version.
Your code never leaves the run
A test works against a copy inside its own isolated machine, which is destroyed the moment the run ends. We keep the findings, not your repository.
Nothing is tested without permission
Before Vallum touches a domain, you prove you control it — a DNS record, a file on the server, or connecting the repository. We record who authorized it and when.
Found passwords are never stored
If a credential turns up in your code, Vallum stores a one-way fingerprint of it so it can recognise the same one later. The value itself is never written down.
One customer can't see another
Separation is enforced by the database itself, not by application code remembering to filter. A bug in our software cannot expose your data to someone else's account.
A record you can hand over
Every issue, every decision, and every state change is written to a log that cannot be edited or deleted afterwards — including by us. That is what a reviewer actually asks to see.
Limits you control
Set how long a test may run and how much it may spend. A run that would exceed either is refused rather than quietly allowed through.
Pricing
Less than one traditional pentest, running all year.
A booked test costs five figures, takes weeks to schedule, and is out of date by the time the document lands. This is the same coverage, billed monthly, with no procurement cycle.
Growth
Most popular€499/ month
For companies closing deals that come with a security questionnaire.
- Up to fifteen apps and APIs
- Ten deep agent tests each month
- Spend and time limits you set
- Exportable record for reviewers
- Priority support
Enterprise
Talk to us
For estates where listing everything is the hard part.
- Unlimited apps, APIs and repositories
- Custom test allowances
- Single sign-on and role mapping
- Data residency and retention terms
- Named contact and response times
Questions
What people ask before they buy.
Is this a real pentest, or a scanner with better marketing?
It's testing, not scanning. A scanner matches patterns and tells you what might be wrong. Vallum tries things — it sends the request, reads what comes back, and follows what it learns, the same way a tester does. Nothing is reported unless it worked, and you get the proof it worked.
Can we give this to a customer as evidence?
You can show them the record: every issue found, what was done about it, who decided, and when — in a log nobody can edit after the fact. That covers most security questionnaires. If a buyer specifically requires a signed report from an accredited firm, you still need that firm; Vallum keeps the list short and the findings current so that engagement is cheaper and shorter.
Will it break our production systems?
The continuous testing is read-only and paced so it doesn't add meaningful load. The deeper agent-driven tests genuinely try things, so they can create records and trigger your alerts — that's why they're separate, why they cost more, and why they run inside a time limit you set. Most teams point those at staging first.
We don't have anyone to manage this. Is that a problem?
No — that's who it's built for. There's nothing to tune and no rules to write. You connect a domain and a repository, and what comes back is a short list with a fix attached to most of it. If you can review a pull request, you can run this.
What if it's wrong about something?
Mark it as a false positive or an accepted risk and it stays marked, with your reasoning attached. Later tests won't raise it again. Anything that was reported to you had to be demonstrated first, so this comes up less than you'd expect.
Can we test something we don't own?
No. Before testing a domain, you have to prove you control it. It's a deliberate limit — a tool that will attack any address you type is a liability, and we record who authorized each target in case a test is ever questioned.
Find out what a real attacker would find first.
Connect one domain and one repository. The first results come back the same day.