The Benware Standard
An open specification for measuring what anyone on the internet can see about a company's security. Published by the Benware Foundation — a nonprofit standards body.
"If a random person on the internet can see it, it counts."
An open specification for measuring what the internet can see about a company's security. 15 vectors, scored 0–100.
Read the Standard →The Benware Standard v1.0
External Security Scoring Specification — April 2026
What it is
The Benware Standard is an open specification for measuring what anyone on the internet can see about a company's security. 15 things to check. A score out of 100. Pass or fail.
Published by the Benware Foundation, a nonprofit. Free to read, reference, and cite. No registration, no paywall.
The problem
Most security checks are self-reported. A company fills out a questionnaire, a vendor issues a certificate, the certificate goes in a folder. Nobody checks what the company actually looks like from the outside.
Attackers only see the outside. Open ports. Leaked credentials. Forgotten subdomains. Exposed admin panels. That is where breaches start.
The Benware Standard measures that view. The same view an attacker has.
How it works, briefly
An accredited assessor scans a company's public infrastructure. Each of 15 security vectors gets a 0–3 rating. Those roll up into a score out of 100.
Score 75 or above with no critical failures and the company is eligible for certification, issued by the assessor. The certification is valid for six months.
Every deeper detail — the full vector list, scoring rubrics, certification rules, required evidence — lives on the other sub-tabs.
15 Security Vectors
Each vector is scored 0–3. Flat list — no domain grouping.
Description: Measures the number of discoverable subdomains via passive DNS enumeration and certificate transparency logs. A large attack surface increases risk of forgotten, unpatched, or misconfigured services.
Risk: Shadow IT, forgotten dev/staging environments, subdomain takeover.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | Fewer than 20 subdomains |
| 2 — Minor | 20–100 subdomains |
| 1 — Major | 100–300 subdomains |
| 0 — Critical | 300+ subdomains |
Evidence file: subdomains.txt
Remediation: Audit DNS records, decommission unused subdomains, implement subdomain inventory management.
Description: Identifies externally reachable network services beyond standard web ports. Unexpected open ports indicate misconfigured firewalls or exposed internal services.
Risk: Unauthorized access, lateral movement entry points, data exfiltration channels.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | Only ports 80 and 443 open |
| 2 — Minor | Few expected extra ports (e.g., mail) |
| 1 — Major | 10–30 unexpected open ports |
| 0 — Critical | 30+ open ports or high-risk services (RDP, SMB, DB) |
Evidence file: nmap.txt
Remediation: Close all non-essential ports, require VPN for SSH, segment public-facing services.
Description: Evaluates the quality of TLS implementation including protocol versions, certificate validity, cipher suites, and HSTS enforcement.
Risk: Man-in-the-middle attacks, data interception, credential theft.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | TLS 1.2+ only, HSTS enabled, valid certificate |
| 2 — Minor | TLS 1.2 present but no HSTS |
| 1 — Major | TLS 1.0/1.1 accepted or known vulnerability |
| 0 — Critical | SSLv3 enabled, expired certificate, or no HTTPS |
Evidence files: testssl.txt, headers.txt
Remediation: Disable TLS 1.0/1.1, enable HSTS with long max-age, renew certificates before expiry.
Description: Checks email authentication DNS records that prevent domain spoofing and phishing campaigns impersonating the organization.
Risk: Email spoofing, phishing, brand impersonation, BEC attacks.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | SPF + DKIM + DMARC with reject or quarantine policy |
| 2 — Minor | SPF + DMARC present but policy set to none |
| 1 — Major | SPF only, no DMARC |
| 0 — Critical | No email authentication records |
Evidence file: dns-security.txt
Remediation: Add SPF, configure DKIM signing, deploy DMARC with reject policy.
Description: Discovers publicly accessible cloud storage buckets (S3, GCS, Azure Blob) that may leak sensitive data.
Risk: Data breach, PII exposure, regulatory violations.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | No public buckets found |
| 2 — Minor | Bucket exists but access denied |
| 1 — Major | Public bucket with non-sensitive data |
| 0 — Critical | Public bucket with sensitive data exposed |
Evidence file: nuclei-exposure.json
Remediation: Set all buckets to private, enable bucket logging, implement access policies.
Description: Identifies publicly accessible API endpoints, documentation pages, and unauthenticated data routes.
Risk: Data leakage, unauthorized access, API abuse.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | No exposed API endpoints |
| 2 — Minor | APIs exist but behind authentication |
| 1 — Major | Swagger/API docs publicly accessible |
| 0 — Critical | Unauthenticated API returning data |
Evidence file: nuclei-exposure.json
Remediation: Remove public API docs, enforce authentication on all endpoints.
Description: Detects exposed source code repositories, accessible .git directories, and leaked secrets (API keys, passwords) in public code.
Risk: Credential theft, intellectual property loss, attack surface mapping.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | Clean — no exposed code or secrets |
| 2 — Minor | Public repo exists but no secrets found |
| 1 — Major | .git directory accessible on web server |
| 0 — Critical | API keys, passwords, or secrets publicly exposed |
Evidence file: nuclei-exposure.json
Remediation: Block .git access, rotate all exposed credentials, implement secret scanning in CI.
Description: Discovers publicly accessible administrative interfaces that could allow unauthorized system control.
Risk: Full system compromise, data manipulation, privilege escalation.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | No admin panels found |
| 2 — Minor | Admin panel behind MFA or VPN |
| 1 — Major | Public login page accessible |
| 0 — Critical | Default credentials work or no authentication |
Evidence file: nuclei-exposure.json
Remediation: Restrict admin panels to VPN, enforce MFA, remove default credentials.
Description: Checks whether corporate email addresses and credentials appear in known data breach databases.
Risk: Credential stuffing, account takeover, initial access for attackers.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | No credentials found in breach databases |
| 2 — Minor | Old breaches only (3+ years ago) |
| 1 — Major | Recent breaches involving regular employees |
| 0 — Critical | Executive or privileged account credentials breached |
Evidence file: ai-report.md
Remediation: Force password resets for affected accounts, enforce MFA organization-wide.
Description: Analyzes certificate transparency logs for wildcard certificate usage and potential rogue certificate issuance.
Risk: Unauthorized certificate issuance, expanded attack surface via wildcards.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | Narrow certificate scope, no wildcards |
| 2 — Minor | Some wildcard certificates |
| 1 — Major | Heavy wildcard usage |
| 0 — Critical | Rogue or unauthorized certificates detected |
Evidence file: subdomains.txt
Remediation: Monitor CT logs, reduce wildcard certificates, investigate unknown issuances.
Description: Evaluates external JavaScript dependencies loaded on the organization's web properties, checking for integrity controls and known malicious scripts.
Risk: Supply chain attacks, data skimming, cryptojacking.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | No risky third-party scripts, SRI present |
| 2 — Minor | Known vendors only, no SRI |
| 1 — Major | Unknown third-party scripts without SRI |
| 0 — Critical | Malicious or compromised scripts detected |
Evidence file: nuclei-vulns.json
Remediation: Audit all external scripts, implement Subresource Integrity (SRI), deploy Content Security Policy (CSP).
Description: Identifies publicly accessible AI or machine learning interfaces, chatbots, and model endpoints that may leak internal data or accept malicious input.
Risk: Data leakage via AI, prompt injection, unauthorized access to internal knowledge.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | No public AI tools found |
| 2 — Minor | AI tools exist behind authentication |
| 1 — Major | Public AI tool with guardrails in place |
| 0 — Critical | AI tool leaking internal data |
Evidence file: Manual notes
Remediation: Place AI tools behind authentication, implement input validation and output filtering.
Description: Detects known Common Vulnerabilities and Exposures (CVEs) in externally accessible software and services.
Risk: Exploitation of known vulnerabilities, remote code execution, data breach.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | No known CVEs detected |
| 2 — Minor | Low severity only (CVSS < 4.0) |
| 1 — Major | Medium severity (CVSS 4.0–7.0) |
| 0 — Critical | High/critical severity (CVSS 7.0+) with known exploits |
Evidence file: nuclei-cves.json
Remediation: Patch all known vulnerabilities, prioritize critical CVEs with public exploits.
Description: Checks for the presence of five critical HTTP security headers that protect against common web attacks.
Risk: Clickjacking, XSS, MIME sniffing, information leakage.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | All 5 headers present (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy) |
| 2 — Minor | 3–4 of 5 headers present |
| 1 — Major | Only 1–2 headers present |
| 0 — Critical | Zero security headers |
Evidence file: headers.txt
Remediation: Add Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers.
Description: Determines whether a Web Application Firewall is protecting the organization's web properties and whether the origin server is properly shielded.
Risk: Direct origin server attacks, DDoS vulnerability, unfiltered malicious traffic.
Scoring
| Score | Criteria |
|---|---|
| 3 — Secure | WAF active and properly configured |
| 2 — Minor | CDN present but WAF status unclear |
| 1 — Major | No WAF but no direct origin exposure |
| 0 — Critical | No WAF and origin server directly exposed |
Evidence file: headers.txt
Remediation: Deploy a WAF (Cloudflare, AWS WAF, etc.), ensure origin IP is not publicly resolvable.
Scoring Methodology
Formula
Benware Score = (Sum of Tested Vector Scores) ÷ (Tested Vectors × 3) × 100
Coverage Penalty
If fewer than 60% of vectors are tested (fewer than 9 of 15), the raw score is multiplied by the coverage ratio:
Adjusted Score = Raw Score × (Tested Vectors ÷ 15)
"Not tested" does not mean "secure." Skipping vectors cannot inflate a score.
Auto-Fail Rule
Any vector scored 0 = automatic certification failure, regardless of overall score.
Examples
15 vectors tested. Sum = 37 out of 45 possible.
Raw score: 37 ÷ 45 × 100 = 82
But one vector scored 0.
12 vectors tested (80% coverage — above 60% threshold). Sum = 32 out of 36 possible.
Raw score: 32 ÷ 36 × 100 = 89
No critical findings (no zeros).
2 vectors tested (13% coverage — below 60% threshold). Sum = 6 out of 6 possible.
Raw score: 6 ÷ 6 × 100 = 100
Coverage penalty: 100 × (2 ÷ 15) = 100 × 0.133 = 13
Grade Scale
| Grade | Score Range | Certification |
|---|---|---|
| A | 90 – 100 | Pass |
| B | 75 – 89 | Pass |
| C | 60 – 74 | Fail |
| D | 40 – 59 | Fail |
| F | 0 – 39 | Fail |
Certification
Pass Requirements
To achieve Benware Certification, an organization must meet both conditions:
| Condition | Requirement |
|---|---|
| Overall Score | 75 or higher |
| Critical Findings | Zero vectors scored 0 |
Auto-Fail
Any single vector scored 0 results in automatic certification failure, even if the overall score exceeds 75.
The critical finding must be remediated and the vector re-tested before certification can be issued.
Validity
| Parameter | Value |
|---|---|
| Certification validity period | 6 months from assessment date |
| Renewal | Full re-assessment required after expiry |
How certification works
Scan
An accredited assessor runs the methodology against your public infrastructure. No installation. No access granted.
Score
Each of the 15 vectors gets a 0–3 rating. Those roll up into a score out of 100. Any vector scoring 0 auto-fails.
Certify
Score 75 or above with no zeros and you get a certification valid for six months.
Grade Scale
| Grade | Score | Meaning |
|---|---|---|
| A | 90 – 100 | Locked down tight |
| B | 75 – 89 | Solid, certifiable |
| C | 60 – 74 | Some gaps to fix |
| D | 40 – 59 | Serious problems |
| F | 0 – 39 | Fix this now |
Accredited Assessors
Only assessors accredited by the Benware Foundation may issue official Benware certifications. Self-assessments may use the scoring framework but cannot produce a certification.
Certificate Contents
Every issued certificate includes:
| Field | Description |
|---|---|
| Company Name | Legal entity assessed |
| Primary Domain | Root domain scope of assessment |
| Score | Numeric score (0–100) |
| Grade | Letter grade (A through F) |
| Assessment Date | Date the scan was performed |
| Expiry Date | 6 months from assessment date |
| Scan ID | Unique identifier for the assessment |
Evidence Requirements
Core Principle
Every score must have a source file. No evidence means the vector is marked not_tested, not scored.
Evidence Rules
| Rule | Description |
|---|---|
| Source Required | Every score (0, 1, 2, or 3) must reference a specific evidence file |
| No Evidence = Not Tested | A vector without evidence cannot receive a score |
| Critical Verification | Scores of 0 or 1 require manual verification before final report |
| Retention Period | Evidence files must be retained for 12 months |
| Reproducibility | Results must be reproducible using the same tools and methodology |
Evidence File Map
| File | Vectors |
|---|---|
subdomains.txt | BW-V001, BW-V010 |
nmap.txt | BW-V002 |
testssl.txt | BW-V003 |
headers.txt | BW-V003, BW-V014, BW-V015 |
dns-security.txt | BW-V004 |
nuclei-exposure.json | BW-V005, BW-V006, BW-V007, BW-V008 |
nuclei-vulns.json | BW-V011 |
nuclei-cves.json | BW-V013 |
ai-report.md | BW-V009 |
| Manual notes | BW-V012 |
About the Benware Foundation
A neutral standards body for external security measurement.
Mission
The Benware Foundation exists to define, maintain, and improve the Benware Standard — an open specification for measuring what the internet can see about an organization's security posture.
The standard is free to read and reference. The Foundation does not perform assessments. It sets the rules.
Benware Foundation
Owns and publishes the Benware Standard. Responsible for versioning, amendment processes, and accrediting assessors who can issue official certifications.
The Foundation operates as a neutral body. It does not sell assessments or compete with assessors.
MEOP Inc.
The first accredited assessor under the Benware Standard. MEOP runs the actual security assessments, delivers reports, and issues certifications to organizations that pass.
Same model as PCI DSS and SOC 2: one body writes the standard, separate firms do the assessments.
Why Separate?
The entity that defines the rules should not be the same entity that profits from applying them. Separation creates accountability:
| Foundation | Assessors |
|---|---|
| Writes the standard | Run the scans |
| Versions and publishes updates | Deliver reports to clients |
| Accredits assessors | Issue certifications |
| Reviews amendment proposals | Provide remediation guidance |
| No revenue from assessments | Charge clients for assessment services |
Governance
The Benware Standard follows a public amendment process:
| Step | Description |
|---|---|
| 1. Proposal | Anyone can submit a proposed change to the standard |
| 2. Review | The Foundation reviews the proposal for technical merit and scope |
| 3. Public Comment | Proposed changes are published for community feedback |
| 4. Decision | The Foundation accepts, modifies, or rejects the proposal |
| 5. Publication | Accepted changes are incorporated into the next version |
All amendments are versioned and documented. Breaking changes require a major version increment.
Why the Foundation exists
External security measurement is broken. Companies with SOC 2 badges get breached through an exposed S3 bucket. Insurance questionnaires ask questions nobody verifies. Pen tests cost tens of thousands of dollars and end up in a folder nobody reads.
Security theater. Paperwork mistaken for protection.
The outside of a company is visible to anyone with a browser. There should be one honest way to measure it. One score that means the same thing everywhere. Free to read, permanently versioned, not gated behind a vendor.
That is what the Benware Standard is. The Foundation published v1.0 to start. Whether one assessor runs it or a hundred do, the standard stays the same. The rules don't bend for customers.
Governing Board
The Foundation is governed by a board of three directors who approve amendments to the standard and oversee the accreditation program. Director identities are recorded with the South Carolina Secretary of State and available in public corporate filings.
Registered as a South Carolina 501(c)(3) nonprofit corporation. Filing ID 260226-1336587.
Version History
| Version | Date | Notes |
|---|---|---|
| 1.0 | April 2026 | Initial publication. 15 vectors, 0–3 scoring, 75+ certification threshold. |
Breaking changes bump the major version. Additive or clarifying changes bump the minor version.
Citation
Get in touch
Talk to MEOP about an assessment, apply to become an accredited assessor, or reach the Foundation with questions about the standard.
Become an accredited assessor
Security firms can get accredited to run official Benware assessments and issue certifications under the standard. Assessors set their own pricing. The Foundation reviews applications and takes no share of assessment fees.
Launching soon. Email to get on the early access list.
Common questions
No. Everything is external. Assessors only look at what's publicly visible on the internet. No credentials, no agents, no access needed.
Usually 1-3 business days depending on how big your public infrastructure is.
You get a findings report showing exactly what to fix, ordered by severity. Re-assessment terms are set by the accredited assessor.
The standard itself is free to read and reference. Getting officially certified requires a paid assessment from an accredited assessor.
Pen tests try to break in. Benware measures what's visible from the outside without exploiting anything. Faster, cheaper, and gives you a score you can compare across companies. They work well together.
The Benware Foundation is a 501(c)(3) nonprofit that owns and maintains the standard. Assessments are done by accredited assessors (separate companies). The Foundation writes the rules but doesn't sell assessments.