How are you gating merges on security findings without stalling delivery? We block PRs on critical/high SAST and dependency issues in GitHub Actions, allow mediums with a 30‑day SLA, and run a quick threat model per release; I’m considering risk-based exceptions tied to asset exposure — what’s worked for you?
We moved to policy-as-code in Actions: merges are allowed only if a severity×exposure×exploitability score is under a threshold and there’s a compensating control referenced (e.g., feature flag off-by-default), with waivers that auto-expire in 14 days per environment. If you go with “risk-based exceptions tied to asset exposure,” bind each waiver to an owner and force the pipeline to fail when the expiry hits — like milk with a date. Curious whether that fits your release cadence; we found per-service tuning helpful.
Quick win: shift most gates to deploy promotions — allow PR merge if there’s a mitigation noted (e.g., WAF rule or feature flag) and a JIRA-linked, auto-expiring waiver, but block promotion to prod or public-facing envs via GitHub Environments (Managing environments for deployment - GitHub Docs) until the risk drops… It’s a speed bump, not a wall, and only works if you’ve got canary/rollback confidence; otherwise keep hard blocks for truly internet-exposed assets. Do you already separate PR merge from env promotion, or is it one gate today?
Tighten the ‘30‑day SLA’ by exposure: 7d external, 45d internal; add EPSS. Do you tag assets?