Skip to main content
友田 陽大
Application-layer security
セキュリティ
脆弱性診断
B2B SaaS
コスト最適化

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

An honest explanation, from the buyer's perspective, of the cost and market rate of web-app vulnerability assessment. Price bands by method (automated / manual / hybrid / penetration), guides by target (web, API, mobile, platform), the seven cost drivers that move an estimate, the trap of 'all-inclusive' estimates, the legitimate way to keep it cheap, and how to spot an assessment that's too cheap — summarized together with my own transparent pricing.

Published
Reading time
10 min read
Author
友田 陽大
Share

First, the number you probably most want to know. The cost of web-app vulnerability assessment is mostly decided by the assessment "method." The guides generally shown in the industry are as follows.

Assessment methodCommon market-rate guideWhat it does
Automated (tool) assessment200k–500k yenA scanner sweeps known vulnerabilities broadly and fast
Manual assessment500k–3M yenAn expert scrutinizes flaws tools can't find
Penetration testing1M–5M yenDemonstrate "can you actually break in" from the attacker's perspective

(Sources: market rates published by multiple assessment vendors such as GMO Cybersecurity by Ierae and UBsecure. It varies greatly by scale, scope, and vendor, so these are only guides.)

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's the most expensive 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.

Assessment targetBilling unitGuide
Web applicationScreen count / request count500k–3M yen manual
API (REST/GraphQL)Endpoint countFrom several hundred thousand yen by scale
Platform (OS/middleware/network)IP-address count50k–200k yen per IP
Smartphone appPer OS (iOS/Android)500k–3M yen / 1 OS
Cloud config (IAM/S3, etc.)Account / item countVaries by configuration

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.

Warning signThe realityThe question to spot it
An abnormally cheap "manual assessment"Effectively a relayed automated-scan report"Tell me concretely the items examined manually (authorization/business logic)"
A report with only a high detection countFalse positives aren't scrutinized"Do you scrutinize and truth-judge false positives?"
A fine report but irreproducibleNo reproduction steps / PoC"Does each finding come with reproduction steps and CVSS?"
Says "you'll be absolutely safe"Don't trust itConsider walking away

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).

PlanPricing guideWhat's included
SpotFrom ¥98,000Focused assessment of priority areas (authorization/RLS/injection) + a findings report
StandardFrom ¥280,000Whole-app assessment + fix design + re-assessment + debrief
AccompanimentFrom ¥680,000The above + CI-gate construction + continuous accompaniment for a set period

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 200k–500k / manual 500k–3M / penetration 1M–5M (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.

友田

友田 陽大

Developer of a METI Minister's Award–winning product. With TypeScript + Python + AWS, I deliver SaaS, industry DX, and production-grade generative AI (RAG) end to end — from requirements to infrastructure and operations — single-handedly.

The vulnerabilities in this article — is your app safe from them?

An expert audit of your Next.js × Supabase authorization & RLS

The IDOR, RLS misconfigurations, and tenant-boundary crossing covered here are vertical risks a library can't fix. I take it on as a security audit — from authorization review through fix design and implementation. You're welcome to visualize the current state with the free OSS first.

Available for both project-based (contract) and advisory engagements. Start with a free 30-minute consult.

Also worth reading