Security Requirement Extraction

From the author

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.

— the description by Seth Hobson

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a systematic framework for deriving security requirements from threat analysis and business objectives. It emphasizes the importance of traceability, testability, and clear prioritization, ensuring that security measures are not just abstract goals but concrete, verifiable technical controls. By utilizing defined requirement categories—functional, non-functional, and constraints—the skill helps bridge the gap between high-level security needs and implementation-ready specifications.

What it does

Maps business requirements to specific security controls
Converts threat models into actionable security user stories
Defines testable acceptance criteria for security features
Categorizes requirements by domain, priority, and risk level
Provides structure for compliance mapping and documentation
Facilitates the creation of test specifications from security requirements

When to use it

When translating identified threats into concrete development tasks
During the creation of security-focused user stories
When building security test cases and acceptance criteria
While documenting security architecture
When mapping security controls to compliance frameworks

Advantages

Ensures every security requirement is traceable to a specific threat
Promotes the creation of testable, non-vague security specifications
Standardizes the documentation of security requirements across teams
Helps prioritize security work based on business impact and risk
Facilitates clear communication between security and development stakeholders

Usage examples

“Convert the threat 'unauthorized access to PII' into a set of security requirements.”: The agent generates a structured requirement including a description, rationale, acceptance criteria, and test cases, mapped to the data protection domain.
“Create a security user story for an authentication requirement.”: The agent produces a formatted user story including the 'As a, I need to, So that' structure, along with specific acceptance criteria.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/wshobson/security-requirement-extraction/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip security-requirement-extraction.zip -d .agents/skills

Documentation by Seth Hobson

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

Files

ATTRIBUTION.mdAdded by AutoGineer1.0 KiB
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md2.5 KiB
references/details.md21.4 KiB

SKILL.md