Source Code and Secrets: The API Key in the Repo Is the Whole Company

Friday night, one file, the whole database

A 12-person SaaS startup ships fast. The founder hires a contractor for a reporting feature, and the contractor is good: three days in, the feature works. It is Friday night, the contractor is vibe coding with an AI assistant, and the assistant helpfully generates a config file so the tests will pass. The file contains the production database connection string, password included, because that is what was in the environment.

The contractor commits everything. The repo he pushes to is the demo fork he created on his personal account, which is public. He does not notice, because he is looking at the passing tests.

Automated scanners run against every public push on the platform, all night, every night. Within a minute the connection string has been harvested. Within an hour someone is running queries against the customer table. By Sunday there is a copy of 31,000 customer records in a place the startup will never see, and on Monday the founder gets an email quoting three of those records back to her with a price.

She asks the obvious question: how? The contractor finds the fork in ten minutes and deletes it. Deleting the fork changes nothing. The password is still the password. The one thing that would have helped, revoking it, has not yet occurred to anyone, because nobody at the company has ever had to do it.

What the heck does this mean

Source code is the recipe for your product. It is also, unless someone has been careful, the place where passwords, tokens and keys get written down so the code will run.

A secret is any credential a program uses to prove it is allowed in: an API key, a database password, a cloud access key, a signing certificate. One secret in the wrong place can open the whole system it belongs to.

A hardcoded secret is one typed directly into the code or a config file, rather than pulled at runtime from somewhere protected. It gets committed, copied, forked and backed up along with everything else.

Secrets sprawl is what happens over years: copies of copies in repos, wikis, chat threads and laptops, none of them tracked.

Revocation is the only fix that works after a leak. The leaked key is dead the moment you revoke it, and not one second before. Everything else, deleting commits, rewriting history, asking nicely, is housekeeping.

A secrets manager is a vault your code asks for the key at runtime, so the key never lives in the repo at all.

The numbers that matter

Twenty-eight point six five million new hardcoded secrets hit public GitHub in 2025, up 34% (GitGuardian State of Secrets Sprawl 2026). The contractor's push was one of roughly 78,000 that day.

AI-assisted commits leak secrets at a rate of 3.2%, against 1.5% for human-only commits (GitGuardian, 2026). The assistant does not know that string is a password. It knows the tests pass.

Sixty-four percent of valid secrets leaked in 2022 were still not revoked in 2026 (GitGuardian, 2026). Four years later, two out of three of those doors are still open. That is the finding that should keep a founder up, because it says most teams never learned to revoke.

What to do this week

1. Revoke and rotate every secret you can find anywhere in the repo history today, old branches and past commits included. If you cannot list them, assume the worst and rotate the database, cloud and payment credentials in that order. (CIS 16 Application Software Security)
2. Turn on secret scanning and push protection on your code platform, so a commit with a key in it is refused before it lands. Most platforms include it at no cost; it takes an afternoon. (CIS 16 Application Software Security)
3. Move secrets out of the code and into a secrets manager or the platform's encrypted environment variables. The rule is one sentence long: nothing that opens a door is written in a file that gets committed. (CIS 3 Data Protection)
4. Give every contractor an account you control, in your organization, with access to the repos they need and nothing else, and remove it the day the contract ends. Personal accounts and personal forks are how the public repo happens. (CIS 5 Account Management)
5. Require a second person to review every change to production, including the config. The reviewer's only job on Friday night was to ask, "why is there a password in this file." (CIS 16 Application Software Security)
6. Write the one-page leak playbook with names: who revokes, who checks the logs, who tells customers, and where the credentials list lives. Then run it once as a drill with a fake key. (CIS 17 Incident Response Management)

Where AccuSights fits

Our assessment reads your repos, pipelines and cloud accounts the way an attacker would, finds the secrets that are already exposed, and hands you a revocation list before anyone else uses it. The Cyber Hygiene Test takes three minutes. A 15-minute call with an engineer will tell you whether your setup would have caught the Friday-night push, and what the fix costs.

We map the assessment to the PDPL and your customers' security requirements, and our read-only compliance agent shows where secrets and customer data sit and which controls have drifted, so you prioritize the right things and keep an eye on them. We have no access and do not remediate; you or your IT partner fix, and we show you where.

Questions people ask

What do I do if an API key is leaked? Revoke it first, within minutes, and issue a new one. Deleting the commit does nothing; the key was copied by automated scanners within seconds of the push and it stays valid until you kill it. Then check the logs of whatever the key opened, the database, the cloud account, the payment provider, for activity you did not do. Then find out how it got there, and fix that, so the next contractor on the next Friday cannot repeat it.

Is a private GitHub repo secure enough? Private is better than public and it is not the same as secure. A private repo is one stolen developer login, one over-permissioned contractor or one accidental visibility change away from public, and secrets inside it are still secrets in plain text. Keep credentials out of the code entirely, in a secrets manager or the platform's encrypted variables, and make the repo private on top of that.

Do SOC 2 auditors look at source code? Not line by line, but they look hard at how it is handled. Expect questions about who can push to production, whether changes are reviewed by a second person, whether secrets are scanned for, how access is removed when someone leaves, and if the logs can be shown. A leaked production password with no revocation record is the kind of finding that turns a clean report into a qualified one.

The code is the company. Treat the password in it the way you would treat the key to the office: never taped to the door, and changed the moment it goes missing.