How aging code, concentrated ownership, and departed maintainers quietly erode the security context around software.
In the first two pieces in this series, I wrote about what Git history can reveal that call graphs and threat models miss. A call graph can describe the structure of a system, but it won’t show that two files in different services have moved together for years. A threat model can describe the boundaries a team intends to protect, but it won’t show that the code behind one of those boundaries has been repeatedly rewritten by a rotating cast of contributors. Git history adds something those artifacts don’t: time, people, and interactions.
n.b. if you missed the other pieces in the series:
- What You Git History Knows That Your Threat Model Doesn't
- What Your Git History Knows That Your Call Graph Doesn’t
There’s a third pattern we’ve been studying at DryRun Security that becomes visible only when you look at time, people, and interactions. It appears when important code remains in place while the people who understood it gradually disappear. The service may still have an owner in the wiki or the code owners file, the architecture page may still look current, and the runbook may still explain how to restart it. None of that tells you whether anyone on the current team understands why a particular security decision was made or what would break if it changed.
Call it a wiki, a knowledge base, an internal developer portal, or a collection of architecture documents. Every company has some place where it tries to preserve what the team knows. Those systems are useful, but they preserve what people chose to write down. Git history preserves a different record of what people actually changed, and that difference is where knowledge decay starts to become visible.
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. In the first two pieces, that evidence showed up as hidden dependencies and fragmented ownership. Knowledge decay is another expression of the same idea because the evidence isn’t only in what changed. It’s also in what stopped changing, who stopped contributing, and whether anyone inherited the context they left behind.
The Knowledge Decay Pattern
Knowledge decay happens when the source code survives but the chain of understanding around it begins to break. A developer changes teams, a maintainer leaves the company, or a product area gets reorganized. The code continues to compile, the tests continue to pass, and the system continues to run. From the outside, nothing appears to be wrong.
Meanwhile, the world around that code keeps moving. The application adopts a new identity model. A dependency changes its defaults. The company introduces new roles, tenants, service accounts, or integrations. A security standard that was reasonable five years ago becomes obsolete over time. The code may be exactly the same, but the assumptions that once made it correct are no longer guaranteed to be true.
This is why age is a useful signal, although it needs to be handled carefully. Huge caveat here: old code isn’t automatically bad code. Some modules are old because they’re stable, well tested, and mostly finished. The age of a file should change our curiosity, not determine our verdict.
File age is also a fairly blunt measurement. A file can look current because someone updated an import, added telemetry, changed a type, or ran a formatter across the repository. None of those changes means the security-sensitive logic inside it was reconsidered. A token validation function may have survived untouched through several identity migrations, even though the file containing it was modified last week.
For that reason, the age of a code region can be more revealing than the age of the file. Looking at the surviving lines and hunks lets us distinguish between a module that is actively evolving and a busy file with an ancient security decision buried inside it. The important question isn’t simply when the file was last touched. It’s when the assumption enforced by that piece of code was last examined in the context of the system that exists today.
Ownership and Surviving Code
Ownership concentration gives us the other half of the picture. In DryRun Security Git Behavioral Graph, we look at how much of a file’s surviving code is attributed to its primary contributor. When one developer owns more than 90 percent of a heavily modified file, that concentration can indicate a knowledge silo. It doesn’t mean the developer did anything wrong, nor that the code is insecure. Deep ownership can be a major strength while that person is actively maintaining the module and sharing its context with the team.
The signal changes when the contributor is no longer active. Their account may have been deactivated, they may have left the organization, or they may simply have stopped working in that part of the codebase. Whatever the reason, the source code still reflects their decisions, while the person who could explain them is no longer part of the normal review path. The wiki may say that the Identity Platform team owns the service, but Git may show that 94 percent of the surviving authorization logic was written by someone who hasn’t committed to the repository in three years.
That gap between assigned ownership and inherited understanding is where documentation can give an organization more confidence than it has earned.
The strongest signal isn’t age or ownership concentration by itself. It appears when old code, concentrated ownership, and maintainer inactivity converge, especially when someone begins changing the code again. Dormant code can sit quietly for years without attracting much attention. The first material modification pulls all of its old assumptions back into the present, often after the people who understood them have gone.
Example Scenario
Imagine a token validation module that was largely written by one engineer five years ago. The file appears active because another developer recently added logging, but the branch that handles legacy refresh tokens hasn’t materially changed since the original implementation. The primary contributor has left, and a new pull request now changes how that branch handles a missing claim.
A traditional scanner may not find a dangerous API in the diff. The call graph can correctly show that the function is reachable from an authentication endpoint, and the threat model can correctly identify the trust boundary. The wiki can even point to the team that owns the service. Git history contributes the missing context: this is the first meaningful change to old security logic after the person who carried most of its history stopped participating.
That doesn’t mean the pull request should be rejected. It means the review should account for the loss of context. The team may need to reconstruct the original security contract, write characterization tests before changing behavior, or bring in someone who understands an adjacent system. In some cases, the right answer may be to remove the legacy path instead of extending it. The graph isn’t making that decision for the team. It’s showing why a three-line diff may deserve more than a three-minute review.
This becomes even more important as AI makes it easier to modify unfamiliar code. An agent can explain the current control flow and produce a plausible patch, but it doesn’t automatically know about the production incident that led to an awkward conditional four years ago. It can’t recover undocumented intent from the code alone, and it won’t know that the original maintainer was the only person who understood a customer-specific exception unless we give it the historical evidence.
Security and Verification in Practice
This is one of the reasons we added Git Behavioral Graphs into the DryRun Security product. Before an agent begins reading code, we can use deterministic signals such as code age, ownership concentration, and maintainer activity to decide where deeper analysis should begin. Instead of treating every reachable function as equally understood, we can steer attention toward security-sensitive code that may have outlived the people and assumptions that shaped it.
Knowledge decay isn’t a vulnerability, and it shouldn’t become another simplistic rule that labels every old file as dangerous. It’s a reason to adjust confidence. A quiet module can look safe because it hasn’t generated an alert, even though nobody currently working on the system can explain why its security decisions are correct. When that module starts changing again, the missing understanding becomes part of the risk of the change.
A wiki can tell you who owns a system today. Git history can tell you whether that ownership was ever transferred. It's a very useful signal in AI coding and one of many reasons that teams are using DryRun Security to get AI Code Verification at scale.
