The Double-Edged Sword of Open-Source Code

Written by

While open code repositories can increase efficiency in R&D, they also raise issues of security vulnerabilities. Today’s developers are under pressure to deliver new software at an increasingly rapid pace, leading to the more frequent use of open source code, with the growing trend of developers using open code repositories to reduce cost and time in order to co-develop applications.

But, according to CyberInt’s research, code repositories such as GitHub, launched in 2008 and recently acquired by Microsoft, have potential security issues. Developers posting work on these sites routinely put private files into their repositories, which are then being copied into public repositories and made searchable.

Attackers are well aware how commonly open source code is used. They monitor repositories to see who contributes code and which have been identified as problematic.

Many organizations have also failed to monitor their developers’ open-source activities correctly. Often there are few records concerning which versions of open source software have been used, leaving corporate security officers in the dark when trying to discover vulnerabilities in their in-house apps. Innocent inclusion of personal information details in the code can also introduce new vulnerabilities.

Repositories such as GitHub shrink time to market by allowing developers to work on programs together as a team, regardless of their location. Each developer can work on their own version of a piece of source code, and only commit changes to the public repository when satisfied with it.

Most companies are unaware of their code repository vulnerabilities, which can have a potentially devastating effect on their client and investor confidence, brand image and bottom line. Even though individual code repository data itself may reasonably be considered of low importance or value, when repository codes are altered, it can result in an entire shut down of systems or applications. 

The identification and collation of technical indicators such as hostnames, IP addresses and service configurations allow a threat actor to build up a picture of a target organization’s infrastructure. This can be used to identify high-value targets. It can also be combined with techniques such as social engineering in locating potential targets, infrastructure attacks, whaling attacks and PII and credential theft as was the case in the Uber data breach in 2016.

Such sensitive information allows attackers to focus on locating vulnerabilities in high-level technologies. Given the ease with which information of relevant vulnerabilities can be obtained from a publicly-accessible repository, threat actors do not need to conduct a full-code analysis and could potentially leverage an attack against any deployed code.

The 2016 Uber data breach is a stark example; hackers broke into the source code repository on GitHub opening up infrastructure attacks worldwide. The online taxi service saw the personal data for seven million drivers and 50 million customers compromised.

Developers also frequently gain access to repositories from their personal email accounts, making these accounts especially vulnerable, particularly after developers leave. Further complications arise when developers are granted access to all of the company's repositories instead of the one most relevant to their task, exposing the company to additional potential threats.

Lack of monitoring of developers’ external communications can increase the risk of a cyber breach. One developer choosing to access dozens of repositories could be an early indicator of an insider threat. An organization whose developers use open repositories has three ways to protect itself: security awareness training, audits, and penetration testing.

  1. Training and guidelines: It is essential that developers are given clear guidelines on the data they are permitted to share on repositories such as GitHub and the data they must not. It is, for instance, crucial to ensure that company-wide confidential and personal data is removed or redacted before publication. Developers must also be trained to exercise caution when sharing screenshots or posting comments that are publicly viewable as these frequently contain useful intelligence.
  2. An audit or review of existing code repository permissions will ensure that repositories for internal-only use are configured with appropriate permissions versus those suitable for public consumption. Developers must be given precise instructions if there is an overriding reason to make an exception. Such audits need to take place periodically.
  3. Ongoing testing - It is also vital that companies commission an external intelligence-led penetration test in order to gather exposed data and identify incoming attacks and mitigate against them. In order to continue to protect themselves against incoming attacks from code repositories and elsewhere companies should also consider using a real-time intelligence service on a permanent basis.

What’s hot on Infosecurity Magazine?