Security Requirement Extraction

When to use this skill

Use Security Requirement Extraction when an AI agent needs a reusable SKILL.md workflow for this job: 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.

When not to use it

Skip Security Requirement Extraction when the task is outside the writing category, or when a more specific skill in this directory already covers the same workflow with clearer triggers.

How to install

1. Personal install: create ~/.claude/skills/security-requirement-extraction/SKILL.md (and any bundled scripts) so Claude Code, Claude Desktop, and compatible agents can load it in every project.
2. Project install: commit the same folder at .claude/skills/security-requirement-extraction/ so teammates get the skill with the repo.
3. Restart the agent session after copying files so it re-scans the skills directory, then ask for the task in words that match the skill description.

Full install guide for Claude, Cursor, and Codex

What this skill does

# 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

| Type | Focus | Example | | ------------------ | ----------------------- | ------------------------------------- | | **Functional** | What system must do | "System must authenticate users" | | **Non-functional** | How system must perform | "Authentication must complete in <2s" | | **Constraint** | Limitations imposed | "Must use approved crypto libraries" |

### 3. Requirement Attributes

| Attribute | Description | | ---------------- | --------------------------- | | **Traceability** | Links to threats/compliance | | **Testability** | Can be verified | | **Priority** | Business importance | | **Risk Level** | Impact 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

Intended uses

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