“It has logins and user roles” is not the same as “it’s secure.” I found that out the hard way.
When you’re looking at a software company, the security stuff is the part you most want to trust and least can verify. The demo has a login screen, user permissions, the works. Looks locked down. I built one of these, and I’m telling you the login screen tells you almost nothing about whether the doors are actually locked. Here’s what I mean, from real things I found in my own platform. The front door was locked. The back was wide open. The app had logins and permissions, everything a demo shows. Underneath, the actual database rules were written so loosely that one customer’s account could reach another customer’s data. Contact lists, a queue of personal info, credentials. You’d never see it clicking through the product, because the product never offered you the door. It was just unlocked if you knew where to push. “Multi-tenant” and “has a login” are not the same as “customers are actually walled off from each other.” “Internal only” was a comment, not a lock. A bunch of behind-the-scenes machinery, the stuff that pulls in data, runs billing, sends notices, was left open because everyone assumed only the company’s own systems would ever call it. Nothing actually stopped an outsider from calling it. “Internal” was a note someone wrote in the code. It wasn’t a security control. Anyone who knew the address could ring the bell. The master key was sitting in the source code. The one key that unlocks everything, that bypasses all the other security, had been pasted directly into the code, which means it lives in the project’s history forever. It worked great. It also meant anybody who ever got a copy of the code had the keys to the entire kingdom. And here’s the kicker a buyer needs to know. A key that’s been in the code history can’t just be deleted. It has to be changed everywhere it’s used, which is real work someone has to do after you buy. One loose rule let a user promote himself to the top. A single over-permissive setting let a regular user hand himself the highest level of access. Not some exotic hack, just one line of a rule written slightly too open. That’s the thing about the scary security bugs. They’re almost never clever. They’re one small mistake nobody caught. None of this showed up in a demo. The app ran fine. Everything looked professional. The problems were all in the plumbing you can’t see by using the thing. So if you’re buying software, “it has authentication and roles” should be the start of the security conversation, not the end. The real questions are: can you prove one customer can’t reach another’s data? Which of these behind-the-scenes systems are reachable from the open internet? And are the keys sitting in a proper vault, or pasted in the code where they’ll live forever? If you’re under LOI on something and want someone who’s found these exact holes to actually go look under the hood, reach out. First pass is free. It’s what I do now. What’s the worst security surprise you’ve inherited after a deal closed? Curious how people caught it, or didn’t.