Sdd Design Security

SDD Design Security

Write the Security Considerations section of a design document.

Scope

Cross-Cutting Roles

Note: Cross-cutting concerns are an extension to docs/sdd-guidelines.md for specialist coordination. See sdd-design for full mapping.

Security is:

• Primary owner: (none in typical frontend projects)
• Reviewer for: Error handling (owned by frontend), User input (owned by frontend)

Instructions

Step 1: Read Context

1. Design skeleton (from sdd-design)
2. All REQs in your section's @derives
3. Foundation anchors (especially CONSTRAINT-*, SCOPE-*)
4. Frontend section (for input handling, code execution)

Step 2: Identify Attack Surface

For each REQ, identify security-relevant elements:

Attack surface types:

• User input: forms, props manipulation, text entry
• Dynamic content: user-provided data rendered to DOM
• Code execution: eval, Function(), dynamic imports

Step 3: Build Threat Model

For each attack surface:

Impact levels: Critical / High / Medium / Low Likelihood: High (easy to exploit) / Medium / Low (requires skill)

Step 4: Design Input Validation

For each user input from REQs:

Validation types:

• Type checking (string, number, enum)
• Range/length limits
• Format validation (regex)
• Whitelist vs blacklist

Step 5: Design Code Execution Controls (if applicable)

If REQ involves code execution:

Decision: Sandbox vs restricted scope vs no eval?

Document with @derives linking to REQ.

Step 6: Design XSS Prevention

For each dynamic content type:

Step 7: Review Dependencies

For libraries suggested by other specialists:

Check: npm audit, Snyk, GitHub advisories

Step 8: Write Section

## Security Considerations

@derives: {REQ-IDs}

### Threat Model
### Input Validation
### Code Execution Controls (if applicable)
### XSS Prevention
### Dependency Security

**Status:** draft

Step 9: Add Decisions

For non-obvious security choices:

| ID | Decision | Rationale | Owner |
|----|----------|-----------|-------|
| DEC-00x | {what} | {why — connect to REQ + threat} | security |

Step 10: Handoff

Per docs/sdd-guidelines.md §4.3 and §10.6.

1. Update Section Status

**Status:** verified

2. Update State File

# .sdd/state.yaml
documents:
  design:
    sections:
      security: verified

3. Create Handoff Record

# .sdd/handoffs/{timestamp}-security.yaml
from: sdd-design-security
to: sdd-design
timestamp: {ISO-8601}

completed:
  - design.security: verified

in_progress: []

blocked: []

gaps: []

next_steps:
  - sdd-design-frontend: Implement validation per spec
  - sdd-design-frontend: Review — error handling exposes no sensitive info

4. Cross-Cutting Status

@derives Judgment

A security control @derives from a REQ when:

NOT @derives:

• Generic security best practices not tied to REQ
• Threats from features not in requirements

Verification

• All user inputs from REQs have validation defined
• Threat model covers all attack surfaces
• Code execution controls match REQ scope (if applicable)
• XSS prevention for all dynamic content
• Dependencies reviewed for known vulnerabilities
• Decisions logged with rationale
• Cross-cutting reviews completed

References

Examples