Topic starter
20/08/2026 5:37 pm
TL;DR: Bot-generated security fixes are being merged far less often than human changes, with 37.38% acceptance versus 72.53% for human submissions and some JavaScript security PRs at 13%, according to Pixee. AppSec workflows need fixes that reviewers can verify quickly, or automation just adds more review load without reducing exposure.
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: 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.
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.
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.
Glossary terms: Mergeable Remediation, Approval Fatigue, Context-Aware Remediation, Trust Paradox
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
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