Developers can’t seem to stop exposing credentials in publicly accessible code

The credentials exposed provided access to a range of resources, including Microsoft Active Directory servers that provision and manage accounts in enterprise networks, OAuth servers allowing single sign-on, SSH servers, and third-party services for customer communications and cryptocurrencies. Examples included:

• Azure Active Directory API Keys
• GitHub OAuth App Keys
• Database credentials for providers such as MongoDB, MySQL, and PostgreSQL
• Dropbox Key
• Auth0 Keys
• SSH Credentials
• Coinbase Credentials
• Twilio Master Credentials.

Also included in the haul were API keys for interacting with various Google Cloud services, database credentials, and tokens controlling Telegram bots, which automate processes on the messenger service. This week’s report said that exposures in all three categories have steadily increased in the past year or two.

The secrets were exposed in various types of files published to PyPI. They included primary .py files, README files, and test folders.

GitGuardian tested the exposed credentials and found that 768 remained active. The risk, however, can extend well beyond that smaller number. GitGuardian explained:

It is important to note that just because a credential can not be validated does not mean it should be considered invalid. Only once a secret has been properly rotated can you know if it is invalid. Some types of secrets GitGuardian is still working toward automatically validating include Hashicorp Vault Tokens, Splunk Authentication Tokens, Kubernetes Cluster Credentials, and Okta Tokens.

There are no good reasons to expose credentials in code. The report said the most common cause is by accident.

“In the course of outreach for this project, we discovered at least 15 incidents where the publisher was unaware they had made their project public,” the authors wrote. “Without naming any names, we did want to mention some of these were from very large companies that have robust security teams. Accidents can happen to anyone.”

Over the past decade, various mechanisms have become available for allowing code to securely access databases and cloud resources. One is .env files that are stored in private environments outside of the publicly available code repository. Others are tools such as the AWS Secrets Manager, Google Cloud’s Secret Manager, or the Azure Key Vault. Developers can also employ scanners that check code for credentials inadvertently included.

The study examined PyPI, which is just one of many open source repositories. In years past, code hosted in other repositories such as NPM and RubyGems has also been rife with credential exposure, and there’s no reason to suspect the practice doesn’t continue in them now.