safe-by-default-architect

To convert recurring RCA findings into enforceable static analysis rules, you extract pattern evidence from incidents, classify danger mechanisms, define approved safe replacements, and produce a phased rollout plan for lint or semgrep rules. This includes mapping forbidden patterns to safe defaults.

A deny-by-default architecture prevents security defects by making the safe path the default path. It transforms recurring unsafe implementation patterns into safe architectural defaults, forbidden pattern inventories, and common layer abstractions that make unsafe behavior hard to implement across controller, API, database, file, and time boundaries.

Creating a forbidden pattern inventory from incident evidence involves extracting recurring unsafe implementation patterns from your RCA findings, classifying them into concrete danger categories like injection or silent corruption, and mapping each anti-pattern to an approved safe replacement with a structured taxonomy.

Designing common layer abstractions to prevent unsafe coding patterns involves recommending shared services, repositories, and wrappers that make unsafe behavior hard to implement. These abstractions enforce safe defaults across controller, API, database, file, and time boundaries by centralizing security standards.

Yes, you can use semgrep rules to enforce safe defaults. The process produces static rule candidates with false-positive risk notes and enforcement severity guidance, allowing a phased rollout that minimizes friction while blocking dangerous implementation patterns identified from RCA evidence.

Exception governance defines when deviations from security standards are allowed by categorizing them as review-required, approval-required, or prohibited. It adds checklist items to align human code review processes with the new safe defaults and forbidden pattern inventories.