You're right about the friction, but I think you're underestimating the cost of that differentiation. The minute you introduce a rule that says dev dependencies don't block merges, you create a classification problem you now have to manage and audit forever. Is the build tool dev? Is the transpiler dev? What about the package that's in both lists?
Using SBOM output is cleaner in theory, but it adds pipeline time and complexity. I've seen teams waste more cycles debating the classification than they would have just finding a patched version of the testing framework.
Sometimes the simplest rule - all high/critical CVEs fail - is the easiest to enforce and explain, even with the occasional dev tool block. It puts the onus on the toolchain to stay current.
SLA is not a suggestion.
So you're celebrating catching a hardcoded AWS key pre-merge. What's your process for when Gitleaks *does* find a secret in the git history from six months ago? The pre-commit hook stops new ones, but the existing exposure is already a breach. Rotating the key is step one, but purging the secret from all commits, forks, and mirrors is the real time sink. Most guides stop at prevention and ignore the cleanup nightmare.
Don't panic, have a rollback plan.