Yes. If you import a repository with its history, every secret ever committed to it comes along, including ones deleted years ago. A monorepo also widens who can read them. Scan the old history before the merge, rotate anything live, and treat history rewriting as a cleanup step, not a fix.
Why the merge makes it worse
In a separate repo, an old leaked key might be visible to ten people. In a monorepo, the same history is visible to everyone with read access to the whole repository, and it is cloned onto many more laptops and CI runners. GitHub's guidance notes that any user with write access to a repository has read access to all secrets configured in it, which is a reminder that repo-level access is the unit of trust. Merging repos merges their trust boundaries.
Steps before you import
- Scan the full history of each source repo, not only the current files. Use a history-aware secret detection tool of your choice. The current checkout tells you nothing about commit 400 of 9,000.
- Triage by liveness. A key that no longer works is a finding to note, not an emergency. A key that still authenticates needs action today.
- Rotate every live credential. Rotation is the control that works. Rewriting history does not recall copies that already exist in clones and forks.
- Decide whether to rewrite. git filter-repo can replace or remove sensitive text, using a file of expressions passed to its replace-text option, with
***REMOVED***as the default replacement. Use it when you want the monorepo to start clean, and remember the tool writes new commits and deletes the originals in that clone. - Import the cleaned clone, not the original.
- Keep a record: which repos were scanned, what was found, what was rotated and when. Auditors and customers ask for that trail.
What rewriting does not do
Rewriting a clone does not change the old remote. Anyone with an old clone still has the secret. Pull requests and forks on a hosting platform may hold references too. This is why the order matters: rotate first, rewrite second. For the deeper argument see secrets in git history: rotate, do not rewrite.
A short decision table
| Situation | Action |
|---|---|
| Secret found, still valid | Rotate now, then decide on rewrite |
| Secret found, already revoked | Note it, optional rewrite |
| Repo has no history worth keeping | Import current state only |
| Large generated files plus secrets | Filter both in the same pass |
Check the neighbours
The same import can carry other risks: committed .env files, private keys, cloud config. Add the file names to your scan rules. Also check that CI configuration in the old repo does not reference secrets that will no longer exist, which is covered in do GitHub Actions secrets move when you consolidate repositories.
For the merged repository itself, Safeguard's asset discovery and SBOM and dependency scanning show what the new repo contains, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
If I delete the file in a later commit, is the secret gone?
No. The file and its contents remain in earlier commits and are imported with the history.
Is rewriting history enough on its own?
No. Old clones and forks keep the original objects. Rotate the credential first.
Sources
Last reviewed: 19 October 2026.
