OWASP ASVS Application Security AI Skill Guide
Overview & Engine Architecture
OWASP Application Security Verification Standard (ASVS) is a catalog of security requirements grouped by chapters (authn, session, access control, validation, crypto, API, etc.) across levels (typically L1-L3). Teams pick a target level, map each requirement to an implemented control or exception, and collect verification evidence. Agents translate ASVS items into concrete engineering tasks - not vague "be secure" advice.
Threat / compliance context
-> Choose ASVS level (L1 baseline ... L3 high assurance)
-> Chapter requirements
-> Control implementation + tests
-> Evidence / exceptions register
When to use this skill
- Setting an application security baseline for a product
- Preparing security review or customer questionnaire evidence
- Turning audit gaps into backlog tickets
- Aligning API and auth designs with standard requirements
Operational directives
- Pick a level explicitly (often L1 for standard web apps; higher for sensitive data).
- Map each applicable requirement to: implemented, partial, N/A (with rationale), or gap.
- Prefer verifiable controls (tests, config-as-code, scanner gates) over slideware.
- Do not mark "N/A" for access control or injection chapters without written justification.
- Revisit ASVS version when upgrading major releases of the standard.
Requirement-to-ticket sketch
ASVS 4.x V4.2.1 (example numbering may differ by version)
Goal: Enforce authorization on every object reference
Evidence: integration tests for IDOR; centralized policy middleware
Ticket: "Add object-level authz checks on /api/orders/{id}"
Common chapter focus areas
| Chapter theme |
Agent emphasis |
| Authentication |
MFA options, credential storage, brute-force resistance |
| Session |
Cookie flags, rotation, logout invalidation |
| Access control |
Deny-by-default, object-level checks, least privilege |
| Validation |
Server-side validation, encoding, file upload limits |
| API |
Authn on all routes, rate limits, mass-assignment guards |
Best practices
- Keep a living ASVS workbook (spreadsheet or SecOps tool) linked to PR evidence.
- Combine ASVS mapping with automated findings (
@semgrep, @codeql, @snyk) - standards and scanners complement each other.
- Treat exceptions as time-boxed risk acceptances with owners.
- Write acceptance criteria that quote the ASVS intent in engineer-readable language.
Limitations
- ASVS is requirements-oriented; it does not replace threat modeling or pen tests.
- Exact section numbers change between ASVS versions - always cite the version used.
- Regulatory frameworks (PCI, HIPAA) may demand controls beyond the chosen ASVS level.
Related skills
@semgrep - static rules mapped to coding flaws@codeql - deep semantic vulnerability queries@snyk - dependency and container issue triage@incident-runbooks - response when controls fail in production
1---2name: owasp-asvs3description: Operational skill for OWASP ASVS: selecting levels, mapping requirements to controls, evidence for reviews, and gap triage.4---56# OWASP ASVS Application Security AI Skill Guide78## Overview & Engine Architecture910OWASP Application Security Verification Standard (ASVS) is a catalog of security requirements grouped by chapters (authn, session, access control, validation, crypto, API, etc.) across levels (typically L1-L3). Teams pick a target level, map each requirement to an implemented control or exception, and collect verification evidence. Agents translate ASVS items into concrete engineering tasks - not vague "be secure" advice.1112```13Threat / compliance context14 -> Choose ASVS level (L1 baseline ... L3 high assurance)15 -> Chapter requirements16 -> Control implementation + tests17 -> Evidence / exceptions register18```1920## When to use this skill2122- Setting an application security baseline for a product23- Preparing security review or customer questionnaire evidence24- Turning audit gaps into backlog tickets25- Aligning API and auth designs with standard requirements2627## Operational directives28291. Pick a level explicitly (often L1 for standard web apps; higher for sensitive data).302. Map each applicable requirement to: implemented, partial, N/A (with rationale), or gap.313. Prefer verifiable controls (tests, config-as-code, scanner gates) over slideware.324. Do not mark "N/A" for access control or injection chapters without written justification.335. Revisit ASVS version when upgrading major releases of the standard.3435## Requirement-to-ticket sketch3637```text38ASVS 4.x V4.2.1 (example numbering may differ by version)39Goal: Enforce authorization on every object reference40Evidence: integration tests for IDOR; centralized policy middleware41Ticket: "Add object-level authz checks on /api/orders/{id}"42```4344## Common chapter focus areas4546| Chapter theme | Agent emphasis |47| --- | --- |48| Authentication | MFA options, credential storage, brute-force resistance |49| Session | Cookie flags, rotation, logout invalidation |50| Access control | Deny-by-default, object-level checks, least privilege |51| Validation | Server-side validation, encoding, file upload limits |52| API | Authn on all routes, rate limits, mass-assignment guards |5354## Best practices5556- Keep a living ASVS workbook (spreadsheet or SecOps tool) linked to PR evidence.57- Combine ASVS mapping with automated findings (`@semgrep`, `@codeql`, `@snyk`) - standards and scanners complement each other.58- Treat exceptions as time-boxed risk acceptances with owners.59- Write acceptance criteria that quote the ASVS intent in engineer-readable language.6061## Limitations6263- ASVS is requirements-oriented; it does not replace threat modeling or pen tests.64- Exact section numbers change between ASVS versions - always cite the version used.65- Regulatory frameworks (PCI, HIPAA) may demand controls beyond the chosen ASVS level.6667## Related skills6869- `@semgrep` - static rules mapped to coding flaws70- `@codeql` - deep semantic vulnerability queries71- `@snyk` - dependency and container issue triage72- `@incident-runbooks` - response when controls fail in production
alivirgo