Deleting a Leaked Secret Does Not Revoke It

The comment disappeared; the authority did not

A responder pastes a token into Jira, deletes the comment sixty seconds later, and posts “fixed.” The string is less visible, but the token issuer will still accept it. Cleanup changed the representation. It did not change the authority.

OWASP defines a secret lifecycle with creation, rotation, revocation, and expiration in its Secrets Management Cheat Sheet. It says potentially compromised secrets must be securely revoked. The same guidance warns that rewriting git history has operational consequences and does not substitute for lifecycle data.

Run two tracks, with one source of truth

The identity track revokes the token, rotates dependent configuration, and checks logs for use. The content track redacts Jira or Confluence, searches related artifacts, and reduces further distribution. Neither track can be inferred from completion of the other.

A defensible incident record needs at least: credential type, owner, first known exposure, surfaces involved, revocation time, dependent services, validation result, and evidence of suspicious use. Do not paste the secret itself into that record. Store a fingerprint or provider identifier sufficient to correlate events without reproducing the exposure.

The order is a dependency graph, not a ritual

For a standalone API token, immediate revocation is usually safe. For a shared database credential, revoking first may take production down before consumers receive the replacement. Map consumers, create the replacement, update and verify them, revoke the old credential, then confirm old-key failure. During an active intrusion, coordinate sequencing with the incident commander so partial action does not destroy evidence or alert the actor prematurely.

The invariant is simpler than the runbook: after containment, the old authority must fail. “We removed every copy we could find” does not establish that property.

Automate discovery without pretending it is rotation

Secret Sentinel can redact supported leaked credentials in Jira and Confluence and optionally create a Jira incident for high-risk findings. The incident is where ownership, rotation, verification, and closure belong. The product does not call deletion revocation, and neither should the process.

For secrets intentionally shared with developer workloads, envseal reduces the need to send plaintext through collaboration tools. Each recipient has a keypair; encrypted values live in git and can be injected at runtime. If an upstream provider credential is exposed, it still needs provider-side rotation—the encryption layer protects distribution, not an authority already known to an attacker.

Close an incident only when both statements are true: exposed copies have stopped spreading, and the exposed credential can no longer authorize anything.