Notifications
Clear all
Topic starter
20/08/2026 5:37 pm
TL;DR: Automated security fix workflows are losing to review fatigue, with bot-generated pull requests accepted at 37.38% versus 72.53% for human submissions and security PRs in some projects seeing only 13% adoption, according to Pixee. The real control gap is not fix generation but fix quality, because developers will not merge remediation they do not trust.
NHIMG editorial — based on content published by Pixee: Agentic Security Engineering, "85% of Automated Security Fixes Get Dismissed. The Fix Isn't More Fixes."
Questions worth separating out
Q: How should security teams improve acceptance of automated security fixes?
A: They should stop optimising for volume and start optimising for reviewer trust.
Q: Why do developers reject automated security remediation so often?
A: Developers reject remediation when it increases review effort without reducing uncertainty.
Q: What breaks when security tools generate more fixes than teams can review?
A: The review queue becomes the control failure point.
Practitioner guidance
- Reduce low-signal remediation volume Suppress automated pull requests for findings that are likely false positives, duplicative, or low exploitability so developers only see changes worth reviewing.
- Add codebase-aware remediation context Require each fix PR to explain dependency compatibility, affected files, test impact, and why the proposed patch fits repository conventions.
- Use merge confidence gates Route high-confidence fixes through fast lanes only when testing, scope, and blast radius support a safe merge decision.
What's in the full article
Pixee's full analysis covers the operational detail this post intentionally leaves for the source:
- The breakdown of merge-rate differences between human, dependency-bot, and AI-generated fixes across the cited datasets.
- The workflow patterns that increase fix acceptance, including PR sizing, explanation quality, and compatibility signalling.
- The discussion of where Renovate-style automation helps and where codebase-aware remediation remains necessary.
- The practical examples of how teams can triage findings before opening remediation pull requests.
👉 Read Pixee's analysis of why automated security fixes are getting dismissed →
Automated security fixes are failing developer review: what now?
Explore further
20/08/2026 6:23 pm
Automated remediation has become a trust problem, not a tooling problem. The article shows that developers are not rejecting security fixes because they dislike security, but because many fixes arrive without enough context to justify the review cost. In identity programmes, the same dynamic appears when teams receive broad policy changes that do not map cleanly to workload behaviour or privilege boundaries. The practical conclusion is that trust is now a control surface, not a soft issue.
A question worth separating out:
Q: How can organisations tell whether automated remediation is trustworthy?
A: Look for a clear policy basis, an accountable owner, and an audit trail for every automated action. If the remediation cannot be explained after the fact, auditors and operations teams will treat it as a risk amplifier rather than a control. Trust comes from transparency, not speed alone.
👉 Read our full editorial: Automated security fixes are failing the merge test in AppSec
