agentsclimarketplace

Secrets management

Skill Amey-Thakur/AI-SKILLS/skills/security/secrets-management

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill secrets-management

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Keep credentials out of source by loading them from a controlled store, scanning for leaks, and rotating on a schedule. Use when adding a secret to an app, cleaning one out of a repository, or setting up how a service reads credentials at runtime.

SKILL.md

2.8 KB, as published. Nobody here has run it

Secrets management

A secret committed to git is compromised the moment it lands, even if you delete it on the next push: the history keeps it and crawlers read history. The job is to keep secrets out of source entirely, load them at runtime from a store you control, and rotate them on a cadence so any leak has a short shelf life.

Method

  1. Move secrets into a vault, not code. Store credentials in HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager, never in source, config files, or Dockerfiles. Reference them by name and fetch at boot or inject them as environment variables through the platform.
  2. Keep .env files local and git-ignored. Add .env to .gitignore before the first commit, check in a .env.example with keys and empty values, and load it with dotenv in development only. A real value must never reach the repository.
  3. Scan every commit and the whole history. Run gitleaks or trufflehog in a pre-commit hook and in CI, then scan the full history once with gitleaks detect --source . --log-opts="--all". The hook stops new leaks; the history scan surfaces old ones.
  4. Rotate on a fixed cadence and after any exposure. Set a 30-to-90-day interval and automate it where the store supports it, such as Secrets Manager rotation functions. Treat any secret that touched a log, a screenshot, or a public repo as burned and rotate it now.
  5. Separate secrets per environment. Give staging and production distinct credentials so a leaked staging key cannot reach production data, and never reuse one API key across services.
  6. Revoke the old value, do not just add a new one. After rotating, disable or delete the prior credential at the provider so a copied secret stops working. Rotation without revocation leaves the leak live.

Checks

  • Does gitleaks detect over the full history return zero findings, or a documented allowlist entry for each?
  • Can you name the last rotation date for every production secret?
  • Would a leaked staging credential fail when tried against production?
  • Is every secret in the repo also in the vault as its source of truth, rather than the repo being the only copy?

Boundaries

This covers application secrets and their lifecycle, not the access policy on the vault itself (see least-privilege) or how a secret is used in a cryptographic operation (see crypto-usage). Rotation cadence and vault choice follow your platform and compliance requirements; when the two disagree, meet the stricter one.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.