Security Basics: Mapping Where Secrets Live Across Your Dev Tools
Most small teams do not lose control of their secrets in one dramatic moment. The exposure builds up quietly: an API key pasted into a configuration file, a token generated for a one-off integration and never revoked, a shared password that lives in a chat thread from two years ago. This article takes a different angle from access-review checklists. Instead of asking who can log in, it asks where your secrets physically sit, how many copies exist, and what a vendor tells you about handling them. The goal is a written map you can maintain, not a one-time cleanup.
Start With a Secret Inventory, Not a Policy Document
Before you write any rules, list the secrets you actually have. A secret, for this purpose, is any credential that lets software or a person act as your organization: API keys, personal access tokens, webhook signing values, database passwords, service account credentials, and the recovery codes attached to shared accounts. Most teams underestimate the count by a wide margin because many secrets were created by someone who has since left, or were generated automatically by an integration that nobody remembers enabling.
Build the inventory by working through the tools your team uses, one at a time. For each tool, check its settings for API keys, integrations, connected apps, and tokens. Look in your code repositories, deployment configuration, CI settings, and shared documents. Record for each secret the tool it belongs to, the purpose it serves, the person or system that created it, and the last time anyone confirmed it is still needed. A spreadsheet is enough. The point is a single list you can review, not a perfect system.
Trace Each Copy of a Secret
A secret that exists in five places is five times as likely to leak as one that exists in one place. For every entry in your inventory, note where copies exist. Common locations include environment variables on a developer laptop, a hosting provider's configuration panel, a CI pipeline's secret store, a password manager entry, a screenshot in a support ticket, and a copy pasted into an AI assistant or a chat window during debugging.
The last location deserves attention. Teams frequently paste logs, config snippets, or error messages into external tools to get help, and those messages often contain tokens. Before pasting anything, scan it for credentials and redact them. If your team uses AI writing or coding assistants, check how each one handles input data by reading its own terms and retention documentation rather than assuming. Write down which tools are allowed to receive which categories of data.
Questions to Ask a Vendor About Their Secret Handling
When you adopt a tool that issues or stores credentials for you, the vendor's documentation should answer several questions. Treat the answers as the basis for your decision, and if a question cannot be answered from public material, put it to the vendor in writing.
Ask how credentials are generated and whether you can scope them to specific permissions or resources. Ask whether tokens expire by default or persist until you revoke them, and how you revoke them. Ask whether the tool displays a secret only once at creation or allows you to view it again later, since the second behavior means the value sits retrievable inside the vendor's interface. Ask how a compromised credential would be detected, and whether the vendor records which token performed which action so you can reconstruct activity afterward. Ask whether there are audit or activity logs available to your team, how long they are kept, and how you export them. Each answer either matches a need in your inventory or reveals a gap you must cover some other way.
Do not infer answers from marketing language. A vendor describing its platform as secure has told you nothing about token scope or log retention. Only specific, documented behavior should influence your decision.
A Checklist You Can Run Each Quarter
Make the inventory a recurring habit. Once a quarter, work through this sequence. First, compare the current inventory against each tool's list of active keys and integrations, and remove anything that no longer has an owner or purpose. Second, rotate any secret that was shared outside the password manager, appeared in a chat or document, or belonged to someone who left the team. Third, confirm that every secret stored in a repository has been moved to a dedicated secret store and that no live value remains in version control history you can still reach. Fourth, re-read the vendor answers you recorded when you adopted each tool, and check whether the vendor's documentation has changed. Fifth, update the inventory with the date of this review.
Keep the review short enough that people actually do it. A thirty-minute session with the list open usually catches the most obvious problems. The value comes from repetition: a map that is updated every quarter stays accurate, while one written once becomes fiction within a year.
Secrets management is less about any single tool than about knowing, at any moment, where your credentials are and who is responsible for them. An honest inventory, a short list of vendor questions, and a regular review will cover most of the risk that small teams actually face.