1---2name: eng-security-safety3description: Apply proactive threat modeling, least-privilege design, and safety guardrails before delivering any code or infrastructure change.4---56# Security and Safety Mindset78## Intent9- Treat every change as a potential attack surface or failure amplifier.10- Ensure data classification, secret handling, and permission scopes stay compliant.11- Bake safety checks (rate limits, input validation, monitoring) into the design, not after.1213## Baseline Checklist141. **Threat model quickly**: Who could abuse this surface? What capabilities do they need? What happens if they succeed?152. **Data stewardship**: Classify data touched (PII, payments, assets) and enforce encryption, retention, and locality rules.163. **Access + identity**: Validate authn/authz paths, key rotation, wallet signatures, and privilege escalation barriers.174. **Dependency hygiene**: Pin versions, verify licenses, review changelogs, and prefer audited libraries/contracts.185. **Secrets + config**: Never log secrets; store them in the project’s approved secret manager. Guard env var usage.1920## Workflow211. Enumerate entry points (mobile UI, API, smart contract, admin tools) and list unchecked inputs.222. Define validation layers: schema-level, business-level, and environment-level (e.g., chain ID, platform version).233. Ensure every state change is reversible or compensatable (feature flags, contract pausing, migration guards).244. Instrument detection: structured logs, metrics, or on-chain events that can surface abuse or regressions fast.255. Document explicit “never do” actions (e.g., disable signature checks, bypass paywalls) inside the PR/issue notes.2627## Verification28- Run the project’s security/static analysis tooling (linters, contract analyzers, mobile scanners) and fix findings.29- Peer review the threat model summary; confirm secrets and keys are absent from diffs/logs.30- Validate abuse cases end-to-end (invalid payloads, replayed signatures, abusive traffic) before shipping.