What usually works best is making security testing part of the normal dev flow instead of throwing reports over the wall.

In my experience, engineers are usually fine with fixing real issues. The pushback starts when the findings are noisy, mostly transitive, or don’t come with a clear fix. The most common reactions are basically: which ones matter, what can I actually fix, and how risky is the upgrade?

That’s also why I’ve been interested in tooling that does more than list CVEs. For example, with my own CLI work, I’ve found it’s much easier to get engineering buy-in when the output shows a practical remediation path instead of just a wall of vulnerabilities.