I'm building a decision-making system that receives a possible leaked API key and decides whether to ignore it, verify it, or trigger removal and rotation. It currently considers repository context such as file path, variable names, surrounding code, key format, Git history, whether the code is reachable, deployment context, and the provider's last_used_at value. These signals help estimate whether the value is a genuine credential, but they do not reliably show whether it is still active or has already been revoked. In real DevOps workflows, what evidence do you check before deciding how to handle a flagged key? I'm especially interested in approaches that determine status without authenticating to the provider with the discovered credential.
2 Answers
I’d avoid treating “production” as the deciding factor. Any credential committed or exposed indicates a possible control failure, and the safe default is to revoke or rotate it, investigate its scope and history, and then restore access through a newly issued secret if necessary. Repository context can help prioritize the incident, but it cannot prove that a key is live.
Liveness is ultimately provider-side state, so code and Git history can only provide clues. Prefer non-secret evidence from systems you already control: provider key metadata and revocation status APIs, audit logs showing creation or revocation events, deployment and secret-manager inventories, infrastructure state, and service ownership records. A provider-supported hash or fingerprint of the canonical key can also let you match a discovered value without storing the raw secret, provided the inventory is kept current.
Treat an unknown value as unknown rather than inactive. Use format, location, history, exposure, and deployment evidence to assign risk, then quarantine or rotate it when the potential impact justifies that response. A missing fingerprint cannot establish that the credential is harmless, especially if the inventory was incomplete or the provider does not expose a comparable fingerprint.
The hash approach seems useful for keys that are already registered in the inventory, but I’m unsure what the system should do when a scanned value has no matching fingerprint.