Deleted file, active credential: investigating a Zombie Key
Source removal does not revoke a credential. Check the issuer, Git history, current owner, and last verification before closing the finding.
On this page(5)
Updated October 4, 2026. The previous version presented a constructed fintech breach, including a transaction count and timeline, as though it were a documented incident. It also incorrectly said GitHub secret scanning examines only current code. This revision removes those claims and describes what a deleted source file and an active credential status actually mean.
A deleted file and a live credential are different records
Deleting a file or replacing a hardcoded value changes a source. It does not change the credential at the service that issued it. A key that remains valid can still authenticate if someone has a copy and the issuer permits that use. Equally, a deleted source record does not prove that the key was leaked, used by an attacker, or copied into every system named in a hypothetical attack path.
Record which source object was deleted, when the deletion was observed, where the credential was first found, and when its active status was last checked. The last check is a point-in-time observation; confirm the current state at the issuer before closing a response. Search other connected and approved sources for copies, including relevant branches, artifacts, and logs where access is authorized.
What GitHub secret scanning does
GitHub states that its secret scanning covers the entire Git history on all branches for supported secret types. Removing a value from the latest file does not make its earlier commit disappear from that history. GitHub also says an alert is not automatically closed when the corresponding token is removed from a repository. An operator must fix the issue and choose a closure reason. Whether validity checks are available depends on the secret type and configuration.
A closed alert is a workflow state, not a guarantee that the issuing service rejected the old credential. Check the alert reason, issuer status, and any security logs. GitHub recommends revoking or rotating an exposed secret before considering a history rewrite. A rewrite can disrupt collaborators and leave old clones or forks; decide whether it is needed after the credential is invalidated.
A response sequence that can be checked
Identify the issuer, the current owner, the credential’s permissions, and dependent workloads. Coordinate replacement with that owner so a production service does not lose access unexpectedly. If the key is exposed and may still work, contain it promptly at the issuer. Recheck that the old value is rejected, then document the rotation or revocation evidence and review issuer logs for use during the relevant window. Note gaps in log coverage rather than treating silence as proof of no use.
For an Amazon RDS master password, the change is handled through RDS and, when configured, Secrets Manager. It is not an AWS IAM access key switched off in the IAM console. The exact procedure depends on how that database credential is managed. Choose a rotation schedule from the credential’s risk and operational requirements; a blanket 90-day maximum is not established by this finding.
What Cremit’s Zombie Key checklist means
The CRE-005 checklist includes a credential when its status is active or manually confirmed active, it has at least one finding, and every associated scanned object is marked deleted. This points to a difference between the observed source state and the last credential status. It does not prove that all historical or external copies are gone, that the issuer status is current, or that an attacker used the key. Cremit does not revoke it automatically. Confirm the latest issuer state and close the incident only after the owner has completed and verified the required action.
Primary sources
GitHub Docs — Secret scanning coverage and remediation
GitHub Docs — Resolving secret scanning alerts
Read next
When the Security Scanner Became the Weapon: A Cyber Kill Chain Analysis of the Trivy Supply Chain Attack
Aqua Security's Trivy was compromised by TeamPCP, cascading into LiteLLM. A 7-phase Cyber Kill Chain and MITRE ATT&CK analysis of how incomplete credential rotation turned a single breach into a five-ecosystem catastrophe.
Public API key in a repository: what to check first
A public commit proves exposure, not misuse. Check validity, permissions, issuer logs, and dependent workloads before closing the incident.
Git secret scanning in 2026: coverage, setup, and response
A practical guide to push protection, history scans, validity checks, and issuer-side response, with GitHub, GitLab, and Gitleaks source links.
Get the next one in your inbox
Monthly NHI security brief from Cremit. One email, high signal.