Who Lets Access Keys Out?
Technical data leakage takes on many forms, but often revolves around the publication of passwords or cloud services’ access keys on the internet. Many technical data leakages are not the result of a malicious actor. Indeed, the leaks can come from well-intended developers who simply share too much of their code on source code repositories.
The above image is an example of how easy it is for a developer to leak their access keys. In this situation, a developer forgot to exclude a text file when publishing his source code. This text file contained all the secrets needed to connect to his e-commerce provider. He even named the file keys.txt, decidedly making it easy for malicious actors to find this information and take advantage of it.
Profiling the leakers
Over the last 4 months, Flare Systems has detected over 1,000 cases of e-commerce platform API key leaks on the source code repository Github alone. In this blog post, we analyze the profile of the developers who leaked those keys to help your company understand where leaks are most likely to come from. Our analysis is based on the 168 individuals whom we identified as the source of the leaks.
Years of experience
It is believed junior developers are more likely to make the mistake of leaking API keys. They might not have had the chance to integrate technical secret management best practices into their coding routine, nor the experience of a leak to understand the API key work process.
A 2010 study confirms that “in most cases [of development of open-source software the authors analyzed], the expertise of the developers who introduce defects is indeed low”.
Our analysis shows that a quarter of all API key leaks were made by developers who had registered their account on Github less than a year before the leak. Of course, these developers could have a much longer experience, but this still suggests a strong correlation between experience and leaking technical secrets. As many as 75% of all API keys were leaked by developers with a Github account that was less than 5 years old, and the median experience is less than 4 years.
Implication in the community
Github developers follow each other in the same way that people friend each other on social media. Developers follow others to discover new trends and receive updates on projects that they like. 995 of the developers who leaked API keys were not popular on Github; their follower score was indeed under 50. Almost 60% of developers who leaked API keys had in fact 0 followers, and, in our sample, the average number of followers was 3.
Another metric to evaluate the implication in the community is the number of stars a developer has received. Our analysis shows that 95% of developers who leaked API keys had fewer than 50 stars. Over 60% of developers had received 0 stars, suggesting once again that their implication in the development community was very low.
In about a third of cases, the Github profiles indicate the location of the developers who leaked API keys.
Our analysis suggests that the United States and India are the two most common regions, though countries like Canada, Vietnam and Pakistan are also well represented among the leakers’ origin. This suggests that remote freelancers are not the only ones responsible for those leaks.
How to best prevent technical secret leaks
Our results suggest the most likely sources of technical secret leaks are junior developers who have not yet fully been integrated in the developer community.
These developers may be freelancers hired from countries such as India, Pakistan and Vietnam, or can be located in Western industrialized countries like the United States, Canada and Australia.
It is important to realize, however, that experienced developers are also potential leakers. In our dataset, developers with up to 13 years of experience made the mistake of disclosing their API keys. Twodevelopers had over 100 followers on Github, a level of popularity that is hard to achieve. Finally, 8 developers had earned over 100 stars from the community, highlighting their contribution to software development.
In conclusion, our analysis suggests that clear, secure coding policies are needed to help junior developers to not make mistakes. However, these policies are not enough, and must be accompanied by ongoing monitoring of source code repositories to detect any technical secret leak as soon as possible. Anecdotal evidence suggests that malicious actors take advantage of mistakes in a matter of hours. By hiring a service to monitor each line of code your in-house and freelance developers publish, you can prevent much of the damage from attacks and protect your brand and reputation.