Home / Knowledge hub / Secrets management
Knowledge hub
Secrets management
Keeping keys, passwords and tokens out of code and in a vault.
What it means
Secrets management keeps keys, passwords and tokens out of your code and configuration files, and puts them in a system built to hold them. That system issues them briefly, records who asked, and rotates them on a schedule.
The secret still has to reach the application at run time. The difference is that it arrives from a vault at the moment somebody needs it, rather than sitting in a repository forever.
Why it matters
A key committed to source control does not stay in source control. It travels into every clone, every backup and every laptop that ever checked the project out, and it keeps working long after its author leaves.
Rotation carries the other half. If you cannot change a credential quickly, every incident, every departure and every odd log line turns into an argument about disruption. Scope deserves thought as well. A credential that can do everything is convenient right up to the moment it leaks. Logging matters here as well. If nobody can say which service read a credential last month, you cannot tell a real leak from a false alarm.
How it shows up
Look for the small compromises. A key pasted into a deployment script. A password in an environment file somebody committed by accident. A token shared in chat because filing a request took longer. Scan your own history once. Most teams who look find something, and a key committed two years ago still works today. MITRE tracks the pattern as CWE-798.
Hold your tooling to the same rule. Cyberlop resolves scan credentials from your own Azure Key Vault when a run starts, so nothing sensitive sits with us. How we handle credentials.
Questions people ask
Secrets management, answered
Is a .env file good enough?
On one laptop, often. For anything shared, no. Environment files get copied, committed by accident and passed around in chat, and nothing records who read one.
Public code hosts are full of committed .env files with working keys still in them.
How often should we rotate secrets?
Often enough that rotating is boring. Many teams settle on 30 or 90 days for database credentials, and managed services can go considerably shorter.
The interval matters less than the drill. If rotation breaks the application, you will not do it on the day it counts.
Do we need a separate vault if we already use a cloud secrets service?
No. AWS Secrets Manager, Azure Key Vault and their equivalents are vaults, with storage, access control and rotation built in.
Running a second one alongside is usually work without a benefit.
We committed a key and deleted the commit. Are we fine?
No. Treat it as leaked and rotate it today.
The key already sits in every clone, every fork and every backup, and rewriting history reaches none of those.
Where does Cyberlop keep our credentials?
It does not keep them. Cyberlop resolves scan credentials from your own Azure Key Vault when a run starts.
Our security page sets out what that looks like in practice, including what a run does and does not touch.
Sources
Where this comes from
Related
Terms that sit next to this one
Hardcoded secret
A password, API key or token written straight into source code.
Key rotation
Replacing a credential on a schedule so a leaked one has a short life.
Encryption at rest
Stored data scrambled so a stolen disk is useless without the key.
Token
A string that stands in for an identity or a permission.
Where do your scan credentials live?
Cyberlop resolves credentials from your own Azure Key Vault the moment a run starts, and exposed secrets count as one of the ten classes it tests for. Ask how that works.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.