Why engineers don't patch
Part of a short series on the patch loop: who patches, who does not, and what it would take to close the gap. The research behind these posts is my own, and every number links to its source.
Intro
I started from an uncharitable place. It seemed crazy to me that engineers will not do the one thing they are paid to do, which is write code and check that it works, because that is all patching is. You bump a version, you run the tests, you ship. So why does half the industry sit on vulnerable dependencies for a year?
So I went and read the studies, expecting them to confirm my grumbling. They did not. What they show is that engineers patch all the time, quickly, when the work has a certain shape, and that they skip it for months when it has a different shape. The dividing line is not the person. It is the work. Once I saw that, “they will not do their jobs” stopped being an insult and started being a design brief, because every property that makes the work get skipped is a property you can change.
This post is the evidence, and the five levers it hands you.
I. They do merge the bounded ones
The clearest data point is the one that broke my assumption. The MSR 2021 study of Dependabot security pull requests found that most were merged within a day. In the manual sample only 3.2 percent had build breakage. The main reason a PR stayed unmerged was not fear, not laziness, and not severity; it was a concurrent change to the same dependency. Vulnerability severity and breaking-change risk were not strongly associated with merge time. The thing that was associated was prior experience with the bot (MSR 2021).
A follow-up on JavaScript projects found the same: security updates merged within days, more often in projects with tests and CI (study). And here is the part that should bother anyone who thinks the problem is willpower: when developers declined the bot’s PR and fixed the thing by hand, the manual fix took months.
Same people. Same vulnerability. A day when the patch arrives as a bounded, tested PR; months when it arrives as a task.
II. They do not do the unbounded ones
Point those same developers at the unbounded version and the numbers invert. Kula and colleagues, across more than 4,600 projects, found 81.5 percent kept outdated dependencies, and 69 percent of surveyed developers said they were unaware of the vulnerable ones. Developers described updates as “extra effort and added responsibility” and said they were “not likely to respond to a security advisory” (Kula et al., EMSE 2017).
Mirhosseini and Parnin found that automated pull-request notifications made projects upgrade 1.6 times as often, and that the developers’ stated concerns were breaking changes, understanding the implications, and migration effort (ASE 2017). UpgradeAdvisor states the mechanism plainly: developers want the fixes but lack knowledge of the dependency’s internals, so they fear the update will make the application malfunction (OSDI 2022). A 2026 rapid review of 63 studies concluded that developers rarely migrate dependencies unless strongly motivated by a bug, a compatibility need, or a security fix (rapid review).
The gap shows up in the aggregate numbers too. Veracode’s 2025 report, over 1.3 million applications, found first-party flaws have a median half-life of 8 months and third-party flaws 12; the top performers fix half their flaws in five weeks, the bottom quartile takes over a year; the average days to fix rose from 171 to 252; and 70 percent of critical security debt comes from third-party code and the supply chain (Veracode 2025). Snyk saw time to fix open-source vulnerabilities more than double, from 49 days in 2018 to 110 in 2021 (Snyk 2022).
So the behavior is real. It is just conditional.
III. The five properties of the work
Read across those studies and the same five properties keep explaining the outcome. Each is a property of the task, and each is a lever.
Unbounded. “Fix 593 findings” has no end, no version, no file. “Merge this one-line PR that closes eight advisories” has all three. The MSR merge-within-a-day result versus the months-by-hand result is the same work in two shapes, and the shape is the whole difference.
Unowned. Third-party code is “not my code.” In a third of organizations with no open-source policy, nobody is responsible for it at all (Snyk). That is the Veracode gap in one word: third-party flaws live four months longer than first-party ones because no one’s name is on them.
Unrewarded. GitLab’s 2022 survey found 57 percent of security professionals say finding bugs is a developer performance metric, and 56 percent say it is hard to get developers to prioritize remediation (GitLab 2022). No study I could find measures whether patching counts toward promotion. That absence is itself the finding: the metric that exists rewards finding, not fixing. On the other side of the fence, 60 percent of open-source maintainers are unpaid (Tidelift), so the upstream fix you are waiting on is also unrewarded work.
Risk-asymmetric. The developer bears the breakage; security bears the finding. If the upgrade breaks production at 2am, that is the developer’s night, and the reward for a clean upgrade is nothing, because nobody notices maintenance that works. UpgradeAdvisor and Mirhosseini and Parnin both land here: the fear is not the CVE, it is that the fix will quietly break something the developer does not understand. Rational neglect, not negligence.
Invisible. Sixty-nine percent did not know they had the vulnerable dependency. A 252-day average time to fix means, for most of that time, nobody is looking. You cannot act on what never reaches you.
IV. What the evidence does not support
Three things I expected the data to say, that it does not.
It does not say developers are lazy. The same developers merge bounded security PRs within a day. Elastic behavior is not a character trait.
It does not say breaking changes are the main reason security PRs sit. In the one study that actually checked, build breakage in merged Dependabot PRs was 3.2 percent, and concurrent edits and lack of experience with the bot mattered more (MSR 2021). Fear of breakage drives the decision not to attempt a manual upgrade; it is not what stalls an automated one. Those are two different problems.
And it does not say that more findings produce more fixes. The opposite. Volume is what produces the 252-day average and the learned habit of ignoring the report. A dashboard with 593 red rows does not get patched faster than one with eight; it gets patched slower, because it has crossed from a task into a condition you live with.
Conclusion
My opening line was half right. Engineers are not doing the work, but it is not because they will not. It is because, in the shape it usually arrives, the work is unbounded, unowned, unrewarded, risk-asymmetric and invisible, and no rational person pays that tax on a voluntary basis. Change the shape and the MSR data says the same people merge within a day. The behavior is elastic; we keep handing them the inelastic version.
Which raises the obvious question. If the fix is to deliver patches in the shape people already merge, is anyone selling that shape? I spent a while trying every product that claimed to, pointed at one real image, with receipts. The next post is what I found.