Safety framework
Threat-model risk posture
Risk band: Low Medium High
Required permissions:
Risky command warning: Any path that changes control logic is high-risk
Rollout caveat: Pair residual risk changes with fallback owners
Security
Threat modeling
Convert assumptions into abuse paths, validate controls, and rank residual risk explicitly by business impact.
On this page
Doctrine
- Define critical assets and trust boundaries before writing control ideas.
- Prioritize abuse paths by likelihood, impact, and time-to-manage.
- Map both preventive and detective controls for each threat family.
- Track residual risk decisions as signed acceptance entries with expiry.
Decision tree
- Is input from untrusted actors reaching a state-changing path?
- Yes → enforce strict validation, auth, and request throttling.
- No → verify integrity assumptions and business authorization checks.
- Can lateral movement occur after initial compromise?
- Yes → design immediate boundary barriers and segment audit points.
- No → document control proof in data-flow model.
- Are mitigations mostly preventive or detector-based?
- Mostly detector-only → convert at least one primary abuse path to preventive control.
- Balanced → keep both with independent owners and test cadence.
Diagnostics pathway
- Validate policy changes against live telemetry:
git log --oneline -- /etc/security/policy.d/ - Review access-control decisions for top endpoints:
rg -n "403|401|forbidden|denied" /var/log/security/requests.log | head - Probe abuse-path edges with controlled scripts:
for p in "/admin" "/api" "/health"; do curl -i https://example.com$p; done - Correlate security events with operations signals:
rg -n "latency|error|denied" /var/log/{security,ops}/*.log
Operational checks
- Maintain a ranked threat backlog with owner, control mapping, and due date.
- Run tabletop simulation before major release: authentication bypass and token theft paths.
- Store findings in a shared register; avoid hidden local notes.