Secrets are meant to be hidden or, at the very least, only known to a specific and limited set of individuals (or systems). Otherwise, they aren’t really secrets. In personal life, a secret revealed can damage relationships, lead to social stigma, or, at the very least, be embarrassing. In a developer’s or application security engineer’s professional life, the consequences of exposing secrets can lead to breaches of security, data leaks, and, well, also be embarrassing. And while there are tools available for detecting source code and code repositories, there are few options for identifying secrets in plain text, documents, emails, chat logs, content management systems, and more.
What Are Secrets?
In the context of applications, secrets are sensitive information such as passwords, API keys, cryptographic keys, and other confidential data that an application needs to function but should not be exposed to unauthorized users. Secrets are typically stored securely and accessed programmatically by the application when needed.
The use of secrets is an essential aspect of securing applications. Unauthorized access to these sensitive pieces of information can lead to security breaches and other malicious activities. To protect secrets, developers, system administrators, and security engineers use a variety of security techniques such as encryption, secure storage, and access control mechanisms to ensure that only authorized users can access them. Additionally, they implement best practices such as regularly rotating passwords and keys and limiting the scope of access to secrets to only what is necessary for the application to function.
Secrets in the Software Supply Chain
Secrets are a critical component of software supply chain security, which encompasses collaboration to deployment, and everything in between.
As an example, Confluence is a popular collaboration tool used by many organizations to store and share information and can be a common source of secret leaks. This is because Confluence allows anyone with access to a page to view its contents, including sensitive information like API keys and passwords (see image below). Additionally, users may accidentally expose secrets by copy-pasting them into Confluence pages or by including them in code snippets or in stored configuration files.
A secret, such as an access key or password, is often the only thing standing between an attacker and sensitive data or systems. Therefore, it's essential to keep these secrets confidential and secure. When secrets are compromised, it can lead to a devastating data breach, which can cause significant financial and reputational damage to an organization.
Secrets are a frequent target of software supply chain attacks. Attackers often target secrets to gain access to enterprise systems, data, or servers. They can easily obtain these secrets if they have mistakenly leaked to a public source. Safeguarding secrets in software supply chain security is essential to ensure that attackers cannot exploit them to compromise enterprise systems and data. Proper secret management can help prevent unauthorized access to critical systems and data, protecting organizations from supply chain attacks.
How Do You Keep Secrets Secret?
To protect against secrets being leaked, you can employ the following practices:
- Use environment variables to store secrets: instead of hardcoding secrets in your code, store them in environment variables. This makes it easier to manage secrets and ensures that they are not accidentally committed to a code repository.
- Use a .gitignore file: Create a .gitignore file to exclude files that contain secrets from being tracked by Git. This will prevent sensitive information from being accidentally committed to a code repository. If following #1 above, make sure if secrets are stored in an environment variable file, that file is specified in .gitignore.
- Use a secrets management tool: a secrets management tool can help securely store and manage application or system secrets. This ensures that secrets are encrypted and only accessible by authorized users.
- Use encryption: encrypt secrets before storing them in code repositories. This provides an extra layer of security and makes it more difficult for attackers to access sensitive information.
- Use two-factor authentication (2FA): Enable 2FA for code repositories to prevent unauthorized access. This adds an extra layer of security and makes it more difficult for attackers to gain unauthorized access to a code repository.
By following these best practices, you can protect yourselves from accidentally exposing sensitive information in our code repositories and source control managers. But what about other systems, such as content management systems, plain text documents, emails, chat logs, and other digital assets not stored in a repository?
Introducing Too Many Secrets by Checkmarx
Too Many Secrets (2MS) is an open source project dedicated to helping people protect their sensitive information like passwords, credentials, and API keys from appearing in public websites and communication services. 2MS supports Confluence today and we will soon be adding support for Discord. In addition, it’s easily extensible to other communication or collaboration platforms as well.
Installing and running 2MS is extremely quick and simple. Built in Go, all you need is to clone the repository, build the project, and run the binary against your platform. Below is the list of commands I used to get up and running on OSX (using Bash 5.1.16):
# brew install go
# git clone https://github.com/Checkmarx/2ms.git
# cd 2ms
# go build
# ./2ms --confluence https://<MyConfluence>.atlassian.net/wiki --confluence-spaces <MySpace> --confluence-username <MyUsername> --confluence-token <MyToken>
2MS is built on a secrets detection engine (currently gitleaks) and includes various plugins to interact with popular platforms. This means anyone in the open source community can contribute, improve, and extend 2MS quite easily.
We believe that by working together, we can create a more secure digital world. To learn more or download the project yourself, head over to the https://github.com/Checkmarx/2ms, available on GitHub.