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.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “85% of Automated Security Fixes Get Dismissed. The Fix Isn't More Fixes.”.
By the numbers:
- In JavaScript open-source projects, Dependabot security PRs hit just 13% adoption.
Key questions
Q: Why do automated security fixes get rejected so often?
A: Automated fixes are often rejected because they arrive as generic, hard-to-verify changes that do not fit the repository’s patterns or review expectations.
Q: When should teams prioritise manual review over auto-merge for security PRs?
A: Teams should prioritise manual review when the change affects sensitive control points, has uncertain compatibility, or could alter authentication, data handling, or runtime behaviour.
Q: What are the signs that integrated security automation is failing?
A: The warning signs are repeated manual rework, duplicated investigations, inconsistent case notes, and containment actions that happen after the attacker has already moved on.
Practitioner guidance
- Implement fix-quality triage before opening PRs Suppress low-confidence findings and only generate remediation pull requests for vulnerabilities that are real, exploitable, and likely to be merged.
- Make automated fixes repository-aware Align suggested changes to local dependency versions, test patterns, coding style, and repository structure so reviewers can validate them quickly.
- Add merge-confidence signals to remediation Attach compatibility evidence, CI outcomes, and risk context to each security PR so developers can judge whether the change is safe.
Bottom line: Automated security fixes fail when they generate pull requests that developers do not trust or cannot review efficiently.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:23 pm
Mergeability is now a security control, not a developer preference. The article shows that fix generation alone does not reduce exposure if the resulting pull requests fail review. In modern AppSec programmes, a remediation workflow that developers routinely reject is functionally equivalent to no remediation workflow at all. The practical conclusion is that security teams should measure whether fixes are accepted, not just produced.
A question worth separating out:
Q: How should security teams reduce access review fatigue without weakening governance?
A: Security teams should reduce review fatigue by shrinking entitlement lists, grouping stable access into lean roles, and using contextual signals to highlight exceptions. Reviews should focus on permissions that do not match peer patterns, business function, or ownership. That keeps humans in the loop while making approvals more accurate and defensible.
👉 Read our full editorial: Automated security fixes are failing the merge test in AppSec