The password that sat in production for seven years

Why legacy code is different

Codebases from the early 2000s predate the frameworks that make entire bug classes impossible. There is no ORM parameterizing your queries, no auth middleware, no template engine escaping output. Every page enforces security by hand, which means every page is a chance someone didn't. And the people who wrote it are usually long gone.

Off-the-shelf scanners are tuned for modern stacks. Pointed at a twenty-year-old codebase they do two things at once: drown you in thousands of false positives and miss the idioms that actually matter, because nobody writes detection rules for languages that stopped being fashionable in 2008. So we write our own rules for these stacks, validate them against known-bad fixtures, and put a human on triage. In one review that discipline took the raw finding count down by hundreds while raising confidence in what remained: 479 confirmed findings across 11 repositories.

What we actually find

• Hardcoded authentication bypasses. The worst on record: a URL parameter that, given a specific hardcoded value, let anyone impersonate any user. Added as a debugging convenience, it had been reachable in production for seven years. The fix was one line, raised and merged the same day we found it.
• "Magic password" gates. Dozens of admin pages protected by short hardcoded strings checked inline, the kind of thing that accumulates one page at a time over a decade and never appears in any access review.
• SQL built by string concatenation. Injection isn't an edge case in this era of code; it is the default query pattern.
• Credentials in source. Connection strings, API keys, and shared secrets, committed years ago and rotated never.
• Orphaned-but-reachable tooling. Internal utilities and one-off admin pages that everyone forgot, still deployed, still routable, and never once patched.

Prioritizing with evidence, not severity labels

A 479-item findings list is not a plan. The step that turns an audit into a remediation program is cross-referencing findings against production traffic and database query logs: which vulnerable endpoints are actually being hit, from where, and how often. That converts "here is everything that is wrong" into "if you only fix ten endpoints this quarter, fix these ten," with hour estimates attached.

What an engagement looks like

A full review runs the codebase through our scanning pipeline with custom rules for the stack in question, triages every finding by hand, cross-references against live traffic, and ends with an executive summary a non-engineer can act on plus a technical appendix an engineer can start on Monday. For platforms that keep evolving, the same pipeline runs continuously and flags new findings as code changes.

If your platform predates your framework's security guardrails and nobody has read all of it in years, that is precisely the code we specialize in reading.