How to scan code repositories for secrets before sharing them

What does a pre-sharing secrets scan need to cover?#

A pre-sharing secrets scan needs to cover everything a recipient could read: every repository in scope, every branch and tag, the full commit history and the non-code files that travel with the code. Scanning only the default branch tells you what is in the code today, not what a reader of the history will find.

Build the scope list before choosing tools. Most missed secrets come from repositories nobody remembered, not from weak detection rules.

• 1Active, archived and forked repositories, including those inherited from acquired products.
• 2All branches and tags kept on the server, not only main.
• 3Configuration and infrastructure files: environment files, CI pipelines, Terraform state and Helm values.
• 4Notebooks, test fixtures, seed data and sample configuration files.
• 5Large files tracked outside normal git storage, if they are in scope.
• 6Wiki repositories and issue attachments, if they will be shared alongside the code.

Gitleaks, TruffleHog and platform scanning compared#

Gitleaks and TruffleHog are the two most common open-source choices, and they suit different jobs. Platform scanning, such as the secret scanning built into GitHub, is useful for ongoing protection, but its coverage depends on your plan and settings, so check the documentation before relying on it for a one-time release.

A practical setup runs gitleaks for broad pattern coverage and TruffleHog with verification for triage, then compares the two result sets. Check the license terms if you plan to embed either tool in your own product rather than run it internally.

Whichever tools you choose, pin their versions for the release scan. Rule sets change between versions, and a rerun with a newer version can produce different findings, which is useful later but confusing in the middle of triage.

Step by step: scanning before a release#

Scanning before a release takes eight steps, from a list of repositories to a scanned, shareable copy. Steps 1 and 2 are where most gaps begin, so give them the most attention.

Keep the scan configuration, tool versions and the commit hash of each mirror with the results. If a question comes up later, you can show exactly what was scanned and rerun it.

• 1Step 1: inventory every repository in scope from the code host's admin view, including archived ones, and record an owner for each.
• 2Step 2: create mirror clones so every branch, tag and ref is present locally, including pull request refs on hosts that expose them, since those can hold commits never merged into main.
• 3Step 3: run each scanner over the full history of each mirror, confirm in its options that it walks every branch and tag rather than only the checked-out one, and save results in a machine-readable format.
• 4Step 4: add custom rules for internal token formats, such as your own service keys or license keys, and rerun.
• 5Step 5: de-duplicate findings across tools and commits so one secret becomes one triage item.
• 6Step 6: triage each finding and assign an owner.
• 7Step 7: rotate live credentials at the source, then decide whether to rewrite history or ship a fresh snapshot.
• 8Step 8: rescan the exact copy you will share and keep the report.

How to triage findings#

Triage turns a long scanner report into decisions. Every finding gets one label, an owner and an action, and nothing is closed without a written reason.

Allow list specific matches by fingerprint rather than disabling a rule, so the same pattern elsewhere is still caught on the next run.

Verification and other operational cautions#

Live verification of secrets needs operational care because it uses the credentials it finds. TruffleHog's live check confirms a secret by attempting to authenticate with it, which means your scan contacts third-party services using credentials that may belong to customers or vendors. Agree internally on when verification runs, from which network and who reviews the results.

Scanner output is itself sensitive: a report lists every secret found, often in plain text. Store reports with restricted access, never attach them to the dataset, and delete working copies once triage is closed.

Plan for tool change as well. The gitleaks README stated in May 2026 that the project is feature complete and that the maintainer's focus is shifting to a separate project, Betterleaks, so new secret formats may not reach its default rules.

Illustrative: a freight software vendor scans before a code license#

Illustrative: a fictional transportation management software vendor prepares its code and code review history for a licensing review. It runs self-managed GitLab, with a monorepo, several archived services and a repository inherited from an acquired routing product.

The first scan of the main branch is clean. The full-history scan of mirror clones finds a cloud access key in an old Terraform state file, a chat webhook in a notebook, test keys in fixtures and a customer's EDI credentials in an archived integration test. The cloud key and the customer credentials are still live.

The CTO rotates both, notifies the customer under its agreement, excludes the acquired product's repository pending a rights review and builds a fresh snapshot of the remaining repositories. The final scan of that snapshot is clean, and the report goes into the release file.

How SourceX approaches code and credentials#

SourceX handles code in the Preparation step of the SourceX five-step transaction, after the Rights step has excluded customer-owned code and third-party material the company cannot license. A secrets scan is part of preparing any code package.

The privacy record and release authorization in the SourceX Evidence Packet note that scans covered full history, which tools were used and that the final scan ran on the delivered copy. The supplier approves the release.