Your last vendor is still logged into your production

Every time we take over a product that ran with another vendor, one finding repeats itself: production keys held by people who left months ago, secrets committed to the repo, a root account shared by five people. A field note on the access cleanup almost nobody does, and why skipping it gets expensive.

Third day of an audit at a scheduling healthtech, fourteen people on the team, product running for almost three years with an agency that had walked out in January. I ran a secret scan across the git history while my coffee went cold. The terminal spat out twenty-three hits. Six still valid.

An AWS key committed nineteen months earlier, live. A payment gateway credential that could list transactions. A database URL with username and password in plain text, sitting in a config file someone forgot to pull out of version control. None of this was a movie-grade heist. It was all right there, in the repo anyone with access to the company GitHub could clone in thirty seconds.

And here comes the part that bothers founders more than the secret itself: three of the agency’s former contractors were still in the GitHub org. One of them had left eight months back. Nobody revoked anything. Nobody remembered to.

A secret scanner invents nothing. It just reads what was already sitting in the repo history, waiting for someone to look.

Nobody breaks down a door that’s already open

When a founder thinks about security, they picture an attack: someone on the outside, a hacker in a hoodie, ransomware. In practice, the most common risk we run into has no intruder at all. It’s access that got left behind. People who came in to do a job, got a key, shipped the work and left, and the key stayed.

Access is easy to grant and annoying to revoke. Granting it solves someone’s immediate problem, so it happens fast. Revoking it solves nobody’s problem, carries no urgency, and slides to later. And "later" turns into never.

What you’re left with is a pile of open doors nobody mapped. Every former freelancer, the agency that came through, the third-party integration someone wired up on a Saturday night: any of them might still be reaching your database. I’ve written before about the security baseline most SMBs ignore, and access control is the item that goes missing from the list most often.

What we find when we open the inventory

One of the first things we do in an audit is build an inventory of who reaches what. It isn’t a rubber-stamp compliance audit, it’s a dirty list of everything that holds a key. It almost always comes back with the same patterns:

• Secrets in git history: an API key, a database password or a service token that got committed once, reverted in the next commit, and lives in the history forever.
• Former contractor with live access: someone who left but is still in the GitHub org, on the AWS console, in Slack with a bot that still reads a private channel.
• Shared root account: one admin credential five people use, password in a Google Doc, no MFA, no way to tell who did what.
• Hardcoded secrets in the code: instead of an environment variable, the key sits right in the file, sometimes copied across three different services.
• Forgotten third-party dashboard: that SaaS someone signed up for a test in 2023, with read access to the database, and the invoice still landing every month.

Building the access inventory is less glamorous than it sounds: you open drawer after drawer and write down who still has a copy of the key.

None of these needs a genius to exploit. It just needs one wrong person, a disgruntled ex-contractor or a stolen laptop with the repo already cloned, to decide to use what they already hold. And before anyone thinks I’m dramatizing with that "six valid secrets" line: two were from a sandbox environment, I’ll admit, which I only realized after rotating everything. But even cutting it to four live production keys, four is four more than should exist.

Why the cheap vendor never does this cleanup

This is rarely malice or raw incompetence. It’s the incentive working exactly as designed. An agency or a bodyshop that sells hours and ships features gets paid for what shows up on screen. Secret rotation, access revocation, a credential vault: none of that becomes a pretty demo on Friday. It’s invisible work, and invisible work under a contract that pays for visible output simply doesn’t happen.

The scattered freelancer is the same story at a smaller scale. He sets up what he needs to run today, hardcodes the key because it’s faster, and vanishes when the contract ends, leaving the trail behind. The trail doesn’t stay out of bad faith; it stays because nobody in the arrangement owned looking at the whole picture.

Access tends to grow like rack wiring: everyone pulls one more cable to solve today’s problem, and nobody comes back to tidy it up.

A senior embedded squad, which is what we do at Revin, works differently for a decidedly unheroic reason: we’ll still be there next month. A team that maintains what it writes treats access as its own problem, not as someone else’s chore. The account that leaks next year is our account. You can see what that looks like in practice in our cases.

What access discipline actually looks like 🔑

There’s no magic to it. There are a few boring habits, applied without exception. I’ll lay them out in prose, because turning them into bullets here would give the false impression of a closed checklist, when the point is that they hold each other up.

First: secrets live in a vault, never in the code. AWS Secrets Manager, Vault, 1Password for teams, the tool barely matters as long as the key isn’t in the repo. Second: every access is named and minimal. Each person logs in with their own account, with only the permission the work requires, no shared root. Third: someone leaving triggers a revocation checklist the same day, not the following week, the same day. Fourth: the secret scan runs in CI, so a commit carrying a key never reaches main.

None of this dents the budget. What dents it is finding out two years later, in the middle of an incident, that the key that leaked was the same one that opened the whole database. This is the kind of thing we catch in the first read of the code, during the Diagnostic Sprint, usually within the first two weeks.

And yes, some products need almost none of this. If your "system" is a five-page landing site with a contact form, standing up a secret vault is overkill: hire a competent freelancer and be happy. The conversation changes when there’s a customer database, payments in the mix, and people rotating in and out of the team.

The question nobody asks on the way out

When I tell this story, what sticks for most people is the number: twenty-three secrets, six valid. For me what matters is something else. In almost three years, nobody had asked even once, "what does this person still reach after they leave?" It wasn’t one person being careless. It was a hole in the process no vendor owned closing.

So here’s the question for you, founder: the last time someone left your team or your vendor, who checked what stayed open? If the answer is "nobody", that’s fine, it’s the most common case we see. It’s just far cheaper to find out in a calm audit than on a Saturday, with an email from someone telling you they pulled your database.

If you want us to run that sweep before it turns into news, book a call and we’ll open the history together.