Are environment variables safe for secrets?

They are better than hard-coding and are a common way to pass configuration, but they can leak through logs, error reports, process listings and build output. Load secrets at runtime from a secret store where possible, and keep environment variables out of logs.

What should we do if a key is leaked?

Revoke or rotate it immediately, check logs for misuse, find how it leaked and fix the cause, remove it from code history if needed, and follow your incident response plan, including notification assessments if personal information may be affected. Rotating is essential; deleting the commit alone is not enough.

How often should secrets be rotated?

Prefer short-lived, automatically issued credentials so rotation is continuous. For long-lived secrets, rotate on a schedule that reflects risk and immediately when someone with access leaves or a leak is suspected. Automate rotation where the provider supports it.

Does ZSpace Labs provide security services?

No. ZSpace Labs does not offer penetration testing, managed security or security certification. We apply secrets management practices in the software we build and can work alongside your security provider.

Web Development4 min read

Secrets Management for Software Teams: Protecting API Keys and Credentials

Secrets management for software teams: what counts as a secret, how they leak, secret stores, short-lived credentials, rotation, scanning and leak response.

How should software teams manage secrets?

Keep secrets out of code, chat and documents; store them in a dedicated secret store with access control and audit logs; prefer short-lived credentials issued through workload identity (for example OIDC from CI to the cloud) over long-lived keys; rotate what remains; scan repositories and builds for leaks; and have a tested plan for revoking a leaked key fast. The OWASP Secrets Management Cheat Sheet is a good reference (OWASP).

This guide is for developers and engineering leads. It is educational; ZSpace Labs does not provide security services. For API protection more broadly, see API security best practices.

Key takeaways

No secrets in code, tickets, chat or wikis.
One secret store per environment, with least-privilege access.
Short-lived credentials beat stored keys.
Automated scanning on commits and pushes.
Rotate on schedule and on staff changes.
Practise revoking a leaked key.

How secrets leak

Committed to repositories, including history and forks.
Pasted into chat, tickets or documents.
Printed in logs, error reports and CI output.
Bundled into mobile apps or front-end JavaScript.
Shared between environments and people.
Left in old servers, images and backups.

Secret stores and access

Use your cloud provider's secret manager or a dedicated vault. Separate secrets per environment, grant applications and people only what they need, log every access, and inject secrets at runtime rather than baking them into images. Configuration that is not secret can stay in environment variables, following the separation described by the Twelve-Factor App (12factor.net). Never ship server secrets in mobile or browser code; anything on the device should be considered public.

Short-lived credentials and rotation

Practice	Example
Workload identity	Applications use the cloud role attached to their runtime, with no stored keys
OIDC from CI	Pipelines exchange a signed token for temporary cloud credentials
Dynamic database credentials	Vault-issued usernames that expire
Automated rotation	Secret manager rotates database passwords on a schedule
Scoped API keys	Third-party keys limited to the permissions and IPs needed

Scanning and prevention

Turn on secret scanning in your source control platform; GitHub, for example, scans repositories for known secret formats and can block pushes containing them (GitHub Docs). Add pre-commit hooks, scan CI logs and container images, and mask secrets in logging. Review third-party integrations' access regularly.

When a secret leaks

Revoke or rotate the secret immediately.
Check provider and application logs for misuse.
Find and fix how it leaked.
Remove it from code history if exposed publicly, knowing copies may exist.
Follow your incident response plan, including Notifiable Data Breaches assessment if personal information may be affected; see cyber incident response plans.
Record lessons and add a control to prevent recurrence.

Hypothetical example: a leaked payment key

This example is hypothetical. A developer accidentally pushed a test payment provider key and a production email API key to a public repository. Push protection was not enabled. The team rotated both keys within the hour, checked provider logs, found no misuse, enabled push protection and pre-commit scanning, moved all keys into the cloud secret manager, and switched CI to OIDC so no cloud keys were stored in the pipeline.

Common mistakes

Shared admin keys used by everyone.
Secrets in mobile apps or front-end code.
Deleting the commit instead of rotating the key.
The same secret in every environment.
No owner or expiry for third-party keys.

Infrastructure as code for keeping secrets out of infrastructure files.
Mobile app security for what can live on a device.
Secure web application development for broader practice.
Cloud security posture review for account-level checks.

Conclusion

Good secrets management combines a secret store, short-lived credentials, scanning and fast revocation. Remove secrets from code and conversations, give each workload only what it needs, and practise responding to a leak before you need to.

Building software that handles sensitive keys?

ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on secure web applications and integrations. We do not provide security assurance or penetration testing, but we apply these practices in the software we build.

Start a Project

FAQ

Common questions.

Anything that grants access: API keys, database passwords, cloud access keys, OAuth client secrets, signing keys, certificates' private keys, webhook secrets, encryption keys and tokens for third-party services.