PluginBench
Skill
Pass
Audit score 90

security-requirement-extraction

wshobson/agents

Transform threat models into actionable security requirements and test cases.

What is security-requirement-extraction?

This skill helps you convert threat analysis and business context into specific, testable security requirements. Use it when creating security user stories, building acceptance criteria, mapping compliance needs, or developing security test cases.

  • Convert threat models to security requirements with traceability
  • Categorize requirements as functional, non-functional, or constraints
  • Define requirement attributes: traceability, testability, priority, and risk level
  • Create security user stories and acceptance criteria
  • Map requirements to compliance frameworks
  • Generate security test cases from requirements

How to install security-requirement-extraction

npx skills add https://github.com/wshobson/agents --skill security-requirement-extraction
Claude Code
Cursor
Windsurf
Cline

How to use security-requirement-extraction

  1. 1.Gather threat model outputs and business context for your system
  2. 2.Identify the security concern or threat to address
  3. 3.Determine the requirement type: functional (what), non-functional (how), or constraint (limitations)
  4. 4.Define requirement attributes including traceability to threats, testability criteria, priority, and risk level
  5. 5.Write specific, measurable acceptance criteria that can be verified
  6. 6.Map the requirement to relevant compliance frameworks if applicable
  7. 7.Review with stakeholders to ensure alignment and feasibility

Use cases

Good for
  • Translating STRIDE or similar threat models into actionable requirements
  • Writing security user stories for development teams
  • Creating security acceptance criteria for user story completion
  • Building compliance requirement mappings to frameworks like NIST or ISO 27001
  • Documenting security architecture decisions with linked requirements
Who it's for
  • Security architects
  • Product security teams
  • Compliance officers
  • Development teams implementing security features
  • Security engineers designing test strategies

security-requirement-extraction FAQ

What's the difference between functional and non-functional security requirements?

Functional requirements specify what the system must do (e.g., 'authenticate users'), while non-functional requirements specify how it must perform (e.g., 'authentication must complete in under 2 seconds'). Both are essential for complete security coverage.

How do I ensure requirements are testable?

Include specific, measurable acceptance criteria. Avoid vague language like 'be secure.' Instead, specify the control (e.g., 'encrypt PII with AES-256'), the mechanism (e.g., 'using KMS key rotation'), and how to verify it.

Should every requirement trace back to a threat?

Yes. Every security requirement should map to at least one threat or compliance obligation. This traceability ensures requirements address actual risks and aren't arbitrary.

How do I prioritize security requirements?

Consider business impact, risk level if not met, compliance obligations, and implementation effort. Not all requirements have equal importance; prioritization helps teams focus on high-impact items first.

Can this skill help with compliance mapping?

Yes. The skill supports mapping security requirements to compliance frameworks early in the process, helping ensure your requirements address regulatory obligations alongside threat mitigation.

Full instructions (SKILL.md)

Source of truth, from wshobson/agents.


name: security-requirement-extraction description: Derive security requirements from threat models and business context. Use when translating threats into actionable requirements, creating security user stories, or building security test cases.

Security Requirement Extraction

Transform threat analysis into actionable security requirements.

When to Use This Skill

  • Converting threat models to requirements
  • Writing security user stories
  • Creating security test cases
  • Building security acceptance criteria
  • Compliance requirement mapping
  • Security architecture documentation

Core Concepts

1. Requirement Categories

Business Requirements → Security Requirements → Technical Controls
         ↓                       ↓                      ↓
  "Protect customer    "Encrypt PII at rest"   "AES-256 encryption
   data"                                        with KMS key rotation"

2. Security Requirement Types

TypeFocusExample
FunctionalWhat system must do"System must authenticate users"
Non-functionalHow system must perform"Authentication must complete in <2s"
ConstraintLimitations imposed"Must use approved crypto libraries"

3. Requirement Attributes

AttributeDescription
TraceabilityLinks to threats/compliance
TestabilityCan be verified
PriorityBusiness importance
Risk LevelImpact if not met

Templates and detailed worked examples

Full template library lives in references/details.md. Read that file when you need concrete templates for this skill.

Best Practices

Do's

  • Trace to threats - Every requirement should map to threats
  • Be specific - Vague requirements can't be tested
  • Include acceptance criteria - Define "done"
  • Consider compliance - Map to frameworks early
  • Review regularly - Requirements evolve with threats

Don'ts

  • Don't be generic - "Be secure" is not a requirement
  • Don't skip rationale - Explain why it matters
  • Don't ignore priorities - Not all requirements are equal
  • Don't forget testability - If you can't test it, you can't verify it
  • Don't work in isolation - Involve stakeholders