Eight credential exposure patterns and how to respond

Updated October 3, 2026. This is a practical summary of eight credential exposure patterns in the NHI Kill Chain series. Earlier versions used precise incident numbers and presented illustrative scenarios as documented breaches. Those claims were not supported by sources, so this version focuses on observable signals and response steps.

Eight ways a credential can become hard to control

Ghost Key: A key associated with someone who has left remains active. Compare directory status with the assigned owner, then check the issuing service before revocation. Shared service keys may need a planned replacement to avoid breaking production.

Shadow Key: A secret appears in a chat, ticket, or document outside its intended store. Record where it appeared, restrict access to that copy, and rotate the key if it may have been read.

Aged Key: A key remains active beyond your own rotation policy. Age alone does not prove compromise; check use, dependencies, and a safe replacement plan.

Over-shared Key: One credential is used by several services or people. Inventory those dependencies before replacing it and issue narrower keys where possible.

Zombie Key: A secret was removed from a file but the credential still works. Repository deletion does not revoke a key. Check history, revoke the old credential at its issuer, and verify the replacement.

Drifted Key: A credential appears in more places than its owner expects. Search connected sources for copies and review each exposure. Reconstructing the path between systems requires logs and human investigation.

Public Key: A live credential is visible in a public repository or page. Treat it as exposed, rotate or revoke it promptly, and inspect the issuer’s access logs. Do not wait for proof that someone copied it.

Unattributed Key: A finding has no confirmed owner. Identify the issuing account and dependent service, assign a person to the response, and retire the key if it is no longer needed.

One response sequence, with different investigations

The common first steps are to locate the credential, check whether it still works, establish an owner, understand its permissions and dependencies, and decide how to replace it. After rotation or revocation, verify that the old key fails and that the intended workload still works. Preserve access logs when misuse is possible.

These names help organize a review; they are not mutually exclusive diagnoses or automatic product classifications. A public key can also be old and ownerless. Use the underlying evidence rather than a label to decide urgency.

What Cremit covers

Cremit Platform scans supported connected repositories, cloud storage, collaboration tools, and container images for exposed credentials. It verifies supported types with the issuing service and helps assign findings. It does not see every credential in an organization, infer every owner, monitor CI runtime activity, or rotate keys automatically. Provider logs, IAM review, and the issuing service remain part of the response.

Sources and further reading

GitHub Docs, secret scanning and response: https://docs.github.com/en/code-security/concepts/secret-security/secret-scanning

GitHub Docs, removing sensitive data from a repository: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository

OWASP, Non-Human Identities Top 10: https://owasp.org/projects/non-human-identities-top-10