I recently reviewed the codebase behind a small professional services company’s custom platform. Buried in the source was this: if you send the production system a request with a header named “bypass” and a hard-coded password, you skip login entirely and get administrative access to their production system.
On the call where I explained this to their operations lead, I explained the situation. Right now, I could “hack” your system by making one simple request/ I would never do that, but anyone who reads the source code owns your business, and the secrets were sitting in the repository along with everything else.
Findings like this used to be rare in my world, mostly because nobody was looking. That second part has changed, and I want to share both what we’re finding and a simple approach for thinking about it, because most organizations I talk to don’t have a security sophistication problem. They have a security attention problem.
Nobody’s Villain Story
First, a word about how a backdoor like that gets built, because the instinct is to blame the developer, and I think that’s wrong.
This system was built by one freelance developer, working alone for years, under constant pressure to ship and support the client. When you’re solo, a bypass header is built as a support tool. It lets you get in and fix a customer’s problem at 9 p.m. Plain-text credentials in the code are a convenience when you’re the only person who will ever read the code. Every one of these shortcuts is terrible practice, but they made sense in the moment to someone doing what it took to keep a client running.
The problem is structural. There wasn’t a second set of eyes, no review, no ownership transfer, no one whose job it was to ask uncomfortable questions. Nowadays, developers should be using agents to help with this (but it was built years ago). My intention isn’t to throw the original developer under the bus, but rather to fix the conditions that made his shortcuts inevitable.
The Shed Out Back
When findings like these pile up in custom systems that are meant for internal use, the next problem is triage. Enterprise security tools love severity labels, but I’ve found the labels themselves are close to useless for executives deciding where to spend money. Here’s a model I use with non-technical executives instead:
Think of a shed behind your house that needs to be secured. You can leave the door wide open. You can close it and hang a bad padlock on it. Or you can fit a good padlock and maybe add a camera. Which one you need depends on the door and on what’s in the shed.
- Open doors are things like personal data stored in plain text or application routes reachable without credentials. Close them now. Cost is barely relevant. Risk is extremely high.
- Bad padlocks are things like a library that hasn’t been updated in 15 years on a low-traffic internal system. Real weaknesses, but an attacker needs effort and motive. Weigh the fix against what’s actually behind the door. Sometimes it’s not worth the money, particularly if no easy upgrade exists.
- Good padlocks that could use cameras are your reasonably maintained systems, where the next dollar goes to monitoring and hygiene rather than emergency repairs.
Executives get this immediately. It turns a 40-item findings report into a more understandable conversation, and it stops the common failure mode in which a team spends its limited budget upgrading padlocks while a door stands open.
An Hour of Agent Time
What’s changed recently is the cost of looking (and fixing!).
At the end of a routine status call, a stakeholder at one of our clients mentioned, almost in passing, a couple of applications that hadn’t been touched in years. Our developers pointed AI-assisted scanning tools at those repositories and spent about an hour with them. They found plaintext PII, routes that could be reached without authentication, etc., along with dependencies that were years out of date. All these findings need to be verified, but it’s an eye-opening starting point.
A few years ago, that type of review meant scheduling a senior engineer for days, so it didn’t happen for systems nobody was worried about. Which was precisely the problem, because the systems nobody worries about are where the open doors are. The economics of looking have collapsed, and if you own software that’s been running quietly for years, the cheapest insurance available to you is to have someone look.
Why the Raw Agent Output Can’t Ship
The same tools that found real exposed data will also, with total confidence, flag a string that literally says “PUT_PASSWORD_HERE” as a leaked credential.
It’s funny until you imagine it landing in front of a client executive as a critical finding. The auto-generated severity rankings are hand-wavy too. So we have a human validate every AI-generated critical finding. The agent does the looking. A person decides what’s real, what matters, and what it should cost to fix. In my experience, the validation pass takes a fraction of the time the manual audit would have, so you keep nearly all the economic benefit. Another approach is to actually instruct the agent to generate code to exploit (verify) the vulnerability; that costs more and is risky, so it isn’t our standard.
Bring the Executive a Decision, Not a Discovery
Once you have validated findings, resist the urge to present all of them. The executive who can fund the fix is probably the most overloaded person in the organization.
Validate the technical details with the client’s technical lead first. Then equip him or her to bring her executive one headline finding, a recommendation, and two paths forward. Someone with forty things on his plate doesn’t need a findings report. They need to hear “Credit card numbers in plain text” and choose between path A and path B. I’d bet on his response being some version of what we predicted: I don’t care what it costs, get it done.
Fixing It Doesn’t Solve It
One of our developers made a point during that internal triage conversation that stuck with me. Going in and fixing whatever we deemed critical wouldn’t actually solve the problem the client had raised. Their real problem was that nobody maintains these systems at all.
A hardening project on unmaintained software is temporary by definition. The dependencies drift again. New routes get added by whoever touches the code next. If the diagnosis is “no one owns this,” then the durable fix is an ownership and maintenance arrangement, whether that’s an internal team with real capacity or a standing relationship with a firm like ours. Security debt and maintenance debt are the same debt.
The Uncomfortable Question
I’ll close with the backdrop that keeps me humble about all this. A contact of mine at a food manufacturer described watching ransomware enter through on-premise equipment at one facility and move laterally until three plants were down. Nobody at that company was careless in an unusual way. Someone clicked the wrong email, and the doors between systems were open. Everyone is hackable. The goal isn’t to build a perfect impregnable fortress. The goal is fewer open doors, sensible padlocks, and somebody actually walking the property once in a while.
So, the uncomfortable question: when did someone last look at the systems your business quietly depends on? If the answer is years, or never, the look now costs an hour. I’d start there.