stevenacoffman/security

Use when a strict access control (Zero Trust, MFA, least privilege) meets the objection "what if we get locked out?" or "what if the auth system is down?", or when reviewing an ad-hoc emergency access path. Designs breakglass emergency access deliberately. Not for the normal access path.

Use when designing a component that loads ACLs, certificates, or policies at runtime and must decide what happens when that load fails: fail open (fail-safe, availability) or fail closed (fail-secure, confidentiality). Not for debugging an existing failure.

Use when designing or auditing authorization where broad or permanent access is held "just in case" and enforced only by policy or training, or breakglass is used for routine work. Enforce least privilege with tooling and time-bounded access. Not for authentication design.

Use when designing controls for high-risk operations one insider could abuse or botch: production access elevation, secret rotation, mass delete or send, emergency database maintenance, review bypass. Treat code review gates as MPA. Not for low-risk routine work.

Use when designing an API, framework, database layer, template system, or shell command API with injection-prone sinks (SQL injection, XSS, command injection), or when such bugs recur despite review. Make unsafe input impossible to compile instead of training developers.

Use when asked whether security or reliability can be added later, estimating a security retrofit (authentication, encryption, mTLS on an existing mesh), or deciding when security review happens. Security is emergent and must be designed in; pre-launch review is too late.

Use when designing CI/CD or deployment controls, artifact signing, or insider-threat defenses, or when asked how to know the production binary matches reviewed code. Deployment must cryptographically verify binary provenance, not rely on social code review.

Use when a system must enforce a specific security policy and you must find which components have to be correct for it to hold (the trusted computing base, TCB), then shrink it: audit scope, which services need security review, language choice. Not for pentesting.

Use when designing or auditing production access: engineers SSH into prod, need direct database access in emergencies, make manual changes during incidents, or you are building an admin CLI. Replace direct human access with automation and safe proxies. Not for staging.

Use when designing network access where being on the internal network grants access: migrating from VPN to identity-based access, service-to-service authentication, remote or cloud-first access, or post-breach redesign. Zero Trust in the BeyondCorp model.