How to remove secrets and credentials from code before licensing it

Why is deleting the file not enough?#

Deleting a file removes it from the latest commit only, while git keeps every earlier version. A database password committed in an old deploy script and removed later is still readable in that commit, in every clone, in old pull request branches and in any archive someone exported.

A licensed code package usually includes history, because commit messages, diffs and review threads are much of what makes engineering records useful for AI. That means the history itself has to be clean, not just the current tree. If history is out of scope, a snapshot of the current code is simpler, but it still needs scanning.

Where do secrets hide in a software company's records?#

Secrets collect wherever engineers needed something to work quickly, and the usual places are predictable. Start the review with the files and systems below, and add any place your own team knows it has cut corners.

• 1Environment and config files: .env files, application settings and connection strings, including commented-out ones.
• 2Infrastructure code: Terraform variables and state files, Kubernetes manifests, Helm values and Docker Compose files.
• 3CI and deploy configuration: pipeline definitions, deploy scripts and build logs that echo variables.
• 4Test fixtures and seed data: sample payloads, recorded API responses and copies of production rows.
• 5Keys and certificates: private keys, signing certificates, SSH keys, Java keystores and mobile app signing files.
• 6Notebooks and scripts: data analysis notebooks with saved outputs and one-off migration scripts.
• 7Content outside normal history: Git LFS objects and submodules, which a plain history scan of the parent repository does not read.
• 8Non-code records: Jira tickets, Slack threads and Confluence runbooks where someone pasted a token to unblock a colleague.

Step 1: scan the full history of every repository#

The first step is a history-wide scan of every repository in scope, using a mirror clone so that all branches and tags are included. A mirror clone from a Git host can also bring hidden pull request refs, which is useful for scanning but has to be decided on before delivery.

Run more than one detector, since each relies on different rules, and add custom patterns for your own token formats, internal hostnames and service account names. Scan the non-code exports that will ship with the package as well; issue trackers, chat exports and wiki pages are text files once exported.

Expect noise in the first results: example keys in documentation, dummy values in tests and tokens revoked long ago. Track every finding in one shared sheet with the repository, commit, file, secret type, whether it is live, an owner and the action taken. That sheet becomes the working record for the next three steps.

Step 2: revoke and rotate before you clean#

Rotation comes before any history rewrite, because a secret that was committed must be treated as exposed no matter how thoroughly it is removed later. Old clones, forks, CI caches and laptops may still hold it.

Work through findings in order of risk: live cloud and database credentials first, then third-party API tokens, signing keys, SSH keys and webhooks. Open a ticket for each, confirm the old value no longer works, and check access logs for use you cannot explain. If a credential belonged to a customer, for example an SFTP login stored in a test fixture, follow your incident process and the customer contract rather than handling it quietly.

Step 3: choose between rewriting and rebuilding#

Rebuilding a separate delivery mirror is usually safer than rewriting the repository your engineers use every day. An in-place rewrite changes commit IDs, breaks open pull requests and forces everyone to re-clone, all for a package that only needs to exist once.

Two widely used open source tools rewrite history, and each has a default that catches teams out. git filter-repo, which the git project now recommends over git filter-branch, expects to run in a fresh clone and stops otherwise; its replace-text option swaps listed strings across every commit, and path filters drop whole directories. BFG Repo-Cleaner, by default, does not modify the contents of the latest commit on your HEAD branch, so the current tip must be cleaned and committed first or the secret survives there.

Step 4: verify the clean copy before release#

Verification means scanning the finished delivery copy with the same tools and rules, then explaining every remaining hit. A finding is closed only when it is removed, rotated or documented as a false positive by a named engineer.

Then check by hand. Search the delivery copy for the exact strings you rotated, open the highest-risk paths, confirm excluded directories are gone, and inspect the repository's own config, because a mirror can keep a remote URL with an embedded token. Record a SHA-256 checksum of the final archive so the reviewed package is provably the one delivered.

• 1Every repository in scope was scanned as a mirror, with all branches, tags and any pull request refs that will ship.
• 2Every finding is marked removed, rotated or documented as a false positive.
• 3Rotated values no longer appear anywhere in the delivery copy, including LFS objects and submodules.
• 4Remote URLs, credential helpers and hooks are stripped from the delivered repository config.
• 5Exports from issue trackers, chat and wikis were scanned with the same rules.
• 6The final scan output and archive checksum are saved with the release record.

Illustrative: a logistics software vendor cleans years of repositories#

Illustrative: a fictional transportation management software company plans to license its engineering history, covering GitHub repositories, pull request reviews and linked Jira issues. The CTO assigns the work to two senior engineers who know the deploy history and gives them the four steps above as a checklist.

The scans surface cloud keys in old deploy scripts, a Slack webhook in CI configuration and a carrier customer's SFTP password inside a test fixture. The team rotates every credential, notifies the carrier under its contract, and builds a release mirror. On that mirror they strip the fixture directory and replace the old keys across history, then rescan until nothing unexplained remains. One infrastructure repository is excluded outright because cleaning it would leave little worth licensing.

How SourceX treats credentials in code packages#

SourceX handles secrets removal in the Preparation step of the SourceX five-step transaction, alongside the removal of personal and confidential details. SourceX never hosts multi-terabyte archives: large repositories remain in the supplier's storage or move on encrypted drives, and the supplier reviews the cleaned mirror before the Approval and Delivery steps.

The scan approach, the rotation record and the final clean-scan result go into the privacy record of the SourceX Evidence Packet. Buyers see that the work was done and verified, never the secret values themselves.