“If you want to keep a secret, you must also hide it from yourself.”

You might be surprised to learn that this wise quote comes from George Orwell’s famous 1984, not a ‘how to code’ textbook. Although if developers want to keep sensitive information safe, they should memorize every word.

There’s been a 20% increase in leaked secrets year-on-year, including API keys, passwords, tokens, and other credentials embedded in source code. Once secrets are authenticated, it’s difficult to distinguish between a valid user and a bad actor, and there’s no way of knowing who has discovered the secrets.

Nobody suspects that their personal information and data will fall into the wrong hands, but if it happens, it can be difficult to reverse. As well as the emotional stress on victims, organizations with lax security standards face heavy fines and a PR nightmare. Thankfully, the ramifications are avoidable, and we’ll show you how in this blog.

 

Why Hardcoded Secrets are a Developer’s Biggest Downfall

If you scan a typical organization’s repository and commit history with at least 400 developers, you will find about 1,050 leaks that are unique in nature. That’s 1,050 opportunities for data breaches. Unfortunately, deleting the repository doesn’t make the threat go away. Although the secret will no longer be in the source code, it will still be present in the commit history.

Hardcoded secrets are the itch that you just can’t scratch because they’re everywhere. As engineers use CI/CD pipelines to deploy infrastructure and applications and take cloud-native approaches, vulnerable secrets lurk in the source code, CI/CD workflows, log files, and more. In this instance, you’ll find that your secrets are stored (or forgotten about) in multiple different places, which is when secrets sprawl occurs.

As organizations grow and developers’ workloads get busier, the number of credentials required grows. Where other vulnerabilities show a specific weakness in code and can be fixed, leaked secrets have a way of getting disseminated through the system. They cannot be entirely removed once compromised. What starts as a small splattering of leaked secrets quickly becomes a sprawling spider web of vulnerabilities.

We Shouldn’t Do it, But We Do

Organizations spend a lot of money to protect themselves from such leaks, but they often forget about the most crucial risk: human error.

According to a study by IBM, 95% of all leaks this year were due to human error. No matter how dedicated an engineering team can be in trying to protect leaks from their end, there are always devs who inadvertently leave a password unencrypted in the application code or forget about credentials in plaintext in a git repository.

Devs know it’s bad practice, so why do they hardcode secrets in application code? Undeniably, the world is in high gear, trying to produce software products at a staggering rate. The sooner an organization can churn out a new version or release, the better its chances of success, the bigger its user base will grow, and the quicker it can adapt to user feedback.

It is a race, and developers pay the price for this frenzy. They save secrets in code to save time or simply because they forget. Consequently, anyone with access to the code gets access to the secrets, including developers, end users, or threat actors.

How can a Vault Keep Your Secrets Secure?

A vault stores precious goods like money and gold in the physical world. In the world of software, the concept is the same, except this time, a vault is a tool to store secrets. Let’s discuss some characteristics of a vault and why it’s a better solution than hardcoded secrets.

Centralizing Secrets Management

A vault is a centralized store for secrets. Access is given on an as-needed basis, giving admin authority rather than providing and restricting access. When there is a suspected leak, access to the vault can temporarily be disabled for specific users or projects.

Reducing Unauthorized Access

An audit plugin is an added advantage that some vault solutions offer. Audit plugins display logs detailing who created a secret, when it was used, and who accessed it. Logs are used to keep tabs on secrets usage and control access to them. In this way, the risk of unauthorized access is reduced considerably.

Control Dynamic Secrets

Some vaults provide the ability to share dynamic secrets without long-term access by setting a TTL (time to live) to restrict the access time. You can set a time based on how long the developer may need access to the secrets for programming. When the time clocks out, you can revoke access.

Improved CI/CD

Once secrets are stored in a location where they can be easily accessed, CI/CD becomes quicker. The usage of secrets and velocity of the pipeline increases with secured one-point storage. CI/CD tools can be integrated and used to improve the whole process. It helps to have the CI/CD tool and the vault solution tightly integrated, as this can become a vulnerability.

Lock Your Secrets in a Vault for Good

There are two kinds of vaults – internal and external. External vaults are leased and need to be configured to be integrated into each program. Internal vaults are created and managed in-house, but creating one is a mammoth task. It involves understanding secrets usage and taking responsibility for misuse due to bad vault design, which detracts from the organization’s core mission.

That’s why an external vault is the preferred option for most organizations. An external vault is extremely secure and delivers strong encryption of secrets, but you can tailor your secrets management strategy to suit you. Follow these tips to keep your secrets and wider SDLC secure.

Encrypt Everything You Can

Secrets in plaintext are easy to guess. Encrypted credentials require decryption on the user side to sync and secure your secrets. While encryption prevents unsolicited visitors from viewing sensitive information, it does present a few problems. The lock needs a key, and the key needs protection too. Decryption keys should be stored in a hard-to-guess location and distributed only to users with the right permission.

Choose the Least Privilege Approach

You can limit the attack surface and the risks of human error and internal sabotage by defaulting to the principle of least privilege. This means only granting access to users who require it for the minimum time it takes to complete a task. Although this strategy requires you to manage additional keys, you’ll be able to lock out particular users, constrain actions, and apply rules.

Use Dynamic Secrets

Indefinite credentials and API keys give malicious users plenty of time to exploit your systems. By using short-lived, dynamic secrets, the credentials become moving targets. Dynamic secrets are automatically changed every few minutes, hours, or days, encouraging good secret hygiene, especially if colleagues are not clued up on security. The only problem with this strategy is that refreshing secrets is cumbersome and error-prone, so it, shouldn’t be done manually. Instead, it is best done by a capable vault service. The most robust vault solutions provide the ability to dynamically update secrets in an automated manner.

Choose a Secrets Scanning Tool

As we’ve discussed, human error is often the biggest downfall, and mistakes are common. Even the most stringent developers who follow best practices can benefit from a helpful hand. Although you’ll likely have a remediation plan in place, you can’t fix something if you don’t know it exists. That’s why it’s a good idea to install secrets scanning tools on private and public repositories to give you more visibility over your internal systems.

Automated secret scanning is faster, more accurate, and more efficient than manual checks. It detects secrets burning in history, logs, and source code and enables continuous monitoring to alert you to vulnerabilities. Complete and continuous control over secrets usage and access is crucial. Knowing where the secrets are being used and by whom helps organizations predict the likelihood of secrets sprawl.

Pivoting towards vaults is a crucial step, now more than ever. Unless you protect your secrets in a vault, there is a high probability that your credentials can be compromised due to secret sprawl.

Protect your Secrets with CloudGuard Spectral

CloudGuard Spectral is available as a standalone solution or as a component of CloudGuard CNAPP.

Spectral’s secret scanning tool safeguards IAM frameworks by identifying and remediating vulnerabilities, giving you peace of mind that your code, assets, and infrastructure are protected from malicious actors.

CloudGuard CNAPP provides a fully integrated developer solution that streamlines cloud security operations from code to cloud. With CNAPP, you have a unified platform that not only identifies security issues throughout your pipeline but also provides in-depth insights and context. This allows you to understand effective IAM permissions and privileges and prioritize risks across your entire cloud infrastructure.

Request a demo today.

You may also like