Managing the Risks of Hard-Coded Secrets

Secrets in code refer to software's most sensitive organizational information—things like passwords, API keys, tokens, and cryptographic keys embedded directly within the source code or other vulnerable parts of your software system. 

Protecting these secrets is crucial because, if exposed, they can compromise your system's integrity and confidentiality.

Despite general awareness of the sensitive nature of this data and the massive cost of data breaches, secrets are exposed quite frequently, even within large corporations. For example, in January 2024, a third party discovered a Mercedes-Benz employee's authentication token in a public GitHub repository. This token provided unrestricted and unmonitored access to the company's internal GitHub Enterprise Server source code. 

Another genuine concern today is the questionable security of code written with the assistance of AI tools like CoPilot and ChatGPT and the potential of these tools to generate code with hard-coded secrets. Samsung recently experienced this issue. Their engineers unintentionally shared source code with ChatGPT and internal meeting notes containing trade secrets.

As in these two scenarios, human error is often the reason hard-coded credentials appear in code. Even if your developers use AI to help them code, the prompts still come from a human. And while it might be impossible to guarantee that hard-coded secrets never appear, there are things your development team can do to decrease the chances of this happening. 

Let’s look at how to avoid hard-coding secrets and what you can do to detect and remediate hard-coded secrets quickly. 

Understanding Hard-Coded Secrets 

Hard-coded secrets are typically required for the application to function correctly, but storing them in the code is considered a bad practice for several reasons. If the source code is exposed through a data breach, insider threat, or improper sharing, attackers can easily gain access to secrets.

Hard-coded credentials can also be challenging to update, rotate, or revoke since they require changes to the source code and redeployment of the application. Pushing code containing secrets to version control systems (GitHub, GitLab, etc.) increases the risk of accidental exposure, especially if the repository is public or improperly secured.

Here’s an example in Python that demonstrates a hard-coded secret within the source code:

import requests

# Hard-coded API key
API_KEY = "1234567890abcdef1234567890abcdef"

def fetch_data_from_api():
    url = "https://api.example.com/data"
    headers = {
        "Authorization": f"Bearer {API_KEY}"
    }
    response = requests.get(url, headers=headers)
    if response.status_code == 200:
        return response.json()
    else:
        return None

data = fetch_data_from_api()
if data:
    print("Data fetched successfully")
else:
    print("Failed to fetch data")

In this example, the API key (1234567890abcdef1234567890abcdef) is hard-coded directly in the source code. It poses a security risk because the API key is exposed if the source code is leaked or shared.

Hard-coded secrets can be found in various places within software applications. They often lurk innocuously in source code files, where developers may embed sensitive information like API keys, passwords, or encryption keys directly into the code. 

This practice is sometimes seen in configuration files, where developers may inadvertently or temporarily place sensitive data. Another common area where hard-coded secrets hide is in comments within the code, where developers might leave notes or reminders that inadvertently include confidential information. 

Hard-coded passwords can sometimes be found in deployment scripts or environment-specific configuration files, where developers set up environments without proper consideration for securing sensitive data. 

The inherent danger of hard-coded secrets is that they're not only accessible during runtime. Unlike security vulnerabilities such as cross-site and server-side request forgery, which require active exploitation while the software is running, hard-coded secrets reside directly within the source code. This means that wherever the source code travels—whether cloned, checked out or forked—these secrets travel along with it, complicating tracking and making them vulnerable to exposure.

This characteristic expands the attack surface significantly, encompassing not just the deployed software but also the repositories and the entire software development lifecycle. Incidents involving source code leakage further amplify these already significant security risks, potentially exposing hard-coded secrets to unauthorized access inside and outside an organization's perimeter. This distinctive vulnerability underscores the importance of robust security measures throughout the software development and deployment processes.

Types of Hard-Coded Secrets

Embedded secrets found in your source code can come in various forms, depending on the type of sensitive information required by an application, including: 

• API keys
  
  
• API secret keys used alongside API keys for enhanced security
  
  
• API endpoints that should not be publicly known
  
  
• Passwords
  
  
• Database connection strings
  
  
• Encryption keys
  
  
• Access tokens
  
  
• Private keys for SSL/TLS certificates or other cryptographic operations
  
  
• Secret keys used for signing data, such as JWTs (JSON Web Tokens)
  
  
• SSH keys for secure access to servers
  
  
• Service account keys for authenticating service accounts, often used in cloud environments
  
  
• Session Tokens used to maintain user sessions

How Do Hard-Coded Secrets Occur?

How do developers allow hard-coded secrets to occur if secrets are so sensitive? Sometimes, developers believe that the code is more secure than it is. For example, developers could assume that the risk of hard-coded secrets is low if the code is for internal use only or not exposed to the public.

However, most cases can be attributed to some form of human error. Sometimes developers do something for convenience that could result in hard-coded secrets. For example, developers might hard-code secrets to save time and simplify testing when rapidly developing a prototype or proof of concept. Hard-coded secrets provide immediate access without configuring environment variables or external secret management tools.

They can also be created accidentally. Secrets might be hard-coded temporarily for debugging or testing purposes and then forgotten or overlooked when committing the code. Copying and pasting code snippets from examples or other projects might also inadvertently introduce hard-coded secrets. 

Sometimes, human error results from stress and time constraints. Under tight deadlines, developers might prioritize functionality over security, leading to hard-coding secrets to save time. 

Why Secrets Management Is Important 

Secrets management is a cybersecurity best practice that gives your team better visibility into where their secrets are and how they are being stored and used. Investing in this process allows you to manage and enforce policies that keep secrets associated with your software in check. 

Organizations that successfully manage their secrets can improve security, compliance, and operational efficiency. 

Proper secrets management ensures that sensitive information such as API keys, passwords, and encryption keys are securely stored and only accessible to authorized entities, preventing malicious third parties from gaining unauthorized access to critical systems and data.

Avoiding hard-coding secrets in source code or configuration files minimizes the risk of accidental exposure through code repositories, logs, or application binaries. Controlled access to secrets reduces the risk of insiders (employees, contractors, etc.) accessing sensitive information they should not have access to.

Many industries are subject to regulations for mandating and protecting sensitive information, such as HIPAA and PCI-DSS. Proper secrets management helps organizations comply with these regulations. Secrets management solutions often provide auditing capabilities, allowing organizations to track who accessed or modified a secret, which is essential for compliance and forensic investigations.

A centralized secrets management process allows organizations to manage all secrets from a single location, streamlining operations and reducing complexity. Developers and operations teams can access secrets securely, reducing the likelihood of errors and improving productivity.

How to Avoid Hard-Coded Secrets

You can't guarantee that your development team will altogether avoid hard-coded secrets. However, some best practices and strategies can significantly minimize the chances of hard-coded secrets being introduced into software applications.

• Keep secrets in environment variables instead of embedding secrets in the source code, and retrieve them at runtime within your application. 
  
  
• Replace sensitive information with tokens. These tokens can be stored securely and mapped back to the original data only when necessary. Use a secure token store to manage the mapping between tokens and their original values. 
  
  
• Securely store and manage secrets with tools like AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or Google Cloud Secret Manager. Integrate these tools with your application to automatically fetch secrets as needed. 
  
  
• Restrict access to secrets to only those who absolutely need it, using the principle of least privilege. Implement Role-Based Access Control (RBAC) to manage who can access or modify secrets based on their role within the organization.
  
  
• Configure your continuous integration/continuous deployment (CI/CD) pipelines to securely manage and inject secrets during the build and deployment processes. Use CI/CD tools that support secure secrets management, like GitLab CI/CD variables or Jenkins credentials.
  
  
• Include code reviews and pair programming practices to ensure that secrets are not hard-coded inadvertently. Use security checklists and standards during security code reviews to ensure compliance with secret management practices.

Detecting and Remediating Hard-Coded Secrets 

Secrets can be detected manually, but the process involved requires a lot of time and is error-prone, as many manual processes are. Manual processes include regularly scheduled peer reviews and security-focused checklists during code reviews. 

Developers can manually inspect the code, code comments, and documentation for any hard-coded values that might have been included for debugging purposes.

To automate the process of hard-coded secrets detection, use static code analysis tools. Use linters and static analysis tools configured to flag hard-coded secrets. Codacy’s static code analysis solutions offer secrets detection for various languages via an integration with Trivy, one of the most popular open-source security scanners. 

Some other best practices for detecting hard-coded secrets include: 

• Scheduling regular scans of your codebase using both manual and automated methods.
  
  
• Periodically auditing your git history to detect any previously committed secrets.
  
  
• Developing custom rules and patterns for your specific environment to enhance detection accuracy.
  
  
• Ensure that developers are trained to recognize and avoid hard-coding secrets and to use the detection tools effectively.

Remediation and incident response are also crucial aspects of managing hard-coded secrets and ensuring the security of your systems. Once you’ve found a hard-coded secret, the first and most vital step is to remove it from your system. Replace hard-coded secrets with environment variables or retrieve them from a secure secrets management tool.

Rotation is another crucial process usually outlined in secrets management. When a hard-coded secret is identified, rotate it to a new value to invalidate the old one. Use automated tools to regularly rotate secrets to reduce the impact of any potential exposure.

Hopefully, you’ve caught the hard-coded secret before a third party could find it, as secrets represent highly coveted digital assets for cybercriminals.  However, as part of your secrets management process, you should also create an incident response plan that defines team member roles when hard-coded secrets have been compromised. 

Protect Yourself and Your Customers with Codacy 

Leaked secrets can lead to costly financial, operational, and reputational losses. According to IT Governance's 2024 Data Breaches and Cyber Attacks USA report, IT services and software companies are the most breached sector, with over 4 million breaches already noted in 2024. 

Codacy Security can protect your organization on all fronts with SAST and DAST tools that scan your code from the inside and out to provide industry-leading application security solutions. Codacy also detects secrets with integrated secret detection scans that ensure your most sensitive data stays out of the hands of malicious third parties.

See how Codacy Security improve your organization's security posture by starting a free trial today or booking a demo with one of our security experts.