/prd-securability-enhancement

name: prd-securability-enhancement
description: Enhance PRDs, feature specs, user stories, or product briefs with explicit OWASP ASVS coverage and FIASSE v1.0.4 SSEM implementation guidance — before code is written. Trigger on "harden the PRD/spec", "choose ASVS level", "map features to ASVS", "find missing security requirements", "add NFRs for security", "make these requirements securable", "security-review my product brief". For code review use securability-engineering-review; for code generation use securability-engineering.
license: CC-BY-4.0

PRD Securability Enhancement (FIASSE/SSEM + ASVS)

Enhance PRD content so each feature has explicit, testable securability requirements aligned to OWASP ASVS and shaped by FIASSE v1.0.4 / SSEM. The goal is to upgrade the requirements artifact *before* implementation, so delivery teams build securable capabilities by design rather than retrofitting controls later.

This skill is requirements-centric. It does not review or write code. If the user wants code review, redirect to `securability-engineering-review`. If they want code generation, redirect to `securability-engineering`.

When to Invoke

Trigger this skill when the user asks to:

• 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

Adjacent phrasings: "security-review this spec", "what's missing security-wise from this feature list", "add NFRs for security to my PRD", "make these requirements securable".

Inputs

Ask the user for whatever is missing before starting:

• 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

If the artifact is large, parse the features inline; do not require the user to pre-extract them.

Procedure

Step 1 — Parse features

Extract each feature into a normalized record. Capture for each:

• 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)

If the source PRD lumps several capabilities into one bullet, split them so each feature is independently testable.

Step 2 — Choose the ASVS level *first*

Selecting the level before mapping requirements prevents both under-scoping and over-scoping. Use this rubric:

| Level | Use when | |-------|----------| | **1** | Internal tooling, prototypes, low-sensitivity data, no regulatory pressure, limited blast radius if compromised | | **2** | Typical production web/API systems with authenticated users, business-critical behavior, customer data, or moderate regulatory exposure (most products land here) | | **3** | High-assurance contexts: payments, health records, government, identity providers, anything where compromise causes severe material impact or where attackers are well-resourced |

Default to Level 2 unless evidence pushes lower or higher. Document:

• 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)

Step 3 — Map each feature to ASVS

For every feature, use `data/asvs/README.md` (chapter index) and the `when_to_use` frontmatter in `data/asvs/V*.md` to identify applicable chapters. Common mappings:

• 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)

Filter requirements by the chosen ASVS level. For each requirement, classify coverage:

• **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

Use the **ASVS Coverage Gap Pattern Table** below to spot the gaps that PRDs reliably miss.

Step 4 — Add Securability Notes per feature

Write a *short* paragraph per feature surfacing only the SSEM and FIASSE points that materially shape implementation. Do not enumerate all ten SSEM attributes or all FIASSE tenets — that produces noise.

Useful lenses (mention only when relevant):

• 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** fa