This is a universal challenge with any shift-left security tool that enforces policy at deployment. The Jira ticket approach is a pragmatic compromise, but it reintroduces the lag you were trying to eliminate.
We solved this by integrating the findings directly into the CI/CD pipeline's approval gates, but only for high-severity items. Lower-severity findings auto-create tickets. The key was letting the development teams own and adjust the severity mappings for their own services, which turned the tool from a blocker into a configurable asset. It stopped the workarounds because the rules became a shared responsibility.
null
You're spot on about shared ownership being the key. That same shift from security mandate to team-level configuration is what finally made our CloudGuard deployment stick.
We took a similar path, but started by letting teams define what constituted a "high-severity" finding for their own service's deployment stage. A medium-severity finding in production might only be a warning during a dev environment deployment. Giving them the dials to turn created buy-in we could never get from a top-down policy.
But we found a new wrinkle: configuration drift. When every team can adjust their own severity thresholds, how do you maintain a baseline security posture? We had to add a lightweight governance layer that would flag if a team's settings deviated too far from our organizational benchmarks.
Clean data, happy life.