protocol

forge:protocol — Security-First Development Workflow

A structured workflow that puts security controls in place before code gets written, not after it ships.

This is a flight checklist. Every phase exists because skipping it has caused a real incident somewhere. The protocol respects your time, it scales to complexity, but it does not let you skip steps. You wouldn't skip preflight on an aircraft because the trip is short. Same principle.

The Four Phases

ASSESS → PLAN → BUILD → VERIFY
  ↑                        │
  └────── (return if new   │
           info emerges) ──┘

Every feature, every significant change, moves through all four phases. The depth of each phase scales to the risk. A CSS color change gets 30 seconds per phase. A payment integration gets hours.

---

Phase 1: ASSESS

Purpose: Understand the security implications before you touch a keyboard.

Entry criteria: A feature, change, or task has been identified.

What you do:

1. Identify what data this feature touches (PII, credentials, financial, health, internal)
2. Map where user input enters and where trusted output exits
3. Identify trust boundaries the feature crosses (client/server, service/service, internal/external)
4. Determine the blast radius if this feature is compromised
5. Check for regulatory requirements (GDPR, PCI-DSS, HIPAA, SOC2)

Use forge:threat here to model the specific threats against what you're building.

Exit criteria: You can answer these three questions:

• What's the worst thing that happens if an attacker owns this feature?
• What data can they reach?
• What trust boundaries does this feature cross?

Output template:

FORGE PROTOCOL — [feature name]
════════════════════════════════

Phase: ASSESS
Status: [in progress / complete]

Feature summary:
[One paragraph: what this feature does and why it exists]

Data classification:
□ PII (names, emails, addresses, phone numbers)
□ Credentials (passwords, tokens, API keys, certificates)
□ Financial (payment info, account numbers, transactions)
□ Health / regulated (HIPAA, FERPA)
□ Internal-only (admin data, system config, logs)
□ Public (non-sensitive, user-facing content)

Security implications identified:
□ [implication 1]
□ [implication 2]
□ [implication 3]

Trust boundaries crossed:
□ [boundary 1: e.g., client → server]
□ [boundary 2: e.g., app server → database]

Blast radius if compromised:
[What an attacker reaches if this feature fails]

Regulatory scope:
[None / PCI-DSS / GDPR / HIPAA / SOC2 — and what that means here]

Ready for PLAN: [yes / no — what's missing]