Lesson 23 / 24

A Team Secrets Policy

Write a short policy: where secrets live, who owns them, how often they rotate and how leaks are reported.

One page is enough

A good policy fits on a page and answers practical questions. Rules nobody can remember are rules nobody follows, so keep it short and put it in the repo's docs.

Policy outline

Adapt the numbers to your risk. The point is that every line is something a new teammate can follow on day one.

Storage    All secrets live in 1Password. Never in Git, chat or tickets.
Access     By group, least privilege, reviewed every quarter.
Rotation   Production keys every 90 days and on any suspected leak.
Local dev  op run with .env.1p; no plaintext .env on shared machines.
CI         Service accounts only; no personal tokens.
Reporting  Suspected leak? Tell #security immediately. No blame.

Automate the checks

Back each rule with a tool where you can: pre-commit scanning, push protection, a CI check for committed .env files. A reminder in a document is weaker than a check that fails the build.

Quick check: What makes a secrets policy effective?

  • Being 60 pages long
  • Being short, specific and backed by automated checks
  • Being secret from the team
  • Never being updated
Answer

Being short, specific and backed by automated checks — People follow simple rules, and tools catch the mistakes people miss.