• Strengthen or harden a PRD, spec, user-story set, or product brief with security requirements
• Choose an ASVS assurance level (Level 1, 2, or 3) for a product or feature
• Map features to ASVS controls or check ASVS coverage of a requirements doc
• Find missing security requirements before development starts
• Annotate features with SSEM attributes or FIASSE tenets
• Add testable security acceptance criteria to existing functional requirements

• The PRD, spec, or feature list (markdown, prose, ticket export, etc.)
• System context: user types, deployment model, data sensitivity, integration surfaces
• Compliance or risk context, if any (HIPAA, PCI, SOC 2, regulated industry)
• Whether they have an ASVS level preference, or want this skill to recommend one

• Feature ID and title (assign IDs like

  F-01

  if absent)
• Actor (user role, system, external service)
• Data touched and sensitivity class
• Trust boundaries crossed (browser↔server, service↔service, server↔storage, internal↔external)
• Existing acceptance criteria (verbatim, even if weak)

• Chosen level
• Why lower levels are insufficient (when level > 1)
• Any specific features that should escalate above the baseline (e.g., a payments endpoint inside a Level-2 product gets Level-3 treatment)

data/asvs/README.md

when_to_use

data/asvs/V*.md

• Auth flows → V2 (Authentication), V3 (Session Management)
• Authorization, ownership, multi-tenant scoping → V4 (Access Control)
• File upload/download → V5 (File Handling)
• Crypto, password storage, tokens → V6 (Cryptography)
• Logging, error handling, observability → V7 (Error/Logging)
• PII, data at rest/in transit → V8 (Data Protection), V14 (Secure Communication)
• Public APIs → V9 (API/Web Services)
• Config, secrets, deployment → V10 (Configuration)
• Workflow rules, anti-automation → V11 (Business Logic)
• Any user/external input → V12 (Input Validation)
• Anything rendered or returned to a client → V13 (Output Encoding)
• Sensitive data lifecycle → V16 (Sensitive Data)

• Covered — the PRD already satisfies the intent
• Partial — partly covered; clarify or strengthen acceptance criteria
• Missing — requirement absent and must be added
• N/A — justified with a one-line rationale

• Trust-boundary handling and input canonicalization (FIASSE v1.0.4 S4.3, S4.4.1)
• Derived Integrity — never trust client-supplied values for server-owned state (FIASSE v1.0.4 S4.4.1.2)
• Request Surface Minimization — process only the named values you expect (FIASSE v1.0.4 S4.4.1.1)
• Observability: what must be logged or auditable (FIASSE v1.0.4 S3.2.1.4 + Accountability; Transparency S2.5)
• Least Astonishment — predictable behavior at trust boundaries and error paths (FIASSE v1.0.4 S2.6)
• Resilience or availability drivers (rate limits, timeouts, graceful and secure failure)
• Testability or modifiability mandates (e.g., centralizing crypto/auth in a dedicated module)
• Dependency stewardship — ongoing relationship with third-party code (FIASSE v1.0.4 S4.6)

• Behaviorally observable (a test or audit can confirm pass/fail)
• Specific about boundary conditions (failure modes, unauthorized actors, malformed input)
• Tied to a verifiable artifact (log line, response code, denied action)

• [Original requirement, kept or rewritten]
• [Newly added requirement from ASVS mapping]
• [Newly added requirement from ASVS mapping]

• [Testable criterion tied to a requirement above]
• [Testable criterion tied to a requirement above]

undefined

F-03: Users can reset their password by clicking "Forgot Password" and entering their email. The system emails a reset link.

undefined

• User can request a password reset by entering an account email at

  /reset

  .
• The system always returns the same success response whether or not the email matches an account (prevents account enumeration, V2.2.2).
• Reset tokens are single-use, expire within 15 minutes, and are stored only as a salted hash (V6.2).
• New passwords are validated against a minimum policy and screened against a known-breached-password list (V6.2.1).
• All reset requests, token issuances, token redemptions, and password changes are logged with user ID, source IP, user agent, and outcome (V7.1.1).
• Reset requests are rate-limited per email and per source IP (V11.1.4).
• The email input is canonicalized and validated against a strict format (V12.1.1).

• Submitting a non-existent email returns the same response body, status code, and timing characteristics as a valid email (within tolerance).
• A reset token cannot be redeemed after 15 minutes or after first successful use; both cases produce a generic failure response and a logged

  reset_token_invalid

  event.
• More than 5 reset requests for the same email within 10 minutes are rejected with HTTP 429 and logged.
• Audit log lines for reset events are queryable by user ID and contain the fields above.

This is the level of specificity the output should hit — concrete, testable, and traceable back to ASVS.

• Every feature has an ID, actor, data classification, and trust-boundary list
• ASVS level is chosen and justified before per-feature mapping
• Every feature mapped against all applicable ASVS chapters at the chosen level
• Gap patterns from the table above were applied to every relevant feature
• Every Missing/Partial item produced a concrete PRD change

• Coverage matrix is present and includes change-needed column
• Each feature follows the exact output shape (Actor / Data / Trust Boundaries / ASVS Mapping / Updated Requirements / Acceptance Criteria / Securability Notes)
• Acceptance criteria are behaviorally testable, not aspirational
• Securability Notes are surgical — only material SSEM/FIASSE points, not exhaustive enumeration

• Every added requirement cites its ASVS reference
• Cross-cutting requirements section captures shared controls
• Open gaps and assumptions are listed explicitly

• Prefer adding a missing requirement over assuming coverage; mark it explicitly so reviewers see it.
• Prefer fewer, sharper ASVS references per feature over a long list that nobody will action.
• Prefer plain language in Securability Notes — these are read by product managers, not just security engineers.

• Step-by-step runbook: plays/prd-fiasse-asvs-enhancement.md
• ASVS chapter index:

  data/asvs/README.md

• ASVS requirements (per chapter):

  data/asvs/V*.md

• FIASSE v1.0.4 foundational principles:

  data/fiasse/S2.1.md

  –

  S2.6.md

  (Transparency S2.5, Least Astonishment S2.6)
• FIASSE v1.0.4 SSEM attribute umbrellas:

  data/fiasse/S3.2.1.md

  –

  S3.2.3.md

  ; leaf files (e.g.

  S3.2.1.4.md

  Observability) for attribute-specific guidance
• FIASSE v1.0.4 Boundary Control and Resilient Coding:

  data/fiasse/S4.3.md

  ,

  S4.4.md

  , and the canonical-input-handling leaves

  S4.4.1.md

  ,

  S4.4.1.1.md

  ,

  S4.4.1.2.md

• FIASSE v1.0.4 Dependency Management and Stewardship:

  data/fiasse/S4.5.md

  ,

  S4.6.md