Safety Academy · Story 19 · Leaked keys & credentials

Line deleted. Key still works.

Cleo cleans a bug report. An older copy keeps the secret.

Estimated 5 min read

LEAKED KEYS & CREDENTIALS6 scenes

Cleo prepares a helpful bug report.

Cleo prepares a bug report from a debug log. It contains useful error details and a private credential. She catches the log before posting, then discovers the same credential was already committed to a shared branch.

Cleo

“The log has everything support could need.”

Logs, screenshots and configuration files can contain secrets. Review them before sharing.

The secret was also committed to a branch.

The older commit may already have been read or copied. The scammer does not need the newest version of a file when yesterday’s credential still works. No secret value is shown here.

The Scammer

“Thanks for including the keys with the instructions.”

Illustration: The secret was also committed to a branch.

Treat a published credential as exposed even if no theft is visible.

Cleo deletes the line in the latest commit.

Cleo removes the line from the latest file. The current view looks clean, but earlier history and other copies may retain the credential. Deletion has not revoked access.

Cleo

“It has disappeared. Are we safe now?”

Removing a visible copy does not revoke a credential.

Captain separates cleanup from replacement.

Captain separates secret types. A service credential usually needs revocation and replacement. A wallet private key cannot normally be reset that way; its account must be treated as compromised.

Captain Obvious

“You removed the photograph. Not the spare key.”

Illustration: Captain separates cleanup from replacement.

The response depends on what the secret controls. Do not apply password-reset logic to a wallet key.

The team contains the exposure first.

The team revokes the exposed service credential, replaces it from a trusted environment and reviews its use. They then clean logs and history without assuming every outside copy disappears.

Cleo

“New credential first. Tidier history second.”

Illustration: The team contains the exposure first.

Use a trusted environment for replacement secrets. Limit what each credential can access.

Future reports contain evidence, not access.

Cleo shares a reviewed report with no credentials. If wallet keys were affected, asset migration would follow a clean incident plan. The new habit is checking what a report reveals before publishing it.

Cleo

“Support gets the error. Nobody gets the keys.”

Illustration: Future reports contain evidence, not access.

The habit: after exposure, invalidate what you can and replace what you must.

The useful bit

Deleting a secret from the latest file does not undo its exposure.

Read logs, screenshots and bug reports for secrets before you share them. Keep credentials out of git history.
Give each service credential only the access it needs, and keep it in a secrets manager.
Run automated secret scans before publishing, then read the results yourself. Scanners miss things.

OWASP: managing secrets ↗

I already did this

For a service credential, revoke and replace it, then review access records. For a wallet key, treat the wallet as compromised and follow its incident guidance. Work from a clean environment. Deleting a file cannot remove every copy or restore secrecy.

Sources & further reading

OWASP: managing secrets ↗