Your code is not just a means for you to deploy an application, it’s also the means by which a hacker can gain access to a network or the data contained within or without. This has become even more apparent with the advent of cloud native development, where a single app or service consists of numerous “moving” parts. Each of those components may or may not have access to a LAN, a database, a server, an API, or any other piece of the puzzle that could include sensitive information.
But how is that access gained? Sometimes through malformed/insecure code or vulnerabilities in the components. In other instances, it can boil down to secrets contained within your code.
What are secrets?
Secrets are bits of code that should remain secret, which enable an app to connect to an external service, account, or application. Secrets are one of most important items within your code, as without them your applications would not have access to other resources.
A study, published back in 2019, by North Carolina State University discovered that over 100,000 public GitHub repositories unwittingly leaked secret keys and that thousands of secret keys are leaked daily.
The last thing you want is to have your secrets either leaked or available for hackers to find.
But what are the most popular types of secrets that are commonly left in code? Let’s take a look.
API keys
An Application Programming Interface (API) key is typically used to help in the tracking and controlling how an API is being utilized by an application. This is done in order to prevent abuse or malicious usage of the API in question. API keys can also be used as a secret authentication token, so the application bearing the key can gain access rights for the API.
Encryption keys
Encryption keys are random strings of characters, created to obfuscate data. These keys are created with algorithms such that every key is unique and unpredictable. Encryption keys are used with a number of applications, such as GPG, SSH, and SSL. These keys are also used in code to hash passwords and other sensitive bits of information.
Oauth tokens
Oauth is an open standard for authorization that can be implemented by anyone. This type of authentication works over HTTPS to authorize devices, APIs, servers, and applications. The Oauth type of authorization uses tokens instead of credentials, making them more secure than the traditional form of authentication.
Certificates
A certificate is a small data file used for security in which the identity, authenticity, and reliability of a website or web application can be verified. Certificates are also known as digital certificates or SSL certificates. These forms of identity verification can be purchased from a Certificate Authority or created locally with a tool like Let’s Encrypt.
Passwords
Passwords (or passphrases) are associated with a user account and give you access to services and applications. The real danger with passwords is that, when used in code, they are in plain text, which could make it very easy for a hacker to break into a network or a server.
How to prevent secrets from being compromised?
There are a few simple things you can do to prevent your secrets from being used against you. Here are just a few tips.
- Encrypt your secrets, no matter if they are at rest or in transit. When you encrypt your secrets, an attacker cannot use them to access the accounts, services, or APIs. When you encrypt your secrets, an attacker cannot use them to access the accounts, services, or APIs without also having the encryption key.
- Never commit secrets to Git repositories. You will have to use secrets in your code at some point. However, you do not want to include those secrets within the code you store on GitHub. Instead, put in placeholders for those secrets.
- Use environment variables for secrets. The placeholders you use for secrets can be in the form of environment variables that can be injected into the code from hidden files or other applications. This advice is in accordance with the 12-Factor App guidelines.
- Use a third-party tool, such as BluBracket’s Community Edition, to detect any secrets found within your code. These applications should consider factors like commit history, false negatives, false positives, monitoring, CI/CD integration, and user experience.
- Instead of storing secrets directly in your code (within the Git repositories), store secrets in a secret manager, such as Hashicorp Vault, AWS Secret Manager, or GCP Secret Manager. Once you’ve done that, connect to the read/write secrets within your vault using the secret manager API.
Conclusion
As a developer, it’s up to you to use secrets intelligently, otherwise you run the risk of exposing information and accounts that could lead to a catastrophic data breach. With just a bit of extra work, you can avoid such an outcome.
