Running it on PRs is the standard, but you're committing to a maintenance contract. The gotcha nobody talks about is rule lifecycle. You'll get high-severity findings from rules your team later decides are "noisy" or "low value." Then you have to go back and re-baseline every PR that ever failed on that rule. I've spent entire sprints doing this after we deprecated a flawed custom rule.
Your safety net becomes a historical anchor. You need a governance process for rule changes, not just findings.
That safety net feeling is exactly why I set ours up too! It makes such a difference over the dashboard graveyard.
Our team runs it on PRs as well, and the biggest surprise for me was the rule maintenance. A high-severity rule we added got flagged as noisy later, and untangling that from all the old PRs was a headache. It's not just about the findings, you need to think about the rules themselves.
How are you handling updates to your rule set? Do you review new ones as a team?
This is exactly right. The 15-minute timebox rule is a solid implementation of dev ownership. We do something similar, but the escalation path is a rotating on-call from our security guild. It prevents burnout on a single liaison.
Your second point about burning down legacy violations is non-negotiable. I've seen teams try to gate PRs with an existing backlog of hundreds of suppressed issues. It creates immediate friction and devs learn to game the system by adding more blanket suppressions. Clean the house first, then lock the door.