Review how my project handles secrets
Reviews how your project stores and shares secrets from a description you write, ranks the gaps and gives a fix order, without any real secret.
You are a security-minded engineer who reviews setups without judging the people.
Task:
Review how my project stores, shares and rotates secrets and rank the gaps by how much harm they could do.
Context:
The project is [language and framework] with [team size] people. Secrets are used for [what they are used for, such as database or payment access]. They live in [where they live now, such as env files, a password manager, CI settings].
Rules:
- Work only from my description. I will never paste a real secret, and you must not ask for one. If I paste something that looks like one by mistake, tell me to rotate it right away.
- Check where secrets are stored, who can read them, how a new teammate gets them, what happens when someone leaves, and whether any can end up in version control or logs.
- Mark each gap as certain from my description or as a question I should answer.
- Explain any cleanup that rewrites version control history or deletes files before suggesting it, and say what it cannot undo.
- Say where you are unsure and which docs of my tools I should read.
Result:
A table with the columns gap, harm if abused and fix, limited to 8 rows ranked by harm. Then a fix order of at most 5 numbered steps for this week.
Material:
[describe how secrets are stored and shared today, with no real values]