界面已本地化;技能介绍与说明文档按所选语言由 AI 自动翻译,代码、命令、路径和专业术语保留原文,以原作者文档为准。
探索技能
开发与工程 · SKILL.md

security-requirement-extraction

security-requirement-extraction

【开发与工程】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.

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

技能说明

GitHub

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
我的收藏