security

Related Skills

• Designing API contracts or database schemas? → Use schema to enforce minimal exposure and proper constraints
• Structuring layers around trust boundaries? → Use architecture for proper boundary separation
• Writing tests for security-sensitive code? → Use testing to verify security behavior
• Handling domain rules around access control? → Use domain-modeling for authorization aggregates
• Applying least privilege or single responsibility to security design? → Use principles for SOLID guidance

Applicability Rubric

Condition	Pass	Fail
Trust boundary crossing	Data moves between zones of different trust levels (including stored data re-entering logic)	All data stays within a single trust zone
Identity or access decision	Code decides who someone is or what they can do	No identity or permission logic
Secret or credential handling	API keys, passwords, tokens, encryption keys involved	No sensitive credentials handled
Sensitive data storage or transmission	PII, financial data, health data processed	No sensitive data involved

Apply when: Any condition passes

Core Principles

Golden Rule

Every security decision is a trust decision. Before writing any security-sensitive code, ask: "Who am I trusting, with what, and what happens if that trust is violated?"

STRIDE Threat Thinking

Systematically analyze threats before writing security-sensitive code. STRIDE is a thinking process, not a checklist. Reference: Microsoft Security Development Lifecycle (SDL).

┌──────────────────────────────┐
│ 1. IDENTIFY                  │
│    What components change?    │
│    (processes, data stores,   │
│     data flows, boundaries)   │
└─────────────┬────────────────┘
              ↓
┌──────────────────────────────┐
│ 2. QUESTION                  │
│    For each component, ask    │
│    the 6 STRIDE questions     │
└─────────────┬────────────────┘
              ↓
┌──────────────────────────────┐
│ 3. VERIFY                    │
│    Does a mitigation exist    │
│    in the code for each       │
│    applicable threat?         │
└─────────────┬────────────────┘
              ↓
┌──────────────────────────────┐
│ 4. IMPLEMENT                 │
│    Add missing mitigations    │
│    before proceeding          │
└──────────────────────────────┘