security-requirement-extraction

Map each threat to its STRIDE category, then apply category-specific requirement patterns covering authentication, authorization, data protection, and audit logging. The extractor generates requirements with acceptance criteria, test cases, and priority based on impact and likelihood.

Assign each requirement a security domain such as authentication or data protection, then map domains to framework controls for PCI DSS, HIPAA, GDPR, or OWASP. A compliance matrix links controls to requirement IDs, and gap analysis flags missing or weak coverage.

A good security requirement is specific, testable, and traceable to a threat or compliance control. It includes acceptance criteria, a priority derived from risk, and a rationale explaining why it matters, avoiding vague statements like 'be secure'.

Priority is calculated by multiplying impact and likelihood scores, each rated low through critical. Combined scores of 12 or more yield critical priority, 6 or more high, 3 or more medium, and lower scores map to low priority.

STRIDE-based extraction relies on predefined patterns per category, so it may miss domain-specific or novel threats outside the six categories. Generated requirements are starting points that still need stakeholder review and tailoring to the system's architecture.