Job security-remove-committed-secret-with-rotation-checklist · revised 11 October 2026
Remove a committed secret from your repository, with a rotation checklist
Up to three credentials in one repository are removed from its files and a rewritten history copy, and replaced with configuration. You rotate the keys; forks, clones and cached views are outside it.
You might be seeing
- A key, token or password appears in a file or an old commit, or a scanner reports one
- An environment file was committed and later ignored, but earlier commits still contain it
No passwords, keys, card details or admin invites needed to start.
What usually happened
A credential sits in a repository's files and history. Deleting the line from the latest commit leaves it in every earlier commit and in every clone, fork and pull request, and the credential is still valid until its owner revokes it. The job is the repository side of the cleanup, done after you have revoked or rotated the credentials yourself: remove the values from the current files and from a rewritten copy of the history that you can publish, make the application read them from configuration, and hand over a rotation checklist that records your revocation and lists every place the credential was used. It does not rotate anything or investigate misuse, and it cannot reach copies outside the repository we are given.
Who it’s for: A founder or engineering lead who has found an API key, token or password committed to a repository and wants the code and history cleaned up properly.
Usually starts when: A scanner alert, a contributor or a code review shows a live-looking credential in the repository, or a repository that held one is about to be made public or shared with a customer.
The result: After you have rotated the credentials, a scan of the final branch and of the rewritten history copy finds none of the named secrets, the application builds and passes its tests with placeholder configuration, and you hold a rotation checklist with each item marked by you. You receive the pull request, the history copy and the steps to publish it. Forks, other people's clones, pull-request references and cached views held by the hosting platform are outside that copy.
Check whether this job fits
Answer without pasting any secret, code or alert text. These checks show whether the repository cleanup can be done safely and in the right order.
Checks you can run yourself
List credentials by kind, not by value
Open the scanner alert or review note and write down, for each finding, the service it belongs to and the kind of credential. Do not copy the value into a message, a ticket or an enquiry.
Look for: Three or fewer distinct credentials in one repository fit this job. Many credentials, several repositories or any personal data point to a wider scope. A full scan can find more than your alert listed; those are reported to you, not cleaned, until you agree to widen the scope in writing.
What you get
- A pull request replacing literal values with configuration, an example configuration file with placeholders and the scan configuration
- An occurrence report listing each file and commit location, the kind of credential and whether it is in current files, history or a pull request, with every value redacted
- The rewritten-history copy, the publishing steps and a list of what the rewrite cannot reach: forks, other people's clones, pull-request references and cached views held by the hosting platform, which only you or the platform's support can address
- The rotation checklist for each credential, in the order to do it: your revocation recorded first, then the places it was used, the replacement steps and the checks that follow
- A list of any other credentials the scan found, redacted, with the decision each needs from you
Included
- One repository, or one repository with its open pull requests, and up to three named credentials, each one key, token or password for one service, counted by distinct value; every place a named credential appears in the files, the history and the pull requests we are given is covered
- Find every occurrence in the current files and the history with a secret scanner and a search for the named patterns, and list each location with its value redacted. If the scan finds any credential beyond the named ones, list it redacted and ask you to rotate it, as the stop conditions say
- Replace each use of a literal value in code with configuration read from the environment or the secret store you name, with a placeholder example and no real value
- Prepare a rewritten copy of the history without the values and the exact steps for your maintainer to review and publish; add a secret-scan configuration that catches the next one before it is pushed
- Write a rotation checklist for each credential, built from the scan. Because you revoke or rotate before we receive the repository, the checklist records that step with your date and then covers what the repository shows and you cannot see without it: every file, workflow and deployment setting in the repository that read or held the credential (with a prompt to list the places outside it, such as CI variables, that only you can see), what to put in its place and in what order, how to confirm the old value is refused and the new one works, and which provider logs to review from the date of the first commit that held it
Not included
- Rotating, revoking or replacing any credential: you hold the accounts and do it, and we never receive or hold a replacement key
- Investigating whether anyone used a leaked credential, incident response, forensics, legal advice or regulatory notification
- Removing data from other people's clones, forks, pull-request references or provider caches, or contacting your hosting provider's support for you. The secret can still exist in copies outside the repository we are given, so rotation is what protects you
- Personal data or customer records committed to the repository, which may be a reportable incident needing your own legal advice
- A whole-organisation secrets audit or a review of any other repository
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A scan with the agreed scanner and pattern set finds none of the named credentials in the current files of the final branch and none in the rewritten history copy, including the branches and open pull request heads included in the copy we were given. Pull-request references and cached views held on the hosting platform are outside the rewritten copy and are named as such in the handover.
Evidence: Both scan reports with values redacted, the scanner version and the commit ranges scanned, and the handover's list of what the rewrite cannot reach.
The application builds and its tests give the same pass and fail results as before the change, run with placeholder configuration only, and no literal value remains in code.
Evidence: Build and test output before and after, and the pull request diff.
A rotation checklist exists for every credential in scope. Its first item records that you revoked or rotated the credential, with the date, before we received the repository; the rest list where the credential was used in the repository, the replacement steps in order and the checks that the old value is refused and the new one works, and you mark each item done or not done yourself.
Evidence: The checklist with your own status and dates on each item.
Every other credential the scan reported beyond the named ones is listed redacted with its location and the decision it needs from you, none of them has been changed by us, and the handover says they remain.
Evidence: The redacted list compared with the full scan output, and the diff showing no change to those locations.
The configured secret scan flags a sample commit that contains a harmless fake credential pattern before it can be pushed.
Evidence: The output of the scan run on that sample commit, using an invented value.
No real secret value appears in any deliverable, and your maintainer accepts the pull request and the rewritten history copy.
Evidence: The independent reviewer's deliverable check and your written sign-off.
Sign-off. You check the two scan reports, read the rotation checklist, mark the items you completed, sign off in writing and decide when to publish the rewritten history. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. If a credential cannot be rotated, or misuse is suspected, we stop and say why, and a different scope needs a new written agreement. Credentials the scan finds beyond the named ones are reported, not cleaned, unless you agree a wider written scope.
When it fits, and when we stop
It fits when
- You can identify one repository and the credentials you know or believe were committed
- An authorised person on your side can revoke or rotate each credential in scope, and will do so before we receive the code
- Your maintainer can replace the repository history after reviewing the rewritten copy, and will coordinate with collaborators
- The code can be shared through an authorised company-controlled route after agreement
We stop and tell you if
- You cannot rotate or revoke a credential in scope: removing it from the code would give false comfort while it still works
- There is any sign the credential was used by someone else, such as unexpected access, charges or resources: we stop and ask you to follow your incident process first
- The repository contains personal or customer data as well as credentials
- The history cannot be rewritten and you still want it clean, because there is no other way to reach that result
- The scan finds a credential beyond the ones named: we list it redacted and ask you to revoke or rotate it, and we do not remove it, rewrite history around it or go further on it until you agree a change of scope in writing; until then the handover says it remains
What could go wrong
The code change is one pull request: closing it before merge changes nothing, and after merge your maintainer can revert it. The rewritten history is a separate copy that nothing publishes until you do; keep a full backup of the original before you replace it, because a history replacement cannot be undone once published.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Rewriting history breaks collaborators' clones, open pull requests or signed commits. | The rewrite is prepared on a copy, the affected branches and pull requests are listed, and you choose the timing and tell collaborators to re-clone. Keep a backup of the original. |
| The value stays reachable in forks, other people's clones, pull-request references or cached views even after the rewrite. | The handover lists these limits. Rotation is the control that matters; the history cleanup is housekeeping after it, and any provider-support request is yours to make. |
| Taking the literal value out of the code breaks the application because nothing now provides it. | The code reads from agreed configuration, the build and tests run with placeholders, and you supply the new values yourself. |
| We see a live credential while scanning. | We do not receive the repository until you confirm rotation of the named credentials, work in an isolated workspace, and keep values out of notes, logs and deliverables. |
| The scan finds a live credential you did not name, which you have not rotated. | We list it redacted and ask you to rotate it, keep it out of every note and deliverable, and do not work on it until you agree a change of scope in writing. The handover states that it remains. |
An independent reviewer checks every deliverable for leaked values, checks the rewritten copy against the occurrence report and reads the rotation checklist for gaps. Your maintainer reviews the pull request and the history copy and decides whether and when to publish; nothing is published for you.
Need to keep it working?
Scanning other repositories or the whole organisation, or reviewing how secrets are handled across your systems, is agreed as a separate written scope.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- GitHub's guide says to revoke or rotate the secret first, then explains how to rewrite history with git-filter-repo and what a force push affects. Your maintainer can follow it directly. docs.github.com
- To stop the next one, GitHub's secret scanning push protection blocks a push that contains a detected secret; check whether it is available and enabled for your plan. docs.github.com
Questions
Is removing it from history enough?
No. The credential stays valid until you revoke it, and the value may remain in forks, other people's clones, pull-request references and cached views that a rewritten copy cannot reach. Rotation is what protects the account; the cleanup comes after it, and the job never claims the secret is gone from history everywhere.
What if the scan finds keys I did not tell you about?
We list them redacted and ask you to revoke or rotate them. We do not clean or rewrite around them unless you agree a wider scope in writing, and the handover says they remain.
Can you rotate my keys for me?
No. You hold the accounts and rotate the keys. We never ask for a replacement value and never receive one.
Will you see my secret?
Not if you rotate first, which we require before receiving the repository. The copy then holds only revoked values. We still keep them out of every note, log and deliverable.
What if I think someone already used the key?
Treat it as an incident: revoke it, keep the provider's logs and follow your incident process. This job does not investigate misuse, and we stop if there is a sign of it.
Send an enquiry
Send us
- The hosting platform, whether the repository is public or private, and roughly how many people hold clones
- The kind of credential, such as a cloud access key, a payment test key or a database password, and whether you have already revoked it (yes or no)
- When you think it was committed, in general terms
- Do not send the secret itself, screenshots that show it, the repository or any credential in any form
Later, once you agree
- Your written confirmation that each credential in scope has been revoked or rotated by your authorised person before we receive the repository
- The repository through an authorised company-controlled route, with a branch route for the pull request
- Where the application should read its new values from, described without the values, and the person who will review the history copy
You own the repository, the credentials and the accounts they unlock, and you decide whether to rewrite history. You rotate and hold every key; we never ask for a replacement value. We work on a copy in an isolated workspace through a company-controlled identity, never a personal login, and keep values out of notes and reports.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “security-remove-committed-secret-with-rotation-checklist” as the subject.