207d8f1697
workflow.security_block_on was documented as the minimum threat severity that blocks advancement, but threats carried no severity and the auditor's threats_open count (the SECURITY.md gate field) counted every open threat regardless of severity — so the threshold had no effect, and the auditor's block_on vocabulary (open/unregistered/none) did not even match the config enum (critical/high/medium/low/none). - planner: add a Severity column to the STRIDE threat register; assign severity per threat. - auditor: read severity; reconcile the <config> block_on domain to the severity enum; redefine threats_open as the count of OPEN threats whose severity is at or above block_on (none => 0). Below-threshold opens are reported as non-blocking and excluded from threats_open. - SECURITY.md template + planning-config.md reconciled. No gate-check site changed: threats_open == 0 stays the gate everywhere; only its computation is now severity-filtered. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
654 B
654 B
type, pr
| type | pr |
|---|---|
| Fixed | 1635 |
The security audit gate now respects workflow.security_block_on severity — /gsd:secure-phase previously blocked phase advancement on any open threat regardless of severity, so the documented security_block_on threshold had no effect (and the auditor's block vocabulary didn't even match the config enum). Threats now carry a per-threat Severity (critical|high|medium|low), and only open threats at or above the configured security_block_on severity count toward the blocking gate (SECURITY.md threats_open); none disables blocking, and a missing/unparseable severity fails closed as critical. (#1626)