How Secrets in Code Lead to Security Breaches
Once upon a time, when desktop applications reigned supreme, the security of the application was placed on the shoulders of the end user on his/her desktop. A developer (or team of developers) would create an application and release it to the end users and IT admins, who would, in turn, install the application on their desktops or servers.
As application development has evolved, so has the way code is managed, deployed, and consumed by the end user. Now web applications, containers, and other cloud-based tools have come together to create a flexible, yet more complex and more distributed ecosystem of technologies that depend on one another to function properly. This has introduced a heightened need for security that starts with application development and spans all the way to how the application is consumed by the end user.
With mobile applications, web applications, containers, and Software as a Service (SaaS), security must be shifted left toward the developers in the application development lifecycle. If security is addressed only in the latter stages of application development it could lead to higher development costs to the organization in terms of delays in product deployment and releases due to the additional time needed to address the security issues discovered so late in the process. In addition, if developers are not developing with security in mind, it could lead to applications that are more easily compromised. And given how modern software is deployed, that compromise could lead to a catastrophic conclusion.
One very important task is secrets detection.
What are secrets?
With regards to software, secrets are passwords, encryption keys, API keys, and OAuth tokens that are required for one application service to authenticate against another service. Without these secrets, it would not be possible for one service to trust another service while communicating.
In other words, with modern software, secrets are a necessity.
The problem with secrets is that if they are left in the application code, they can be discovered by nefarious users. In 2019, it was discovered that nearly half of all breaches came from the misuse of credentials that were frequently left inside code. And when these secrets are in repositories housed on GitHub or other cloud-based code repositories, they can fall into the wrong hands. This happens all the time, where hackers (either ethical or not) find keys that are publically available on GitHub. Why is this?
Because those keys are left inside code that is then committed to public repositories.
Why is this such a widespread problem? First and foremost, gitit is both open and permissive. Git also makes it extremely easy to clone code from a remote repository server to a local machine. If that code contains secrets, anyone who has access to the repository will now have access to those secrets. And once a secret has been pushed to a public repository, that secret will remain in the commit history even if that code is never merged into the main branch. This means that technically, that secret can still be found..
Consider this: Your developers write application code that requires an API key to be used to access data in one of your backend servers or services . If that key is left in the code, which is then uncovered by a hacker. That hacker now has the proverbial key to your kingdom and can, quite possibly, access to your backend services.
To make matters worse, your backend servers most likely hold client data. If a hacker has that API key and can access your backend, they can also make off with client information. Do a google search and you’ll find a never-ending list of companies that have been hacked, simply because credentials and access keys were left in code on GitHub.
Think about it this way: A secret is meant to be, well, secret; so why would you want to expose that secret?
What can you do?
Although it takes just a little bit more work, your developers don’t have to leave company secrets in plain view.
There are things your developers can do, to ensure your company secrets aren’t being left in code, and finding their way to public repositories:
● Make sure your developers use a secret scanner pre-commit to find them before the code has been pushed up to the remote code repository. BluBracket Community Edition is a free tool that does precisely this.
● Use a third-party service, such as Vault, to protect secrets and have your application dynamically download the secrets from Vault during runtime only as they are needed.
● Monitor your company’s GitHub account at all times for secrets – this includes both private and public repositories.
● Use automated secret scanning tools (such as BluBracket) on your CICD pipeline and empower your developers to catch and remediate the secrets in their daily development workflow before the code reaches production.
● Vet your developers’ GitHub accounts. A lot of company code ends up in employees’ or contractors’ public repositories. Many times developers copy your enterprise code to their public repositories and unwittingly expose the same secrets which were in your organization’s private repositories to their public repositories thereby putting the entire company and possibly your customers’ data at risk.
● Do not allow the use of public repositories on GitHub (make them all private) and employ a tool to double check for misconfigurations.
● Form a best practice to discourage the hardcoding of secrets in code. Train your developers on why this is important, even if your repositories are all presumably private.
● Scan for secrets in public repositories. If your code has been cloned, chances are high it’ll be found in other locations. There are security tools such as BluBracket which can help you do this.
Conclusion
Once your secrets have been discovered in public repositories, your organization could find itself in a situation where a hacker has either used those credentials to gain access to your network, or to a third-party account associated with your business. In the worst case, that hacker could sell that information, at which point there’s no telling how many ne’er do wells would have access to your data.
Because of this, it’s absolutely imperative that developers not leave secrets within their code. It might take a bit of work at first, but once you’ve integrated a secret scanning solution into your application development process, you will be able to keep secrets out of your repositories for good, security will be top of mind every day and your company will be better off for the effort.
Monitor and Prevent Secrets in Code for Free.
The post How Secrets in Code Lead to Security Breaches first appeared on BluBracket.
*** This is a Security Bloggers Network syndicated blog from BluBracket authored by blubracket. Read the original post at: https://blubracket.com/how-secrets-in-code-lead-to-security-breaches/
