DevSecOps in Practice

Levels of Secrets Leaks

Secret leaks occur when sensitive information, such as API keys, database credentials, encryption keys, or tokens, is inadvertently exposed in code, logs, environment variables, or public repositories. These leaks can be categorized into several types; some of them are easy to detect, while others are more subtle and require advanced scanning techniques. Here are the main levels of secrets leaks:

• Hardcoded Secrets: Storing secrets directly in source code, configuration files, or scripts, often committed to version control (e.g., GitHub) by accident. Attackers can search for these secrets in public repositories using automated tools. If your repository is private, it is still vulnerable to insider threats.

• Secrets in Logs: Logging sensitive data unintentionally, such as credentials or API responses, exposes secrets to logs that may be accessible by unauthorized users. Debug logs, especially, are a common source of leaks. At this level, different types of actions are required: preventing hardcoding secrets, ensuring logs do not contain sensitive data, ensuring debug and traces are not enabled in production if they may contain sensitive data, and more depending on the context.

• Environment Variable Exposure: While storing secrets in environment variables is a common practice, it poses security risks if they are improperly managed, logged, or exposed in error messages and misconfigured applications. Attackers with access to the system or container can retrieve environment variables, potentially exposing sensitive credentials. Instead of passing secrets as plaintext environment variables, they should be stored securely at rest using a secrets management solution (e.g., HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets) and accessed securely at runtime.