Why your codebase is more dangerous than you think
Most engineering teams are sitting on a ticking clock. Vulnerable dependencies, hardcoded secrets, fragile modules — they accumulate silently until something breaks in production. Here's what the data actually looks like.
The illusion of stability
Your service is running. Deployments are green. Users aren't complaining. Everything feels fine.
But "running" and "safe" are two completely different things.
Most codebases accumulate risk the same way — gradually, invisibly, and then all at once. A dependency gets a CVE patch but nobody updates it. A developer hardcodes an API key "just for testing" and it gets committed. A module grows to 3,000 lines and everyone quietly agrees to never touch it again.
None of these things break your service today. But they will.
What we found scanning real repositories
After scanning hundreds of repositories, the patterns are consistent:
- **34% had at least one hardcoded secret** — API keys, tokens, database credentials committed directly to the repo. In many cases, the secret was added years ago and the original developer had long since left the company.
- **61% had at least one critical or high CVE** in their dependencies. Not theoretical vulnerabilities — actively exploited ones with public proof-of-concept exploits available.
- **Every codebase over 2 years old** had at least one module that no current team member fully understood. These are your highest-risk files: high churn, many authors, nobody wants to review PRs touching them.
The compounding problem
Technical debt compounds like financial debt. A vulnerable dependency ignored for 6 months is exponentially more dangerous than one caught in the first week — more systems have integrated with it, more data has flowed through it, and the blast radius of an exploit has grown.
The same is true for secrets. A leaked GitHub token discovered in minutes can be rotated with minimal damage. A token sitting in git history for two years has likely already been scraped by automated scanners that index public repositories.
What "good" actually looks like
A healthy codebase isn't one with zero findings — that doesn't exist. It's one where:
- **Critical and high findings are addressed within days**, not quarters
- **Dependencies are updated on a regular cadence**, not only when something breaks
- **No secrets are stored in code** — environment variables, secret managers, or encrypted storage only
- **High-risk modules are identified proactively** and have owners who understand them
A risk score above 80 is achievable for most codebases with 2-4 weeks of focused effort. Below 60 means you have work to do before your next security incident does it for you.
Start with visibility
You can't fix what you can't see. The first step isn't a refactoring sprint or a dependency update — it's getting an honest picture of where your codebase actually stands.
That's exactly what LegacyCode MRI does. Connect a repository, run a scan, and in a few minutes you'll have a prioritised list of exactly what needs attention and why.
The scan takes less time than your next standup.