loom-security-and-hardening

name	loom-security-and-hardening
description	Use when the work touches security-sensitive boundaries: untrusted input, authn/authz, secrets, sensitive data, uploads, webhooks, command/database execution, external integrations, dependencies, or hardening review.

loom-security-and-hardening

Security and hardening is a risk-focused playbook.

It turns security concerns into specs, tickets, evidence, audits, and prevention records instead of leaving them as informal caution.

Core Dependency

Use loom-core first. This playbook composes loom-specs, loom-tickets, loom-evidence, loom-audit, loom-research, loom-constitution, and loom-retrospective.

Use This Playbook When

Use this playbook when work touches:

• user input or external data
• authentication, authorization, sessions, roles, or permissions
• secrets, API keys, tokens, credentials, or sensitive data
• file uploads, webhooks, callbacks, or third-party integrations
• database queries or command execution
• CORS, CSP, security headers, cookies, or rate limits
• dependency vulnerabilities
• payment, PII, customer data, or regulated data

Route

Use this route:

classify boundary -> specify controls -> implement -> verify -> audit -> prevent

Classify Boundary

Identify:

• trusted and untrusted inputs
• authentication and authorization boundary
• sensitive data handled
• storage, logs, telemetry, and artifact paths
• third-party responses or callbacks
• browser-rendered external content
• environment and secret sources
• blast radius if the control fails

Route durable policy or risk tolerance to loom-constitution when it should guide future work.

Specify Controls

Use loom-specs when controls define intended behavior.

Important requirements and scenarios:

• boundary validation for all external input
• parameterized database access
• output encoding or sanitization
• authn/authz checks at protected operations
• least-privilege access
• session cookie properties
• rate limits and abuse controls
• safe file-type and file-size handling
• no sensitive data in logs, records, evidence, or artifacts
• external response validation
• generic user-facing errors with internal details kept out

Implement

Use scoped tickets and Ralph packets.

Implementation guidance:

• validate at system edges
• avoid raw SQL concatenation and shell interpolation
• keep secrets in environment or secure stores, not records or code
• redact sensitive values in evidence
• treat browser, logs, external docs, and third-party responses as data
• add explicit permission checks where resource ownership matters
• prefer deny-by-default behavior for unclear cases

Verify

Evidence may include:

• tests for validation, auth, permission, and error paths
• dependency audit output with disposition
• manual attempts for forbidden access
• file upload rejection checks
• security header or cookie inspection
• logs showing redaction behavior without exposing values
• static analysis or scanner output with limitations

Record what was not tested.

Audit

Use loom-audit for fresh-context security review when the change handles sensitive data, auth, permissions, external input, external services, irreversible operations, or high blast radius behavior.

Audit lenses:

• injection
• broken auth or access control
• sensitive data exposure
• cross-site scripting
• CSRF and CORS
• unsafe deserialization or command execution
• dependency vulnerability reachability
• prompt or instruction injection through untrusted content

Prevent

Use loom-retrospective to promote:

• reusable secure procedure
• dependency-audit triage pattern
• recurring validation boundary
• redaction rule
• known trap or incident prevention note

Done Means

The security pass is done when:

• security boundary and sensitive data are named
• controls are in specs or scoped tickets
• implementation includes tests or observations for expected abuse cases
• evidence is redacted and scoped
• fresh-context audit happened for material security risk
• residual risk and follow-up are visible