0x06Respond

Secret exposure sweep

Use this when credentials may have been committed, logged, or shared, and the exposure needs closing in the order that limits damage rather than the order the scanner reported.

Done when

Every live secret is rotated, the old value is confirmed dead, and the path that leaked it is closed.

Confirmation means the old credential no longer authenticates and the dependent service is healthy on the new one. A secret merely removed from a file is not remediated, because history and clones still carry it.

The cycle

  1. 01Scan current files, history, and build logs for credential-shaped material.
  2. 02Triage each candidate: real or example, still valid, and what it grants — without testing against unauthorized systems.
  3. 03Order live secrets by blast radius and rotate the top one, then revoke the old value.
  4. 04Close the path that leaked it so the same secret cannot return.
  5. 05Confirm the old credential is dead and the service is healthy, then repeat.

repeat from 01 while the evidence improves

Why it holds

Deleting a committed secret does nothing — it stays in history, in forks, in caches, in anyone’s clone. Only rotation ends the exposure. Testing whether a candidate is live first stops the team burning a day rotating example keys, and closing the path that leaked it is what stops the same secret reappearing next week.

Prompt

Work only within [authorized repositories, logs, or systems]. If you need access you do not have, name what is missing and stop. Scan for credential-shaped material: keys, tokens, connection strings, private keys, and passwords, in current files, in commit history, and in build logs and artifacts. Triage before acting. For each candidate, determine whether it is real or an example, whether it is still valid, and what it grants. Never test a credential against a system you are not authorized to touch — prefer the provider’s own introspection endpoint, and if you cannot verify safely, treat it as live. Order confirmed live secrets by blast radius: production data and money movement first, then production infrastructure, then everything else. For the top item, rotate first and revoke second — issue the replacement, cut it over, confirm the service still works, then invalidate the old value. Removing the secret from a file is cleanup, not remediation, and never counts as done on its own. Then close the path: whatever allowed it to be committed or logged, fix that too — ignore rules, a pre-commit check, a redaction filter, a change in how the value is supplied. A rotation without this returns. After each rotation, confirm the old credential no longer authenticates and the service using it is healthy. Stop and ask before revoking anything that would interrupt production, and before any action against a system outside the authorized set. Finish when every live secret is rotated, revoked and verified dead, and every leak path is closed. Report each secret by what it granted, when it was exposed, what was rotated, whether the old value is confirmed dead, and what now prevents recurrence.

  • Local rulesclean
  • Trivyclean
  • Cisco AI Defense Skill Scannerclean

    1 informational

  • NVIDIA SkillSpectorclean

    score 0/100 · safe