2026 Gartner® Magic Quadrant™ for Software Supply Chain Security: 5 takeaways
The Magic Quadrant™ for Software Supply Chain Security is a 45-minute read. Here's what we feel security leaders need to pull from it.
Secrets Management in Software Security
What is secrets management?
Secrets management is the set of practices, policies, and tools that control how sensitive credentials are created, stored, distributed, rotated, and retired across software systems. In a security context, a secret is any piece of information that grants access to a protected resource: API keys, database passwords, cryptographic private keys, OAuth tokens, certificates, and SSH credentials.
Secrets management answers the question of how software components authenticate to each other securely, at scale, without hard-coding credentials into code that developers can read, commit, and accidentally publish.
Secrets management is like a hospital pharmacy
The analogy
A hospital pharmacy holds controlled substances. Medications are not left on open shelves for anyone to take. Access is logged, quantities are tracked, every dispensing event requires authorization, and inventory is audited regularly. The pharmacy does not give out the master key to anyone who asks. Secrets management works the same way for software credentials.
Walk the analogy through:
- The pharmacy vault is the secrets vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Credentials live in one controlled location, not scattered across configuration files, environment variables and developer laptops.
- Dispensing authorization is secrets access control. An application that needs a database password requests it at runtime, provides proof of its identity, and receives only the specific secret it is authorized to access, for a defined time window.
- Dispensing logs are audit trails. Every secret access is recorded: which system requested it, when, and from where. If a secret is misused, a trail exists to investigate.
- Expiring prescriptions are secret rotation. Secrets have a defined lifespan. Rotating them regularly limits how long a stolen credential is useful to an attacker.
- Controlled substance reporting is secrets governance. Organizations must know what secrets exist, who can access them, and whether any have been compromised, just as a pharmacy must account for every controlled substance it dispenses.
Why poor secrets management creates software supply chain risk
Secrets become a supply chain problem the moment they leave the environment they were meant for. That happens more often than most organizations realize. Some examples:
- Hardcoded in source code. A developer hard-codes an API key to make local testing faster. That key is committed to a shared repository. The repository is pushed to GitHub. GitHub is public. The key is now exposed to anyone who searches for it.
- Compiled into binaries. Secrets embedded during the build process end up inside distributed software artifacts. Anyone who reverse-engineers or decompiles the binary can extract them.
- Leaked in container images. Container layers are not encrypted by default. Secrets copied into an image during build, even if removed in a later layer, remain in the image history and can be extracted.
- Exposed in CI/CD logs. Build systems that print environment variables or echo configuration during the build process write secrets into logs that are often accessible to anyone with read access to the pipeline.
Scale of the problem ReversingLabs identified over 40,000 leaked secrets across major open-source repositories in 2023, including API tokens, private keys, and service account credentials embedded inside published packages. Those secrets remain accessible in version history even after a corrective commit removes them from the current codebase. |
Secrets management best practices
Practice | What it means in practice |
|---|---|
Never hardcode secrets | Secrets belong in a vault or injected at runtime through environment variables from a secrets manager. No credential should appear as a string literal in source code. |
Rotate secrets regularly | Automated rotation limits the window an attacker can exploit a stolen credential. Short-lived tokens (minutes to hours) are preferable to long-lived keys wherever the system supports them. |
Scan repositories and binaries | Automated scanning catches secrets before they are committed or distributed. Binary analysis surfaces secrets that made it past source code scanning by catching what is compiled into artifacts. |
Apply least privilege | A secret should grant access only to the specific resource the requesting system needs, with the minimum scope required. A build server credential should not grant production database access. |
Audit and monitor access | Log every secrets access event. Alert on anomalous patterns: unusual access times, unexpected source IPs, access to secrets the requesting system has never previously used. |
Frequently Asked Questions (FAQ)
What counts as a secret in software security?
Any credential that grants access to a protected resource: API keys, database passwords, OAuth and session tokens, SSH private keys, TLS/SSL certificates and their private keys, cloud provider credentials, and encryption keys. Anything that proves identity or enables decryption is a secret that requires managed storage and controlled access.
Is it safe to store secrets in environment variables?
Environment variables are safer than hardcoded strings in source code, but they are not a secrets management solution. Environment variables are often logged, visible to other processes on the same host, and inherited by child processes. A dedicated secrets manager that injects credentials at runtime with short lifespans and access logging provides meaningfully stronger protection.
How do secrets end up inside compiled software?
Developers sometimes embed credentials during the build process: connection strings baked into configuration files that are bundled with the application, API keys passed as build-time arguments that get compiled into binary constants, or tokens included in Docker build steps that persist in container image layers. Binary analysis can detect these embedded secrets even when source code scanning does not.
What should an organization do when a secret is leaked?
Rotate the secret immediately. Treat the leaked credential as fully compromised from the moment it was exposed, not from the moment the leak was discovered. Investigate where the secret was used to determine whether unauthorized access occurred during the exposure window. Review how the leak happened and close the gap before issuing a replacement credential.
