In a code based world, it’s convenient for developers to store static secrets and configuration files containing passwords with the code they develop. Not only is this bad hygiene from a source control point of view, but also from the perspective of weakening the security of your application. Let’s dive in to discover some of the key risks of storing secrets in your code repositories, and what you can do as an application security engineer to uncover unnecessary risk.
First off we need to define what a Secret is: typically, secrets could be…
- API Keys
- Static System Passwords
- Encryption Keys
- OAuth Tokens
- DataBase Passwords
The External Threat:
In July, it was reported that Binance (Crypto Exchange) suffered what is dubbed the “Largest Data Breach in History”. It’s estimated that ~1 billion records were stolen. How did this data breach happen? It all came down to a simple snippet of code, containing secrets – that was then shared on a Chinese blog site. Attackers were subsequently able to use the exposed secrets to escalate privileges and move laterally undetected on the product environment.
Engineering is meant to be a collaborative effort amongst teams – and in some cases, collaborative across an entire community. Code snippets are often shared for troubleshooting purposes, and open source software has become table stakes in a CI/CD world, in order to enable engineering teams to move quickly. Having secrets in your code base only increases the likelihood it will get in the wrong hands (potentially of a threat actor) – and ultimately increases the risk of leading to a data breach.
Once breached, it becomes nearly impossible for your security teams to detect this level of access, because the activity will look normal (legitimate secrets are used!). Until, of course, your data is posted on the dark web for sale…
The Internal Threat:
Developers should not have or need access to production systems – and in theory nor should support engineers (different problem lol). When static secrets are defined in your code base, 3rd party contractors and rogue developers now have the ability to escalate their privileges and gain access to areas of the production systems they should not have access to in the first place (principles of least privileged access).
It’s more important than ever for product security teams to focus on building authentication mechanisms, just in time access solutions, and bring your own key solutions. If there are unprotected secrets in that code it eliminates the effects these solutions will have on the overall risk mitigation for your product, and increases the likelihood of rogue developers (and 3rd party contractors) who will be able to exploit those hard coded secrets to gain unauthorized access to your product and/or data.
What Should I do?
Storing secrets and passwords in your code base (or code repos) are never a good idea, but how do you even start to discover where they might be in the first place?
It starts with connecting your code repositories to a tool that scans and identifies secrets and passwords. The ultimate goal is to discover 100% of your secrets and passwords in your code and quickly remediar them. Whether you use obfuscation in code or authenticated calls to key/certification vault that is external to your production environment, eliminating this risk is an easy win to reduce the overall risk to your customers and product.
And we’ve got you covered: both BigID y Identificación pequeña easily connect to GitHub, GitLab, and BitBucket to scan code repos. We use both machine learning capabilities and out of the box secret detection policies to detect secrets and passwords in your code base to improve your data risk posture… wherever you’re intentionally or unintentionally storing those secrets in the first place.
Autor
