Over the last three years, Simple Storage Service (S3) buckets in Amazon Web Services (AWS) have leaked a lot of information. An American publishing company for educational content exposed grades and personal information for 100,000 students. A consumer ratings and review website exposed 182 GB worth of data covering American and Canadian senior citizens. Thousands of UK consultants had their passport scans, tax documents, background checks, job applications, and other personal information exposed.
Go back further in time, and S3 has leaked social security numbers, driver’s license information, military secrets, and more. S3 buckets have been considered the leakiest buckets in the world. Until now.
GitHub is the New S3 Bucket
Over the past few months, analysts have started referring to GitHub as the new S3 bucket. This is due to multiple pieces of sensitive data leaking from GitHub repositories, including private repositories that were accidentally exposed to the public due to a misconfiguration. Twitter and Slack have both had code leak out of their GitHub repository. GitHub is known for containing sensitive secrets like 0Auth tokens, API keys, usernames and passwords, encryption keys, and security certificates.
The reasons are many. Sometimes, users make a mistake and accidentally expose private repositories. Other times, the fault is applications that request – and are granted – too much access. Another common scenario centers on a lack of control of who can change repositories and the users who have access to advanced settings.
GitHub Leaks Have a Common Thread
User mistakes are the common denominator across almost every GitHub leak. The application, in a vacuum, is remarkably secure. However, when used in practice developers often hand over the keys to their repositories.
When publicly sharing repositories, users receive a warning message recommending that they revert the setting back and not allow wide access to the code. However, users tend to ignore those types of warnings. One click of the button later, and the repository is public, and the headlines are waiting to write themselves.
A few years ago, the issues caused by leaky S3 buckets were a driving force in the development and growth of CSPM solutions. This response helped improve cloud security. Leaks coming from GitHub and other repository apps are having a similar effect on SaaS security. They have raised awareness of the need for SaaS security, and have helped businesses upgrade their security profile.
Plugging the GitHub Leak
Securing GitHub and preventing them from leaking source code and other information isn’t a particularly complex task. It requires an SSPM to monitor the application’s configurations and share settings. SSPMs provide automated, 24/7 monitoring, and they alert security team members and developers when settings are changed.
There are several high-risk settings to keep an eye on. Two-factor authentication should always be required, protecting the source code from password spray attacks or phishing attacks. Public GitHub pages should be closely watched. Public repositories should be closed to the public; if information needs to be shared with outside users, it should be shared with specific users who need to authenticate themselves before accessing the repository. GitHub keys should be rotated, and be deactivated over a reasonable amount of time.
These configurations are just some of the steps savvy organizations should take to plug their GitHub leaks. Controlling access, implementing data leakage protection, and monitoring key management help shore up the applications, and keep source code and other data safe.
About the writer
