Derive security requirements from threat models

Security requirement extraction

by wshobson · MIT license · ★ 39,857 on GitHub · updated Sep 21

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.

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

Overview

Transform threat analysis into actionable security requirements.

Manual install (npx, ZIP)

Claude Codenpx skills add wshobson/agents --skill security-requirement-extraction -g -a claude-code

Claude Code (manual)

mkdir -p ~/.claude/skills && curl -sL https://codeload.github.com/wshobson/agents/tar.gz/4236bb91f839 \
  | tar -xz -C ~/.claude/skills --strip-components=4 agents-4236bb91f839/plugins/security-scanning/skills/security-requirement-extraction

Windows (PowerShell)

New-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null; Invoke-WebRequest "https://m.agentalley.io/zip/661a953fff7fc840f57c/security-requirement-extraction.zip" -OutFile "$env:TEMP\security-requirement-extraction.zip"; Expand-Archive "$env:TEMP\security-requirement-extraction.zip" -DestinationPath "$HOME\.claude\skills" -Force

Claude.ai / desktopDownload the ZIP and upload it under Settings → Capabilities → Skills.

Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

SKILL.md2.5 KB
references/1 file · 21.4 KB

Read the files here

wshobson/4236bb92 files

SKILL.md2.5 KB

SKILL.md

Show the full text68 lines

security-requirement-extraction/SKILL.md68 lines · 2.5 KB

PreviewCode

Outline

RawView on GitHub

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

1	---
2	name: security-requirement-extraction
3	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.
4	---
5
6	# Security Requirement Extraction
7
8	Transform threat analysis into actionable security requirements.
9
10	## When to Use This Skill
11
12	- Converting threat models to requirements
13	- Writing security user stories
14	- Creating security test cases
15	- Building security acceptance criteria
16	- Compliance requirement mapping
17	- Security architecture documentation
18
19	## Core Concepts
20
21	### 1. Requirement Categories
22
23	```
24	Business Requirements → Security Requirements → Technical Controls
25	↓ ↓ ↓
26	"Protect customer "Encrypt PII at rest" "AES-256 encryption
27	data" with KMS key rotation"
28	```
29
30	### 2. Security Requirement Types
31
32	\| Type \| Focus \| Example \|
33	\| ------------------ \| ----------------------- \| ------------------------------------- \|
34	\| Functional \| What system must do \| "System must authenticate users" \|
35	\| Non-functional \| How system must perform \| "Authentication must complete in <2s" \|
36	\| Constraint \| Limitations imposed \| "Must use approved crypto libraries" \|
37
38	### 3. Requirement Attributes
39
40	\| Attribute \| Description \|
41	\| ---------------- \| --------------------------- \|
42	\| Traceability \| Links to threats/compliance \|
43	\| Testability \| Can be verified \|
44	\| Priority \| Business importance \|
45	\| Risk Level \| Impact if not met \|
46
47	## Templates and detailed worked examples
48
49	Full template library lives in `references/details.md`. Read that file when you need concrete templates for this skill.
50
51	## Best Practices
52
53	### Do's
54
55	- Trace to threats - Every requirement should map to threats
56	- Be specific - Vague requirements can't be tested
57	- Include acceptance criteria - Define "done"
58	- Consider compliance - Map to frameworks early
59	- Review regularly - Requirements evolve with threats
60
61	### Don'ts
62
63	- Don't be generic - "Be secure" is not a requirement
64	- Don't skip rationale - Explain why it matters
65	- Don't ignore priorities - Not all requirements are equal
66	- Don't forget testability - If you can't test it, you can't verify it
67	- Don't work in isolation - Involve stakeholders
68