Software companies
How to scan code repositories for secrets before licensing engineering history
By SourceX Editorial · Updated
Short answer
To scan code repositories for secrets before licensing engineering history, scan every artifact in the package, not only code: all branches and tags, pull request and review comments, issues, wikis and CI logs. Rotate every live credential first, then decide per finding whether to rewrite history, exclude the item or redact the text, and rescan the delivery copy.
Key takeaways
- Engineering history leaks secrets in discussions and logs as well as in commits, so the scan covers the whole package.
- Rotation is the real protection; cleaning the delivered copy is hygiene on top of it.
- Rewriting history keeps context but changes commit hashes, while exclusion is simpler but can break links between records.
- Keep the scan configuration, findings and sign-off with the release record.
What does a pre-licensing secrets scan cover?#
A secrets scan before licensing engineering history covers every artifact that will leave the company, because licensed engineering packages usually include far more than source files. Pull request descriptions, review threads, issue comments, CI logs and wiki pages all collect pasted tokens, connection strings and console screenshots.
The scope follows the package definition. If the license includes issue-to-fix histories, the scan covers the tracker export and the linked pull requests; if it includes build history, the logs. Scanning only the default branch of each repository misses most of the places where credentials actually hide.
| Artifact | Where secrets typically hide | Scan approach |
|---|---|---|
| Git history | Old commits, deleted files, every branch and tag | Mirror clone, full-history scan |
| Pull requests and reviews | Pasted logs, config snippets, debugging notes | Export the text and scan it as files |
| Issues and tickets | Reproduction steps, customer config, screenshots | Scan text; review image attachments by hand |
| CI logs | Echoed environment variables, failed authentication output | Scan exported logs, not only pipeline files |
| Wikis and runbooks | Setup guides, shared service credentials | Export pages and attachments, then scan |
| Notebooks and data files | Embedded outputs, connection strings | Scan outputs as well as code cells |
Choosing scanning tools#
Choosing scanning tools starts with coverage and license terms, then with how each tool handles verification. Two widely used open-source options are gitleaks and TruffleHog, and code hosting platforms also offer built-in secret scanning on some plans.
Gitleaks is MIT-licensed and detects passwords, API keys and tokens in git repositories, files and standard input; its default configuration held 222 detection rules as of July 2026. In May 2026 its README was updated to say the tool is feature complete, with future releases limited to security patches, which is worth weighing if the scan will be repeated over a long program.
TruffleHog is AGPL-3.0 licensed and says it classifies over 800 secret types across Git, chats, wikis, logs, object stores and filesystems. For secrets it can classify, it can log in to check whether a credential is live. That check sends real authentication requests, so agree with your security lead when and where it runs, especially for credentials that belong to other companies.
The pre-release checklist#
The pre-release checklist puts the steps in the order that prevents rework. Most teams that skip ahead end up scanning twice, because a rewrite or exclusion done before triage has to be redone once live credentials are found.
- Define the package: every repository, tracker project, wiki space and CI system in scope.
- Mirror-clone repositories with all refs, including archived repositories and long-lived forks.
- Export pull request, review, issue and wiki text, plus attachment metadata, into scannable files.
- Run at least one scanner over everything, using a configuration file you keep.
- Triage each finding as live, revoked, test value or false positive, with a named reviewer.
- Rotate live credentials and confirm the old values no longer work.
- Choose rewrite, exclusion or redaction for each remaining finding.
- Rescan the exact delivery copy and compare the results with the first run.
- Record the scan, the decisions and the approver in the release file.
Rewrite, exclude or redact?#
Rewriting history, excluding items and redacting text each remove a secret from the delivered copy, but they cost different things. The right choice depends on how much the surrounding history matters to the package.
Never rewrite the working repository your engineers use. Make every change on a separate delivery copy, keep a mapping from old to new commit hashes, and update references in exported issues and CI records so the links that give engineering history its value still resolve.
| Approach | What it does | Keeps | Costs | Use when |
|---|---|---|---|---|
| Rewrite history | Replaces the secret in every affected commit of the delivery copy | Full commit sequence and diffs | Commit hashes change; links from issues and CI need remapping | The repository's history is central to the package |
| Exclude | Drops the file, commit range, issue or log | Simplicity and certainty | Context around the excluded item | The item adds little or is mostly sensitive |
| Redact in place | Replaces the value with a placeholder in text | Discussion and structure | Needs consistent placeholders and review | Pull request, issue and log text |
Rotate first, then clean#
Rotating credentials comes before cleaning because any secret that was ever committed should be treated as exposed. Removing it from a delivery copy does not remove it from developer laptops, forks, backups or earlier clones.
Rotation is also the step most often skipped when a finding looks old. Confirm each credential is dead by testing it or checking with the service that issued it, rather than assuming a departed engineer's key was revoked. Where rotation is impossible, for example a key for a vendor that no longer exists, record why and exclude the affected material.
Illustrative: a route accounting software company prepares a package#
Illustrative: a fictional software company that sells route accounting tools to beverage distributors decides to license issue-to-fix histories from its core product: Jira issues, linked GitHub pull requests with review threads, and GitHub Actions logs.
The first scan finds credentials in places nobody expected: a review comment where an engineer pasted a staging config, CI logs that echoed a token during a failed deployment, and an archived repository holding an old integration with a distributor's ordering system.
The team rotates the live token and confirms the old integration credential no longer works. It redacts the review comment, excludes the failed deployment logs, and leaves out the archived repository entirely because it contains customer-specific integration code. A rescan of the delivery copy comes back clean apart from documented test values, and the CTO signs the release record.
How SourceX handles credentials in engineering packages#
SourceX handles credentials in the Preparation step of the SourceX five-step transaction, before Approval and Delivery. Scanning runs on the delivery copy, the supplier rotates any live credentials, and customer-specific code is excluded during the Rights step.
The scan configuration, findings, treatments and sign-off form part of the privacy record in the SourceX Evidence Packet, alongside provenance, licensing rights, permitted use and release authorization. The buyer can see what was checked, and the supplier approves what leaves.
Frequently asked questions
Is rewriting history enough if a secret was ever public?
No. If a repository or fork was ever public, assume the secret was copied. Rotate it, check the issuing service's access logs for misuse where they exist, and then clean the delivery copy. Cleaning history protects the licensed package, not the credential itself.
Do archived repositories and forks need scanning?
Yes, if they fall within the package, and often even when they do not, because submodules and references can pull them in. Archived repositories tend to hold older integrations and forgotten credentials, which makes findings there more likely, not less.
What about secrets in screenshots and binary files?
Text scanners do not read screenshots, PDFs or compiled binaries reliably. Exclude binaries the package does not need, and review images attached to issues and pull requests by hand, or extract their text and scan it. Console screenshots are a frequent source of exposed tokens.
Should the buyer run its own scan?
Many buyers do, and it is a useful second check. It does not replace the supplier's scan, because only the supplier can rotate credentials and decide what leaves. Share the scan record so any new finding can be traced and resolved quickly.
Who signs off that the package is clean?
Usually the CTO or a security lead who did not run the scan, so the review is independent. The sign-off should reference the scan configuration, the delivery copy it covered, the findings and their treatment, and the date of the final rescan.
Sources
- Gitleaks is an MIT-licensed tool for detecting secrets such as passwords, API keys and tokens in git repositories, files and stdin; as of July 2026 its default configuration contains 222 detection rules. Source
- On May 21, 2026, the gitleaks README was updated to state that Gitleaks is feature complete and future releases will be security patches only. Source
- TruffleHog, an AGPL-3.0 open-source secret scanner, says it classifies over 800 secret types, can log in to confirm whether a secret is live, and scans Git, chats, wikis, logs, object stores and filesystems. Source
Related resources
- IndustryHealthcare data
- QuestionDo AI companies buy private business data?
- QuestionWho owns enterprise data?
- InsightHow do I de-identify contracts and legal documents for AI training?
- InsightHow do I de-identify internal documentation for AI training?
- InsightHow do I de-identify knowledge base articles for AI training?
See if your company qualifies
A short company assessment. No data uploads are needed.