| 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
