We agree what finished looks like before we start
Security is the one line on a build budget with no natural end. So we fix the end first.
Start with a scoped call
You get back the questions we still need answered and a call with the software engineer who would run the review.
You pick a level of the OWASP Application Security Verification Standard. We agree the scope in writing before anyone starts, and every requirement on that list is checked and marked pass or fail. The same team that finds a problem writes the fix, opens the pull request in your repository, and ships it with a test that fails if the defect comes back, then re-tests it within the agreed scope. When every requirement on the agreed list has a pass, or a recorded exception with its reason, the work is finished and we say so.
Two ways this question usually arrives
What this actually costs companies your size
You have probably been handed a breach figure in the millions. Those averages are computed over large enterprises holding regulated data at scale. The numbers below come from a government survey that sampled at random, and from a dataset of insurance claims that were actually paid. They describe companies closer to your size, and they argue against spending more than you need to.
UK government random-probability survey, fieldwork August to December 2025.
UK government random-probability survey, fieldwork August to December 2025.
A revenue-bracket distribution of 24,873 claims within a 69,683-claim US dataset.
The shape here is a long tail. A small number of companies carry most of the loss, and whether yours is one of them depends on how your system is built rather than on the average. That is the question a review answers.
What a late start cannot buy
Some of this cannot be bought back later
Settled at design
Six properties settled at design
Where the trust boundary sits; how one tenant, meaning one customer organisation on a shared system, is kept away from another. How an authorization decision gets made, and where; the shape of the data flow. Who holds the keys and how they are rotated; whether the audit trail can be quietly edited.
What late still buys
A late engagement still helps.
It buys patches, a web application firewall, a compensating control, and a ranked list of what to do next. It does not buy those six. The ones that arrived by accident are where we start.
The number to distrust
The hundred-times claim
A defect supposedly costs a hundred times more in production. The largest study, 171 commercial projects and 47,376 defect logs, found no significant rise in effort for issues fixed later. Almost every citation traces to one 1981 book whose data was never published.
How we build
We build the same way.
Security, performance and reliability are engineered in, not bolted on. Those six properties are settled in our own architecture work, while they are still cheap to change rather than expensive or impossible to undo later.
One measured authorization rebuild
Login platforms
BeforeFive separate systems
AfterOne
Auth-related support tickets, across five separate platforms
BeforeFive platforms
AfterDown 70 percent
License and development cost, five platforms
BeforeFive platforms
AfterDown 40 percent
Monthly active users, consolidated
BeforeFragmented estate
AfterThousands
Anonymised, as every case on this site is. The figures are the measured outcome of that engagement and nothing else was measured.
A multi-brand services group came to us with applications that had grown up separately. Five separate login platforms across a fragmented application ecosystem. Nobody could answer who had access to what from one place. We put one identity layer underneath the whole estate, using Keycloak with OAuth 2.0 and user federation, which means one login works across separate applications and one identity provider (Keycloak, an open-source one) answers for all of them, and moved every application onto it.
The finish line is somebody else's document
OWASP publishes the Application Security Verification Standard. Version 5.0.0 carries about 350 requirements across 17 chapters, grouped into three levels. Level 1 is the minimum worth considering. Level 2 is where the standard says most applications should be aiming. Level 3 is for the systems where the consequence of being wrong is severe.
Show data table
| Segment | Value (percent) | Share |
|---|---|---|
| Level 1, about 20 percent of requirements | 20 | 20% |
| Level 2 adds about 50 percent, reaching about 70 percent | 50 | 50% |
| Level 3, the remaining 30 percent | 30 | 30% |
You choose the level. The standard deliberately does not choose it for you, and neither do we. Each requirement has to be verifiable, and the verification has to end in a pass or a fail, so there is no partial credit and no room for our opinion to drift. The report states the scope, every requirement checked, every exception, and every requirement recorded as not applicable with the reason it was.
Two things the standard says that a supplier would rather you did not read. Running an automated tool over the code does not verify a level. Neither does testing from the outside with no source, no configuration and no documentation.
One more worth saying plainly. OWASP does not certify vendors, verifiers or software. A level is a property of your application after it has been verified against the list, and it never belongs to the firm that did the verifying.
The order the work runs in
Progress is reported weekly against the agreed list, so you watch the scope being used up instead of discovering it at the invoice.
- Threat model and scope, in writing
We model the ways your system can actually be reached and attacked, then agree the requirement list and the target level. What is out of scope is named.
- Review against the agreed list
With source, configuration and time with the people who built it, because the standard is explicit that the higher levels cannot be verified without them.
- Validate every finding against the running system
Anything a tool reported that does not reproduce is dropped before it reaches you. What survives is written in terms of your application.
- Rank by what is exploitable here
Ordered by what someone could actually do inside your own running system, not by a generic severity score attached to a category name.
- We write the fix
A pull request in your own repository, from the same team that found the problem, reviewed by a senior software engineer before it merges.
- The fix ships with a test that fails if the defect returns
The fix ships with a test, and the secure default moves into the scaffold so the next service starts with it already in place.
- Retest, then the report
The same team re-tests within the agreed scope. The report carries the scope, the passes, the exceptions and the requirements recorded as not applicable.
What a scanner actually catches on real code
A scan is not a review. On real repositories with known vulnerabilities, the best single tool in each language found well under half of them.
Show data table
| Item | Share of labelled vulnerabilities detected |
|---|---|
| CodeQL, C | 44.4% |
| Horusec, Java | 37.5% |
| DevSkim, Python | 30% |
CodeQL leads the C column at 44.4 percent. In the same study it found none of the labelled Python vulnerabilities. Several other widely deployed scanners also scored zero. Put the identical class of tool on a synthetic benchmark and it looks precise, which is exactly why a benchmark score tells you nothing about how a tool performs on your code.
So the review here is done by a software engineer, and you meet that person before anything is signed. Not a salesperson and not an account manager. Ask them how they would approach your system, where they would look first, and what they would do if they found nothing. If the call convinces you that our method is wrong for what you have built, that is a useful answer and it has cost you nothing.
Ask for the call with the software engineerOne firm's published starting prices
Of the nineteen pages ranking for this work, seventeen publish no price at all. One that does publishes its own starting prices, so here they are, and a starting price is where a job begins rather than where it lands.
Show data table
| Item | Published starting price |
|---|---|
| Secure code training | 5,000 USD |
| Mobile app test | 5,400 USD |
| External network test | 5,400 USD |
| Secure cloud review | 6,200 USD |
| Internal network test | 7,700 USD |
| Secure code review | 9,300 USD |
| Web and API test | 10,800 USD |
| AI systems test | 10,800 USD |
| IoT test | 10,800 USD |
| Hardware test | 12,400 USD |
| Threat modelling | 12,400 USD |
| Testing subscription | 21,400 USD |
The biggest lever on the number is the level you choose. Going from level 1 to level 2 takes an application from about 20 percent of the standard's requirements to about 70 percent of them, and that choice is yours rather than ours. After that it is five counts. How many applications and separately deployable services you run. How many endpoints and third-party integrations. How many distinct ways a person or a machine signs in and gets authorized. Whether money moves or bulk data can be exported. Whether source, configuration and the people who wrote it are available to us.
The industry sizes this work in days of a software engineer. One vendor sells credits worth eight hours each. Count those five things about your own system before any call, and the first conversation starts a long way in. We are not going to turn them into a number without asking, because nobody honestly can.
What we commit to in writing
The question that stalls this purchase is what happens if you find something serious. A serious finding is reproduced against your running system, brought to you the day it is confirmed rather than held back for the report, and fixed by us with a pull request into your repository. The same team re-tests within the agreed scope. If the repair changes the scope, you get a new estimate and you approve it first.
| Included in the engagement | Not included, and we would rather say so now |
|---|---|
| Included: the scope and the target level agreed in writing before work starts, with the requirements we are leaving out named rather than implied. | Not included, and we would rather say so nowNot included: a certificate of any kind, because OWASP does not certify vendors or software. |
| Weekly progress against that list. | Not included, and we would rather say so nowA compliance attestation, because we do not certify against frameworks ourselves. |
| Findings reproduced against your running system with tool noise removed. | Not included, and we would rather say so nowA price by return from the form, because a number before a scoping conversation would be a guess. |
| The fixes written by us and shipped with tests. | Not included, and we would rather say so nowWork outside the agreed list without a new estimate. |
| The retest within the agreed scope. | Not included, and we would rather say so now |
| The report with the scope, the passes, the exceptions and the requirements recorded as not applicable. | Not included, and we would rather say so now |
Your code and your intellectual property are yours from day one. Everything lives in your repositories and your cloud accounts. There is an NDA from day one, access runs through SSO and your own repository permissions, and the report belongs to you to send to whoever asked for it.
Send the counts and get the scoping questions
You get back the questions we still need answered and a call with the software engineer who would run the review.
What this will not find
Outside this work
Your people are outside it, so a convincing phone call to your finance team is not something this catches.
Your suppliers' own systems are outside it.
Physical access to your offices and hardware is outside it.
So is anything that only appears when a live adversary chains small weaknesses together over weeks.
Where to go instead
If your team can already run this and the gap is the threat model, buy the threat model and keep the rest of the budget.
where the threat model gets scoped before a line of code exists
If the question is about personal data, what you collect, how long you keep it, and what a regulator expects to see, that is different work
where personal data, consent, and regulator obligations are handled
If a procurement or compliance review is the trigger rather than a specific system, you should start on the enterprise page instead
No review is complete, and a firm that tells you otherwise is selling. This method reads your applications and the systems around them, against an agreed list. That leaves real risk on your side of the line.
We do not certify against compliance frameworks ourselves. We engineer systems that pass your auditors' requirements. And where the work shows that incremental hardening will do, we say so rather than proposing a rewrite you do not need.
Before you book the call
The six questions this category actually asks, in the words they were originally asked in.
Who does the work, and can I speak to them first?
How do I know this is not just a scanner?
What do I get, exactly, and can I see a sample first?
What happens to the report, and can I show it to a customer or an investor?
We already paid for a pentest. Does that change anything?
Do you need our source code, and what access do you need?
Send us the counts
How many applications and separately deployable services you run. How many endpoints and third-party integrations. How many distinct ways a person or a machine signs in. Whether money moves or bulk data can leave. Whether we can have source and configuration access. That is enough to begin.
What comes back is the questions we still need answered, and a call with the software engineer who would run the review. On that call we agree a target level, the scope we would work to, and what we would deliberately leave out of it. You get that in writing whether or not you hire us.
Two outcomes here are good. One is a scoped engagement with a written finish line. The other is you leaving with a scope your own team runs. If that is the honest answer for your system, it is what the call will say.
- A software engineer, not a salesperson
- Scope and target level agreed in writing
- The same team re-tests its own fixes