The cost and market rate of web-app vulnerability assessment [2026 edition] — price bands by method, how to read estimates, how to choose without failing

First, the number you probably most want to know. The cost of web-app vulnerability assessment is mostly decided by the assessment "method." The price ranges assessment vendors publish are as follows.

(Sources: for automated assessment, GMO Cybersecurity by Ierae lists tool assessment at "free to a few hundred thousand yen" and UBsecure at "from a few tens of thousands of yen per month"; for manual assessment, UBsecure lists "500k–3M yen"; for penetration testing, GMO quotes per engagement. It varies greatly by scale, scope, and vendor, so these are only guides.)

Note: the figures are the ranges each vendor published as of October 2026, and they change over time.

But deciding your order on these numbers alone will fail. Because vulnerability assessment is an extremely asymmetric purchase whose contents change dramatically by "what, how far, and how it's examined." Even the same "500k-yen web assessment" protects a completely different range between one that just relays an automated-scan report and one that manually verifies even the authorization logic.

With the goal of letting the buyer come to judge an estimate's validity themselves, this article explains, as honestly as possible, the structure of market rates, the cost drivers, how to read an estimate, the legitimate way to keep it cheap, and how to spot an assessment that's too cheap. I'll also transparently disclose my own pricing, with the rationale.

1. Pricing is decided by "method" — automated, manual, hybrid, penetration

The true nature of the price difference is "how much human time is used." Vulnerability assessment gets more expensive as the ratio of human effort rises.

1-1. Automated (tool) assessment — cheap but only "horizontal"

A method that mechanically sweeps known vulnerability patterns with scanners (DAST/SAST). Its strength is being broad, fast, and cheap. It comprehensively crushes "flaws of the same structure in any app (horizontal holes)" like injection, missing security headers, and known vulnerable dependencies.

The weakness is clear. A tool doesn't know your business rules, so it can't judge the validity of authorization (vertical risk) like "who may see this invoice." Even if an automated-assessment report is perfect, that only means "no known patterns," not "safe."

Important: most automated assessment you can do yourself with free official tools. Before paying, the most cost-efficient first step is to sweep the horizontal holes with how to do web-app vulnerability assessment (hands-on with the OWASP official methodology).

1-2. Manual assessment — expensive but can see "vertical"

An expert understands the system's spec and business logic and manually scrutinizes flaws tools can't find. Its value is stepping into the validity of the design — broken authorization (IDOR), privilege escalation, business-logic abuse (tampering with quantity or price, stepping out of state transitions).

Of the 12 categories of the OWASP Web Security Testing Guide, 4.5 Authorization Testing and 4.10 Business Logic Testing are reachable almost only manually. The manual-assessment fee is the expert's time spent here itself.

1-3. Hybrid assessment — the realistic optimum

A method combining "automated comprehensiveness" with "manual depth," the recent mainstream. Since it sweeps horizontal with automation and concentrates the freed effort on scrutinizing vertical, it's easy to balance cost and accuracy. For a SaaS handling personal data or billing, this form is the baseline first.

1-4. Penetration testing — demonstrating "can you break in"

Rather than enumerating vulnerabilities (assessment), it's an attacker's-perspective activity that demonstrates whether intrusion/privilege takeover actually succeeds in a specific scenario. It takes the most human time, is usually quoted per engagement, and has a different purpose. "Want to comprehensively cover known holes" → assessment; "want to verify whether this attack really gets through" → penetration — use them separately.

2. Market rates by target — the unit changes by what you examine

After "method," what matters most is "target." Depending on the assessment target, the unit of counting the fee changes.

What matters here is "whether you can explain your app's scale in billing units." Organizing "how many screens, how many auth flows, how many API endpoints, how many IPs to assess" before ordering drastically reduces estimate variance. Conversely, order "all-inclusive" while leaving this ambiguous, and you fall into the trap described below.

3. The seven cost drivers that move an estimate

Even for the same target, an estimate varies several-fold by the following seven factors. If you can ask about these seven, you can judge an estimate's validity yourself.

1. Scale: screen count, request count, endpoint count, IP count. The biggest driver.
2. Method ratio: is automation central, or how high is the manual ratio.
3. Whether authentication is needed: assessing post-login features requires credentials, multiple roles, and MFA-bypass procedures, raising effort.
4. Whether re-assessment (retry) is included: does it include detection → fix → confirming "it's fixed" with re-assessment. An estimate that doesn't include this looks cheap.
5. Report quality: the concreteness of reproduction steps, impact (CVSS), and fixes. Just a "detection list," or written down to "how to fix it."
6. False-positive scrutiny: does it manually judge the truth of automated detections and drop them. Relaying raw scan results is cheap but low-value.
7. After-support / SLA: does it accompany you through a debrief, fix consultation, and recurrence prevention (CI integration).

A pre-order checklist (copy-paste OK): when you receive an estimate, always throw these questions. "① What defines the scope (screens/API/IP count) ② What's the automated-to-manual ratio ③ Are post-auth features in scope ④ Is re-assessment included ⑤ Does the report have reproduction steps and fixes ⑥ Do you scrutinize false positives ⑦ Is there follow-up after fixing?" A vendor who can't answer the seven immediately has an ambiguous scope.

4. The trap of "all-inclusive" estimates — the cheaper-looking the estimate, the more you decompose it

The most common failure is comparing a rounded estimate like "web assessment, all-inclusive, ◯◯ yen" as-is. All-inclusive notation hides which of the seven drivers above are included and which are excluded.

Items typically "not included":

• Re-assessment (the pattern where confirming the fix is a separate fee)
• Post-auth features (only pre-login screens were examined)
• False-positive scrutiny (raw scan results are counted as "detections" as-is)
• Fixes ("there's a vulnerability" but no how-to-fix written)

The countermeasure is simple. Always request an itemized breakdown of an all-inclusive estimate, and line up multiple vendors with the same scope definition to compare. Comparing amounts of estimates with mismatched scopes is meaningless.

5. The legitimate way to keep costs down smartly (without dropping quality)

"Want it cheaper" and "cut corners" are different. There are three legitimate ways to lower cost without dropping quality.

5-1. Crush horizontal yourself with free tools → concentrate manual on vertical only

The biggest saving is to use human time only on what machines can't do. SCA (dependencies), SAST (static), secret scanning, and DAST (ZAP) can be brought in-house with free official tools. Sweep the horizontal holes with these, and manual assessment can concentrate on the vertical risks of authorization and business logic, lowering effort = cost. The concrete how-to is summarized in the hands-on OWASP-official-methodology article, and how to choose tools in the vulnerability-scanner comparison article.

5-2. Correctly "narrow" the scope (rather than cutting carelessly)

Examining all features uniformly deeply is expensive. Thick manual on high-risk areas (authentication, payments, personal data, admin features), light automation on low-risk areas — adding such emphasis widens the protected range on the same budget. "Thick on the important parts" over "thin on everything" is the iron rule.

5-3. Integrate into CI and prevent regression for free

A one-time assessment goes stale with next week's deploy. Integrate SAST/SCA/secret scanning into CI to prevent regression, and you can keep stopping the re-introduction of the same holes for free. A continuous free gate + pinpoint manual is, in total, cheaper and safer than an expensive once-a-year assessment.

6. The danger of "an assessment that's too cheap" — how to spot it

An assessment extremely cheaper than the market rate usually has a reason. Here are the points to spot before ordering.

The last item is the most important. Don't trust a counterpart who says "take this / introduce this and you'll be absolutely safe." What an assessment can do is systematically crush known serious risks, leave a mechanism to prevent recurrence, and honestly state the remaining risks. An assessment that sells "a guarantee of safety" breeds the worst result — complacency. I detail that boundary in what does a security audit look at.

7. My pricing — disclosed transparently

It's not fair to only talk about market rates while hiding my own pricing, so I'll disclose it. The pricing for the security audits I provide for Next.js × Supabase apps is as follows (excl. tax, varies by scale).

For small apps built with AI there is also a pre-launch light review (from ¥29,800) that only judges whether any critical holes exist. If you can't read the code and first need to decide whether to ask for a review at all, start with does the app you built with AI need a human security review?

Web apps and SaaS products built on stacks other than Next.js × Supabase are covered too. What is and isn't examined, and each plan's price and turnaround, are laid out on the web application security audit (scope and pricing) page.

Why this price band holds. The reason is my style itself. Because I do design, implementation, and verification end-to-end with one-person × generative AI (Claude Code), there are no middleman margins of multi-layered subcontracting and no communication cost from division of labor. I mechanically crush the horizontal holes with my own free OSS Aegis, and concentrate human time on the vertical risks machines can't judge. This is the structure that makes "fast, cheap, production quality" hold simultaneously.

This approach is backed by experience actually designing and implementing, alone, an METI-Minister's-Award-winning B2B SaaS and a payments platform that achieved 0 double charges in production. It's not "cheap and nasty," but cheapness as a result of structurally cutting waste.

Summary — see through to the "contents" behind the numbers

1. Pricing is decided by method: automated free to a few hundred thousand yen / manual 500k–3M yen / penetration quoted per engagement (vendors' published ranges as of October 2026; guides only).
2. The unit changes by target: screen count, endpoint count, IP count, OS count. Count your scale before ordering.
3. The seven cost drivers vary an estimate several-fold. Always decompose "all-inclusive" and compare on the same terms.
4. Smart saving is three things: crush horizontal yourself with free tools / add emphasis to the scope / prevent regression for free in CI.
5. Spot an assessment that's too cheap: the contents of the manual, false-positive scrutiny, reproduction steps, whether re-assessment is included. Avoid a counterpart who sells "absolutely safe."

Vulnerability assessment is a purchase chosen not by the size of the amount but by "what is protected and what remains." With this article's checklist in hand, come to see through an estimate's contents with your own eyes. From a scope consultation — tell me your situation first, and I'll design the most waste-free allocation for you together.