A secret key was exposed in a repository. Is deleting it enough?

The problem and decision criteria

What should you do when a configuration file containing a production API key reaches a repository? Can you finish by deleting the file, committing the change, and making the repository private?

No. Hiding a file and preventing access with a copied key are different actions. GitHub also recommends revoking or rotating exposed secrets before cleaning sensitive history. Repository cleanup cannot retrieve clones others already copied.^[1]

First stop the exposed credential's ability to exercise permissions. Then update legitimate consumers and investigate issued sessions and activity during exposure. Emergency containment and routine rotation are different operations; whether availability justifies any brief overlap with an old key requires a separate decision.^[3][6]

Identify the key owner and affected work first

Create an incident record when an exposure alert arrives, but do not paste the secret into issues, chats, or screenshots again. Record issuer, account, safely managed key identifier, earliest possible exposure, discovery location, permissions, and actual consumers. Distinguish confirmed times from estimates. OWASP also recommends documenting secret owners, rotation, and dependencies that rotation could interrupt.^[3]

Use these operational questions to populate the record.

• What was exposed? Establish issuer and purpose: API key, OAuth token, JWT signing private key, or TLS private key. Do not infer from file extension alone.
• What can it do? Check whether it permits limited operations, reading or modifying data, or issuing more credentials. Distinguish production/development environments and connected accounts.
• Where did it spread and where is it used? Distinguish public and private repository access and identify application, worker, scheduled job, CI, and external-integration owners.

The incident owner does not wait for all investigation to finish before containment. Treat an exposed valid credential as potentially compromised and investigate consumers while blocking its use.^[2]

Revoke first or deploy a new key first?

OWASP's exposure response principle is rapid revocation and rotation. The distinctions below are editorial decision criteria for applying that principle to service dependencies, not a grace period allowing continued use of an exposed key.^[3]

Containment comes first for public production keys, broad privileges, or unexplained use. There is sufficient reason to disable/revoke with the issuer and block necessary access even if legitimate work stops. Lack of observed exploitation is not a reason to leave an exposed key active. AWS IAM distinguishes deactivation from permanent deletion, allowing immediate invalidation followed by dependency and deletion planning.^[5]

If containment offers choices and interruption would have major impact, a limited transition may be considered. First establish issuer support for overlapping credentials and whether dangerous use of the exposed key can actually be blocked during transition. Only with verified controls and no exploitation signs should an owner, transition deadline, and abort conditions govern deploying the new value first. If controls are uncertain or transition fails, stop using the exposed key. Making the repository private or monitoring alone does not satisfy those conditions.

If the issuer confirms the value already expired or was revoked, unnecessary reissuance is not required. Still investigate activity while it was valid and remaining sessions. Creating a new key does not itself prove the old key is invalid.

Verify rotation at actual consumers, not just in the repository

After closing the exposure route, distribute the new secret through a trusted management path. Changing only the secret store leaves a gap unless consumers are checked. Keep separate completion evidence as follows.

New-value application evidence records which secret version reached which service, required restarts or redeployments, and successful business operations. Check asynchronous workers, scheduled batches, and CI as well as the web UI because their execution timing differs. Use nondestructive validation within owned or explicitly authorized operating scope.

Old-value containment evidence records disabled or revoked status from the issuer's administration interface/API, action time, and scope. Do not reinsert exposed keys into third-party systems to test them. Closing a GitHub alert or removing a string cannot replace this evidence.^[2][5]

Privilege reduction is separate work. In AWS IAM, review permissions assigned to users and roles; a new key string does not reduce them. Limit policies to required actions and redesign identity and authorization boundaries if consumers must be separated.^[6]

Apply the same rule to recovery. Do not reactivate an exposed key because the new deployment fails. Prepare to run old code with new credentials or temporarily disable the feature. Returning to a configuration or image that re-exposes the key is not successful recovery.

API keys, tokens, signing keys, and certificates have different closure conditions

Temporary sessions need separate attention after disabling AWS long-term keys

Investigate whether a long-term key issued AWS STS temporary credentials. AWS documents blocking temporary-credential permissions and revoking IAM role sessions. Role revocation denies permissions to sessions issued before a specified time and also affects legitimate users or jobs sharing that role.^[7][8]

Besides the original key's status, record affected roles, session issuance times, and blocking policies. Consider policy propagation delays and access that continued through other roles. Service-linked roles and sessions managed by IAM Identity Center have different constraints and procedures; do not apply one action indiscriminately.^[7][8]

Separate OAuth reissuance from already issued tokens

Auth0 can revoke refresh tokens used to obtain new tokens. The API and tenant configuration determine whether revocation targets one token or the related grant. Access tokens for APIs and ID tokens carrying user identity cannot be revoked in the same way as server-stored session cookies.^[11][12]

Do not infer that existing access tokens, application sessions, and external service tokens all ended because a refresh token was revoked. Check issuer-specific reissuance and access-blocking scope, and record residual lifetimes and additional controls.

Rotating a signing key is different from withdrawing trust in the old key

Auth0 signing-key rotation does not immediately invalidate tokens signed with the old key; old-key revocation is a separate step. The work also depends on whether applications or API gateways periodically fetch JWKS or pin certificates manually.^[13][14]

For an exposed signing key, verify both issuance with the new key and withdrawal of old-key trust at each verifier. Also identify which legitimate tokens may be rejected or require reauthentication.

Do not confuse a public TLS certificate with a private key

A public certificate and a private key differ. Let's Encrypt logs issued certificates in Certificate Transparency and instructs revocation when the private key is compromised. Suspected key compromise uses the keyCompromise reason.^[15]

For private-key exposure, do not treat reissuance using the same key as a fix. Plan a new key pair and certificate deployment together with old-certificate revocation. Let's Encrypt also describes limited browser checking of revocation information; do not promise that one revocation request instantly blocks every client.^[15]

Extend cleanup beyond Git history

Once credentials lose their authority, clean remaining exposure paths: other branches, tags, historical commits, PR references, forks, and collaborators' clones as well as the current branch. GitHub explains that rewriting history affects hashes, signatures, PR review, and others' work. It is not a task to begin with indiscriminate force pushes.^[1]

Operational scope includes CI logs, build caches and images, deployment artifacts, configurations, test data, and exports. Docker warns that secrets passed through build arguments or environment variables may remain in final images and recommends mechanisms such as secret mounts. Clean current source does not establish that already deployed images are clean.^[16]

Adding a file to .gitignore does not replace cleanup. Git documentation states that already tracked files are unaffected by it.^[4]

Record locations cleaned, locations access-restricted, and copies you cannot directly recall. Do not guarantee deletion of every externally copied value.

Preserve evidence without spreading the raw secret again

Preserve evidence alongside containment without delaying urgent blocking. Before cleaning logs, retain investigation evidence in an access-controlled location. Link its location and identifier instead of pasting secret-bearing logs into ordinary tickets. Design exposed-log cleanup and evidence integrity together.^[3]

AWS CloudTrail identifies request actors and temporary-credential sessions. However, accessKeyId is not always present, and role-session requests contain the temporary credential key ID rather than the original long-term key. Searching one key is therefore insufficient.^[9]

Investigate missing records too. CloudTrail Event history shows 90 days of regional management events and excludes data events. No anomaly there does not establish that data access or exfiltration did not occur. Separately check actually enabled data events and service-log retention.^[10]

Distinguish confirmed key exposure, unexplained activity, confirmed harm, and unresolved impact due to log gaps. Suspicious use warrants investigation of newly created credentials/resources and changed permissions. Normal service after rotation does not prove earlier changes were undone.

Response record: separate service restoration from investigation closure

This design example is not an IXC customer incident or delivery result. Assume an upload service IAM key was found in a public repository and used by web, workers, and CI with access to roles. All completion states, observations, and EV evidence identifiers are fictional. No raw key is used.

The example is service restored, impact investigation still open. Do not change unknowns to no anomaly merely to make every row green.

Prevent the next exposure from causing the same incident

Reduce the need for long-lived keys first. For applications running on AWS, prioritize role-based temporary credentials; grant only necessary permissions where long-lived keys remain necessary.^[6]

Assign every remaining secret an owner, consumers, lifetime, rotation method, and revocation verification. Combine secret storage, least privilege, code/log review, and commit/push detection. Define who changes it and what proves completion instead of only reducing scanner warning counts.^[3]

Internal owners can follow public guidance when issuer administration rights and consumers are clear. Involve security and issuer support early when permissions span accounts, signing-key or derived-session boundaries are unknown, or suspicious activity and log gaps prevent impact assessment. Buying another tool need not precede blocking the exposed key.

The final answer is not that a file was deleted. Explain with evidence which access was blocked, which consumers were restored, which impacts were confirmed, and what remains unresolved.