The OWASP ASVS Default Findings Engine is a requirement-aware template layer for OWASP Application Security Verification Standard (ASVS). It helps a team define consistent starting language for recurring findings while the normal project remains the source of truth for scope, evidence, ownership, remediation progress, validation, and reports.
Library and standards scope
OWASP ASVS provides detailed application security verification requirements that can organize web application and API assessment scope. The selected ASVS version and verification level guide coverage, while the tested behavior, trust boundary, exploit conditions, and business context determine the actual finding and severity.
Global, local, and project layers
- Global defaults are standards-based templates published by voiqq platform for a system Library.
- Local defaults belong to the signed-in workspace administrator and can override editable wording without changing the global source.
- A project finding receives copied template values and then becomes an independent record.
- Later global changes do not silently rewrite a local override or a finding already created in a project.
- Status is Open and validation is Pending when the reusable default is applied, unless an authorized project workflow later changes them.
Fields and canonical mapping
Each template is owned by a canonical security requirement in the OWASP ASVS Library. The reusable record contains a stable identifier, summary, description, remediation guidance, severity key, mapped values, source Library, and display order. The visible wording can be edited locally, while the background requirement identity continues to support filters, reports, imports, and New Finding suggestions.
Create or customize a default
- Set the ASVS version, level, target assets, and authorization boundary.
- Open the ASVS local engine and choose the most precise requirement.
- Write a neutral vulnerability summary without a client endpoint or payload.
- Describe the reusable security consequence and conditions that make the pattern relevant.
- Add outcome-based remediation and retest expectations.
- Use the project finding for requests, responses, payloads, assets, evidence, exploitability, and final severity.
Writing rules for reusable findings
Write the summary as a concise statement of the recurring failure. Use the description to explain the expected behavior, likely impact, or control concern in neutral language. Use remediation to describe the desired outcome rather than a patch tied to one framework or customer. Store actual results, reproduction steps, affected assets, evidence, people, dates, measurements, samples, and environment details in the project finding.
Suitable template subjects
- Object-level authorization is not enforced before access to another user resource.
- Session tokens remain valid after a security-relevant account or authentication event.
- Untrusted input reaches an interpreter or sensitive operation without the required validation.
- Sensitive data is exposed through transport, storage, logs, or an unintended response.
- Security events do not preserve the context needed for detection and investigation.
Use a default in a project
Open New Finding inside a project configured with OWASP ASVS. Choose Template mode or select a prepared template after choosing the applicable security requirement. voiqq prefills the reusable values. Review every field, add the real evidence and context, and save the finding. Comments, attachments, assignments, history, validation, sharing, exports, and reports then use the same normal project workflow.
Accuracy and safety checks
- Never store credentials, tokens, or live exploit data in a reusable default.
- Keep scanner confidence separate from professional validation.
- Map the requirement rather than only a broad weakness category.
- Avoid claiming exploitability until the project evidence supports it.
- Retest the exact affected control before closure.