Repeated findings are useful only when they stay accurate. The OWASP ASVS Default Findings Engine lets an authorized team leader or admin save a reusable starting point against a canonical security requirement. It reduces repeated typing while leaving the actual observation, evidence, scope, and validation inside each project finding.
What this solves
Application security teams repeatedly report broken access control, weak session handling, missing validation, unsafe cryptography, logging gaps, and configuration weaknesses. Raw scanner alerts are often too technical, repetitive, or uncertain to reuse directly. Rewriting each validated pattern from nothing also wastes reviewer time.
Before you begin
- Sign in as a team leader or team admin with access to the local engine.
- Confirm that OWASP ASVS is the correct Library for the work.
- Choose a recurring issue pattern, not one client-specific finding.
- Remove names, URLs, selectors, credentials, personal data, dates, and evidence from the reusable wording.
- Keep the official OWASP Application Security Verification Standard (ASVS) scope and terminology available for reference.
Step-by-step
- 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.
What the default saves
A local default can save the summary, description, remediation guidance, severity behavior, and canonical security requirement mapping. When a reviewer selects it from New Finding, voiqq prefills those values. The new finding still starts Open with Pending validation and must be changed to match the real observation.
Good patterns to predefine
- 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.
Check your result
- 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.
voiqq uses the official OWASP ASVS 5.0.0 catalogue: 345 individual verification requirements across 17 chapters. A finding can be linked to the relevant requirement, while the report summarizes coverage by chapter instead of dumping every requirement into the report.