Vezraa Methodology — How Scores Are Calculated

Scoring Methodology

Vezraa's scoring system is designed to be transparent, explainable, and fair across different types of applications. The overall production readiness score is a weighted composite of all applicable categories, with each category scored independently before being combined into the final score.

Base Score and Deductions

Each category starts with a base score of 100 points. Finding deductions are applied based on severity: CRITICAL findings deduct 25 points, HIGH findings deduct 15 points, MEDIUM findings deduct 8 points, and LOW findings deduct 3 points. These deduction values were calibrated against real-world breach data to ensure that the final score accurately reflects actual risk. A site with a single critical vulnerability cannot score above 75 even if everything else is perfect, reflecting the reality that one critical gap can compromise an entire application.

Score Capping

Vezraa imposes a score ceiling when P0 (Critical) findings are present. If any P0 check fails, the overall score cannot exceed 70 regardless of passing checks in other categories. This ensures that critical security gaps cannot be hidden by good performance in less important areas. Similarly, if multiple P0 failures exist, each additional P0 failure further reduces the effective ceiling.

Category Weighting

Not all categories contribute equally to the final score. Category weights reflect real-world impact and are based on analysis of breach data, industry standards, and security research. Security carries the highest weight at 25% because it represents the most direct risk to users and data. Performance (15%) and Payments (10%) follow because they directly affect user experience and revenue. SEO (10%), Observability (8%), AI Safety (8%), Accessibility (7%), Email (6%), Legal (6%), Infrastructure (5%), and the remaining categories at lower weights round out the scoring model. Categories that don't apply to a given application — for example, AI Safety for a static brochure site, or Payments for an application that doesn't process transactions — are excluded from the weighted average, preventing artificial score inflation or deflation.

Category Weights at a Glance

• Security — 25% (headers, secrets, TLS, CORS, auth)
• Performance — 15% (Core Web Vitals, caching, CDN)
• Payments — 10% (webhook verification, key exposure)
• SEO — 10% (meta tags, OG, canonical, sitemap)
• Observability — 8% (error tracking, monitoring, PII in logs)
• AI Safety — 8% (prompt injection, rate limits, cost controls)
• Accessibility — 7% (WCAG compliance, alt text, keyboard nav)
• Email — 6% (SPF, DKIM, DMARC, MX records)
• Legal — 6% (privacy policy, terms, cookie consent)
• Infrastructure — 5% (debug mode, console.log, mixed content)
• Breach — Informational only (domain/credential breach history)

Severity Classification

Severity classification follows a structured assessment based on CVSS 3.1 scoring methodology adapted for automated scanning. Each finding is evaluated across three dimensions: exploitability (how easy is it to exploit this vulnerability), impact (what is the worst-case outcome of exploitation), and detectability (how likely is it that exploitation would be detected). These dimensions combine to produce the final severity rating.

• CRITICAL — CVSS 9.0–10.0. Immediate exploitation possible with significant impact. Examples: exposed database credentials in client-side JavaScript, unverified payment webhooks, missing authentication on administrative endpoints, service role keys exposed in public code.
• HIGH — CVSS 7.0–8.9. Exploitable with moderate effort, significant impact. Examples: missing CSP allowing XSS, CORS allowing any origin, weak password policy, verbose error messages exposing stack traces.
• MEDIUM — CVSS 4.0–6.9. Exploitable under specific conditions, moderate impact. Examples: missing HSTS header, no rate limiting on login endpoints, mixed content warnings, missing X-Frame-Options.
• LOW — CVSS 0.1–3.9. Low-risk informational findings. Examples: missing Open Graph tags, no sitemap.xml, minor accessibility violations, missing security.txt.

False Positive Handling

Vezraa employs multiple strategies to minimize false positives. Each check is designed with specific pass/fail criteria that are tested and validated against real applications. The verification phase of the VAPF methodology independently confirms exploitable findings before they are reported. For passive scanning checks, Vezraa uses heuristic confirmation — for example, when detecting exposed API keys, the scanner verifies that the detected string matches the format of an actual API key for the identified provider, not just a variable name containing the word "key." Users can dismiss individual findings with a reason, and the engine suppression system learns from these dismissals to reduce false positives in future scans. Continuous improvement is driven by a feedback loop where user-reported false positives are reviewed and the check logic is refined.

Industry Standards Alignment

Vezraa's methodology aligns with multiple industry standards and frameworks. The security category maps to the OWASP Top 10 (2021) and OWASP ASVS (Application Security Verification Standard). Severity classification follows CVSS 3.1 scoring guidelines. Accessibility checks are based on WCAG 2.1 AA standards. Email security checks validate compliance with email authentication standards (SPF, DKIM, DMARC). The AI Safety category incorporates the OWASP Top 10 for LLM Applications. Legal compliance checks reference GDPR, CCPA, and DPDP Act requirements. This multi-framework alignment means a Vezraa scan provides coverage assessment against the standards your organization likely already targets.