name	secret-rotation-plan
description	Find committed secrets and draft a prioritised, step-by-step rotation plan saved to context.
tags	["secrets","gitleaks","remediation","incident"]

Secret Rotation Plan

When secrets have been committed to a repository, finding them is only half the job — each one must be rotated, and rotation has an order and a blast radius. This skill turns a gitleaks scan into an actionable, prioritised plan and records it so the work survives the current session.

Steps

Scan for secrets. Run run_gitleaks over the repository. It reports each finding with its rule, file, line, and a redacted snippet.
Classify each finding. For every secret, determine:
- Type — cloud key, database password, OAuth/API token, private key, …
- Scope — what it grants access to, and how widely.
- Exposure — how long it has been in history, whether the repo is public, whether it appears in more than one place. Use read_file to inspect surrounding code where the snippet alone is ambiguous (e.g. to see which service a token talks to).
Prioritise. Order rotation by blast radius and exposure: production credentials and anything in a public repo first; low-scope or already-expired secrets last. A leaked production database password outranks a dev-only token.
Draft the plan. For each secret, write concrete steps: where to rotate it (which console / secret manager), what to update afterwards (env vars, CI secrets, deployments), how to invalidate the old value, and how to confirm nothing still depends on it. Remember that rotating a secret and purging it from git history are two separate tasks — note both.
Persist the plan. Save it with write_context (e.g. under a name like secret-rotation-plan) so it outlives this session and a teammate can pick it up. Use read_context / list_context first to check whether a prior plan already exists and should be updated rather than duplicated.
Report. Summarise the count and severity of findings, the rotation order, and where the full plan was saved.

Notes

Never print full secret values back to the user; keep them redacted, exactly as the scanner does.
gitleaks scans the working tree the Session is pointed at — secrets that were force-pushed away but linger in forks or backups are out of its reach; say so when relevant.

Más de este repositorio

mismo repositorio

authz-audit

argusappsec/argus

White-box detection of broken authorization (BOLA/IDOR, BFLA, access-control logic flaws) in an API or web codebase. Use when asked to audit authorization, hunt IDOR/BOLA, check object-level or function-level access control, or verify that handlers scope data access to the current principal/tenant. Reconstructs the app's ownership model first, then finds access paths that skip the per-object/per-role check their peers enforce. Static, read-only; delegates injection/secrets/path-traversal to run_semgrep/run_gitleaks.

2026-06-214

pr-quick-check

argusappsec/argus

Fast security pass over a pull request diff — scanners plus a targeted grep for risky patterns.

2026-06-104

threat-modeling

argusappsec/argus

Build a STRIDE threat model of a codebase from its structure and code, using the bundled template.

2026-06-104

Secret Rotation Plan

Steps

Scan for secrets. Run run_gitleaks over the repository. It reports each finding with its rule, file, line, and a redacted snippet.

Classify each finding. For every secret, determine:

Type — cloud key, database password, OAuth/API token, private key, …
Scope — what it grants access to, and how widely.
Exposure — how long it has been in history, whether the repo is public, whether it appears in more than one place. Use read_file to inspect surrounding code where the snippet alone is ambiguous (e.g. to see which service a token talks to).

Prioritise. Order rotation by blast radius and exposure: production credentials and anything in a public repo first; low-scope or already-expired secrets last. A leaked production database password outranks a dev-only token.

Draft the plan. For each secret, write concrete steps: where to rotate it (which console / secret manager), what to update afterwards (env vars, CI secrets, deployments), how to invalidate the old value, and how to confirm nothing still depends on it. Remember that rotating a secret and purging it from git history are two separate tasks — note both.

Persist the plan. Save it with write_context (e.g. under a name like secret-rotation-plan) so it outlives this session and a teammate can pick it up. Use read_context / list_context first to check whether a prior plan already exists and should be updated rather than duplicated.

Report. Summarise the count and severity of findings, the rotation order, and where the full plan was saved.

Notes

Never print full secret values back to the user; keep them redacted, exactly as the scanner does.

gitleaks scans the working tree the Session is pointed at — secrets that were force-pushed away but linger in forks or backups are out of its reach; say so when relevant.