---
description: Evidence-driven Pentester coverage standard for OWASP Top 10:2025, WSTG, ASVS, APIs, LLM, mobile, native code, and target-specific attack techniques
agents: [pentester]
task_types: [security-review, coverage-planning, adversarial-testing]
triggers: [pentester activation, app target, comprehensive security review]
---

# Pentester Coverage Standard

Load after the review contract and before selecting probes. This document defines what “complete” means inside a declared, authorized local scope. It never means “impossible to hack” or “free from every vulnerability.”

## Assurance truth

- A scanner run is not coverage.
- Absence of findings is not proof that a surface was tested.
- A category is covered only when its entry records a target, method, and concrete evidence.
- `not_applicable` requires a causal reason tied to inspected architecture or code.
- Missing prerequisites, credentials, roles, runtime, browser, fixtures, or tools are `not_tested`, never `passed`.
- “Complete in the declared scope” is allowed only when every mandatory row exists and none is `not_tested` or malformed. Reports must still state that no finite review guarantees absolute security.

## Pinned standards baseline

Use versioned references so a future taxonomy change cannot silently rewrite an old report:

| Standard | Pinned baseline | Role |
|---|---|---|
| OWASP Top 10 | **2025** | Ten mandatory awareness-risk rows for every `app_target` |
| OWASP WSTG | **v4.2 stable** | Web testing families and versioned scenario IDs (`WSTG-v42-*`) |
| OWASP ASVS | **5.0.0** | Verifiable application controls; reference exact IDs as `v5.0.0-<id>` |
| OWASP API Security Top 10 | **2023** | Mandatory overlay when an API, GraphQL, RPC, or service boundary exists |
| OWASP Top 10 for LLM Applications | **2025** | Mandatory overlay for LLM/RAG/agentic surfaces |
| OWASP MASVS/MASTG | current version recorded at run time | Mandatory overlay for mobile targets |
| MITRE CWE Top 25 | **2025** | Implementation-weakness lens, including memory safety for native code |

If the user allows read-only web research, check official project pages for newer stable releases before testing. Record the consulted URL, version, and date in `review_contract.standards`. Do not replace a stable baseline with WSTG `latest` development content; use `latest` only to identify and disclose possible gaps. Web access never authorizes probing a public target.

## Review depth

Set `review_contract.review_depth`. It follows the resolved `scope_target` by default — `project` is `comprehensive`; `feature`, `simple_plan`, `paths` and `routes` are `focused` unless the caller asks for complete coverage:

- `focused`: QA supplied a concrete sensitive surface or finding, or the caller scoped the run to one feature, simple plan, path set or route set. Test that execution chain deeply and still create all ten OWASP Top 10 rows, marking unrelated categories with evidence-backed `not_applicable` or explicit `not_tested`.
- `comprehensive`: direct full-audit request or broad app review. Map every reachable interface, identity, trust boundary, parser, data store, dependency, deployment boundary, and applicable conditional profile. This is the default when the user asks for complete/full coverage.

Set `review_contract.assurance_level`:

- `ASVS-L1`: local/internal or low-assurance application without sensitive data.
- `ASVS-L2`: default for consumer, authenticated, multi-user, or sensitive-data applications.
- `ASVS-L3`: only for explicitly high-assurance systems such as finance, health, government, safety-critical, or irreversible high-value actions.

Do not infer a lower level merely to finish faster. Record every applicable ASVS requirement tested; never invent requirement IDs. Use the official ASVS 5.0.0 CSV/JSON when exact mapping is needed.

## Coverage entry contract

Write `coverage[]` in the authoritative findings artifact. One test may support multiple controls, but each control retains its own entry.

```json
{
  "control_id": "A01:2025",
  "standard": "OWASP Top 10:2025",
  "title": "Broken Access Control",
  "status": "passed | finding | not_applicable | not_tested",
  "tested_paths": ["src/auth/authorization.ts"],
  "tested_endpoints": [
    {
      "method": "PATCH",
      "url": "http://127.0.0.1:3000/api/orders/:id",
      "roles": ["owner", "other-user"],
      "status": "passed",
      "evidence": ["tests/security/idor.test.ts:42"]
    }
  ],
  "evidence": ["ownership predicate traced from route to data query"],
  "finding_ids": [],
  "not_applicable_reason": null,
  "not_tested_reason": null,
  "limitations": []
}
```

Rules:

- `passed` needs negative or adversarial evidence, not only a happy-path unit test.
- `finding` needs at least one valid `finding_id`.
- `not_applicable` needs `not_applicable_reason` naming the absent actor/data/entry point.
- `not_tested` needs `not_tested_reason` and appears prominently as incomplete coverage.
- `tested_paths` use real workspace paths. Prefer a concrete file; a directory is allowed for a documented scanner scope only.
- `tested_endpoints` store method plus origin/path. Strip credentials, fragments, query strings, tokens, personal data, and secret values before persistence.

## Mandatory OWASP Top 10:2025 gate

Every `app_target` artifact must contain exactly one roll-up row for each ID below. Detailed ASVS/WSTG rows may sit beneath them.

| ID | Risk | Minimum adversarial obligation |
|---|---|---|
| `A01:2025` | Broken Access Control | Horizontal/vertical authorization, ownership/tenant isolation, method and object-property authorization, forced browsing, path/file authorization, default deny |
| `A02:2025` | Security Misconfiguration | Debug/admin exposure, unsafe defaults, headers/CORS, methods, cloud/IaC/container permissions, directory listing, backup/source-map/config exposure |
| `A03:2025` | Software Supply Chain Failures | Direct/transitive dependencies, lockfile integrity, install scripts, CI Actions, artifact provenance/signing, vulnerable or abandoned components |
| `A04:2025` | Cryptographic Failures | TLS, password hashing, key/secret lifecycle, randomness/nonces, data at rest/in transit, token signing and algorithm enforcement |
| `A05:2025` | Injection | Contextual XSS plus SQL/NoSQL/ORM, OS command, code/template, LDAP/XPath/XML/XXE, header/CRLF, CSV, prototype pollution, unsafe deserialization and parser confusion |
| `A06:2025` | Insecure Design | Threat boundaries, business-rule bypass, workflow skipping, race/TOCTOU, anti-automation, abuse cases, resource exhaustion, unsafe fail-open design |
| `A07:2025` | Authentication Failures | Enumeration, brute force/credential stuffing defenses, MFA/reset/recovery, default credentials, alternate channels, OAuth/OIDC/PKCE, session establishment |
| `A08:2025` | Software or Data Integrity Failures | Untrusted updates/artifacts/data, insecure deserialization, unsigned state, mass assignment/integrity fields, webhook/message authenticity, CI/CD trust |
| `A09:2025` | Security Logging and Alerting Failures | Security-event coverage, outcome/actor/source, secret/PII redaction, tamper resistance, actionable alert path, clock/correlation integrity |
| `A10:2025` | Mishandling of Exceptional Conditions | Fail-closed behavior, error/stack leakage, partial transaction rollback, timeout/cancellation, retry storms, resource cleanup, malformed/unexpected state |

The Top 10 is an awareness list, not a testing methodology. Passing these ten roll-ups therefore also requires the WSTG family gate below for web targets and the applicable ASVS requirements for the declared assurance level.

For `review_depth: comprehensive`, any `not_tested` row keeps the Pentester handoff blocked until the prerequisite is supplied or the user explicitly narrows/accepts the limitation. A focused review may return an incomplete-coverage warning, but never a complete claim.

## WSTG family gate for web targets

Create at least one coverage entry for every applicable family. Use stable versioned scenario IDs where a concrete WSTG test maps to the evidence.

| Family | Required scope |
|---|---|
| `WSTG-INFO` | Architecture, entry points, routes, assets, versions, metadata and information leakage |
| `WSTG-CONF` | Platform/deployment config, methods, permissions, admin interfaces, storage, headers, backup/unreferenced files |
| `WSTG-IDNT` | Roles, registration, provisioning, username/account policy and enumeration |
| `WSTG-ATHN` | Credentials, bypass, lockout, alternate channels, reset, MFA |
| `WSTG-ATHZ` | Traversal, authorization bypass, privilege escalation, IDOR/BOLA, OAuth client/server boundaries |
| `WSTG-SESS` | Cookies, fixation, CSRF, logout, expiry, hijacking, JWT and concurrent sessions |
| `WSTG-INPV` | All interpreters/parsers: XSS, SQL/NoSQL, command/code/template, XML/XXE, request smuggling, host/header, SSRF, mass assignment, CSV and prototype pollution |
| `WSTG-ERRH` | Improper error handling, stack traces and exceptional-state behavior |
| `WSTG-CRYP` | TLS, primitives, encrypted channels and oracle behavior |
| `WSTG-BUSL` | Forged requests, workflow bypass, races, limits, misuse, upload and payment/business invariants |
| `WSTG-CLNT` | DOM/client injection, redirects, CORS, clickjacking, WebSocket, messaging, browser storage and third-party resources |
| `WSTG-APIT` | API reconnaissance, object/function/property authorization, data exposure, GraphQL and service-specific boundaries |

## Conditional overlays

### API, GraphQL, RPC, or service interface

Add all ten OWASP API Security Top 10:2023 rows:

1. `API1:2023` Broken Object Level Authorization
2. `API2:2023` Broken Authentication
3. `API3:2023` Broken Object Property Level Authorization
4. `API4:2023` Unrestricted Resource Consumption
5. `API5:2023` Broken Function Level Authorization
6. `API6:2023` Unrestricted Access to Sensitive Business Flows
7. `API7:2023` Server Side Request Forgery
8. `API8:2023` Security Misconfiguration
9. `API9:2023` Improper Inventory Management
10. `API10:2023` Unsafe Consumption of APIs

Inventory REST versions, GraphQL operations, WebSocket messages, gRPC/RPC methods, webhooks, callbacks, background consumers, undocumented/deprecated endpoints, and machine identities. Test object, property, function, and tenant authorization independently.

### LLM, RAG, or agentic application

Load `llm-supplychain.md` and add all OWASP LLM Top 10:2025 rows: LLM01 Prompt Injection; LLM02 Sensitive Information Disclosure; LLM03 Supply Chain; LLM04 Data and Model Poisoning; LLM05 Improper Output Handling; LLM06 Excessive Agency; LLM07 System Prompt Leakage; LLM08 Vector and Embedding Weaknesses; LLM09 Misinformation where it can cause a security decision or unsafe action; LLM10 Unbounded Consumption.

### Mobile

Use the run-time-recorded OWASP MASVS version and MASTG test IDs. Cover storage, cryptography, authentication, network, platform interaction, code quality, resilience, and privacy. A web-only review cannot mark a native mobile client `passed`.

### Native, desktop, CLI, host service, cloud, container, or IaC

Add relevant profiles rather than forcing browser tests:

- native/memory safety: bounds, lifetime/use-after-free, integer overflow, unsafe FFI, parsers, IPC, code loading and update signing;
- desktop/CLI: command and argument injection, file/URI/protocol handlers, credential storage, temp files/symlinks, update integrity and local privilege boundaries;
- host/service: network binding, TLS, authentication, least privilege, file permissions, unsafe defaults, deserialization, resource limits, audit trail and process isolation;
- cloud/container/IaC: public exposure, IAM/default deny, secrets, metadata access, privileged/root containers, capabilities, mounts, image provenance, network policy and storage policy.

Use CWE Top 25:2025 and stack/vendor primary documentation to choose concrete controls. Mark memory-safety rows `not_applicable` only after proving the reviewed execution path uses a memory-safe runtime and has no native/unsafe boundary.

## Attack-technique inventory

The threat-surface map must consider these families before selecting playbooks:

1. Reconnaissance, version/metadata leakage, hidden/admin/debug/backup assets, route and asset inventory.
2. Identity, authentication, recovery, MFA, OAuth/OIDC, API keys and machine identities.
3. Horizontal/vertical authorization, IDOR/BOLA, tenancy, object properties, functions and storage policies.
4. Sessions, cookies, JWT, CSRF, fixation, hijacking, expiry, logout and concurrent sessions.
5. Injection into every interpreter: browser, database, shell, template, expression, directory, mail, header, spreadsheet and serialization/parser layers.
6. File upload/download, archive extraction, path traversal, file inclusion, symlink/zip-slip, content sniffing and parser bombs.
7. HTTP/proxy and client boundaries: request smuggling, response splitting, host header, cache behavior, CORS, CSP, framing, messaging and WebSockets.
8. Server-side outbound calls: SSRF, redirects, DNS rebinding defenses, webhooks, callbacks and unsafe third-party API consumption.
9. Business logic and abuse: races, replay, duplicate actions, workflow bypass, automation, quotas, money/inventory/state invariants and denial of service.
10. Data, privacy, secrets and cryptography throughout collection, storage, logs, transport, backups and deletion.
11. Dependencies, build/release, CI/CD, packages, containers, IaC, provenance and update mechanisms.
12. Error/exception handling, fail-open behavior, partial rollback, retries, timeouts, cancellation and security logging/alerting.
13. LLM/model/RAG/tool inputs, output sinks, agency, poisoning, prompt/system disclosure and unbounded consumption.

This inventory is a discovery forcing function, not permission to run destructive exploits. A technique becomes a probe only when a real local entry point, actor, trust boundary, and safe expected result exist.

## Evidence mix

For each applicable surface choose the smallest mix that can prove it:

- source/config review and execution-chain tracing;
- stack-native negative and regression tests;
- SAST, secret scanning, SCA/SBOM, container/IaC scanning where already available;
- local DAST and a real browser for browser-accessible applications;
- two or more isolated identities for authorization/tenant tests;
- controlled parallel requests for state races;
- manual adversarial reasoning for business logic, trust, authorization, identity and cross-service boundaries.

Automated output begins as candidate evidence. Validate it against a real path/endpoint before creating a finding. Preserve the tool name, version, configuration, target scope, exit state, and raw evidence path; do not paste secrets into findings or HTML.

## Completion gate

Before remediation or reporting:

1. Every mandatory matrix row exists.
2. Every `passed` row has evidence and at least one path or endpoint when the target has one.
3. Every `finding` row references a valid finding.
4. Every skip is `not_applicable` with causal evidence or `not_tested` with a limitation.
5. Coverage is rolled up both by source folder/module and by sanitized URL/route/method when dynamic testing ran.
6. All high/critical candidates were reproduced safely or downgraded to `needs_validation` without a false blocker.
7. All eligible bounded corrections were re-probed and received a security regression test where practical.
8. The delivered report represents open, corrected, pending-validation, not-applicable, and not-tested states without claiming absolute safety — as the HTML bundle in `report_mode: full`, or as the response summary in `report_mode: none`. Report mode never relaxes gates 1-7.

## Official references

- https://owasp.org/Top10/
- https://owasp.org/www-project-web-security-testing-guide/
- https://owasp.org/www-project-application-security-verification-standard/
- https://owasp.org/API-Security/
- https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/
- https://owasp.org/www-project-mobile-app-security/
- https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html