How code churn, fragmented ownership, and years of rewrites quietly create security risk.
We found a customer file that kept generating security issues. The code itself wasn’t particularly remarkable, but its Git history was. Years of churn, fragmented ownership, and repeated rewrites revealed a security signal that would never appear in a call graph, architecture diagram, or traditional scanner.
Over time, a surprising number of people had modified that code. Different teams had touched it for different reasons across different eras of the product. An integration needed a new option, a workflow change, and a new deployment option was added. None of those changes looked reckless in isolation. In fact, most of them were probably reasonable at the time.
What caught our attention was the history that produced it.
Adam Tornhill’s Your Code as a Crime Scene has been influential for me because it treats code history as evidence. The core idea is simple: the way software changes over time often tells us more than the current snapshot of the code. Years of software engineering research have shown that code churn is one of the strongest predictors of defect density, while Tornhill extended that conversation into hotspots, ownership, and the human dynamics that shape software systems. The result is a useful reminder that software risk is often behavioral before it is technical.
History turns out to be a surprisingly good security signal.
The Many Hands Pattern
One of the patterns we have become increasingly interested in is fragmented ownership, or the many hands pattern. As revision counts increase, contributor counts naturally rise as well. The interesting cases are the ones where ownership never gets settled. The code becomes communal property, shaped by dozens of reasonable decisions made by people solving immediate problems. Over time, the original assumptions become harder to see, and the code begins carrying institutional knowledge that no individual contributor fully possesses.
That matters because many security failures are not failures of coding ability. They are failures of shared understanding. One engineer assumes a value is trusted because it always has been. Another introduces a workflow that changes where that value originates. A third extends the system without realizing the original boundary no longer exists. No individual change is obviously wrong, but the underlying security contract of the system has quietly changed.
What we often see next is something I think of as security contract renegotiation.
One of the simplest ways to spot it is by looking at cumulative additions and deletions over time. In relatively stable modules, growth tends to dominate. The code expands, but the core design remains recognizable. In unstable modules, deleted lines begin tracking added lines surprisingly closely. The code is not simply growing; it is being continuously rewritten. The team keeps returning to the same area of the system because the abstraction never quite settles into place.
This does not mean the engineering is poor. In many cases, it reflects a business that is evolving rapidly. New customers arrive, requirements change, integrations expand, and the software adapts. The security implication, however, is that the trust boundaries are moving. When a module is repeatedly reworked, the assumptions that originally governed it are repeatedly reworked as well. The code may look clean in its current state while still carrying years of accumulated security debt embedded in the decisions that led there.
None of this shows up particularly well in traditional security artifacts. An architecture diagram will not tell you that fifteen different people have modified a file over the last year. A call graph will not reveal that a subsystem has effectively been redesigned three times in eighteen months. A threat model rarely captures the organizational history that shaped a piece of software. Yet those signals often provide valuable clues about where security risk is likely to concentrate.
The rise of AI-generated software makes these patterns even more relevant. AI increases the number of people who can successfully modify software systems and allows engineers to move much faster across unfamiliar parts of a codebase. That is an enormous advantage, but it also means contributor breadth can grow faster than ownership depth. The code may be moving faster than the institutional memory can keep up with.
As we’ve continued building DryRun Security, one lesson keeps resurfacing: some of the most valuable security signals are hidden in the history of the code. Revisions, contributors, churn, ownership patterns, and repeated rewrites all help explain where risk is likely to emerge. They reveal pressures and behaviors that never appear in a vulnerability report but often explain why vulnerabilities appear in the first place.
Sometimes, the most important thing you can learn about a piece of software is not what it does today. It is whether anyone still owns the story of how it got there. Because eventually there comes a point where everybody has touched it, nobody owns it, and the history of the code becomes as important as the code itself.
