It's Time to Take GitHub Threats Seriously

Source code. The software stored in GitHub is valuable intellectual property. Copying the code may enable other companies or even nation-states to quickly develop derivative applications, saving years or even decades of development time and leveraging trade secrets without paying licensing fees. Hackers might also steal code to resell it on the Dark Web.

Attack vectors. The source code might provide hackers with insights into how to attack software running in production. Stealing source code gives them time to search for vulnerabilities that might be much more difficult to discover through penetrations. They can even run code in production and test attacks against it, refining attacks for speed, stealth, and effectiveness.

Login credentials. Code and supporting files checked into GitHub sometimes inadvertently contain login credentials for other services, such as Amazon Web Services. When hackers gain access to the code, they can gain access to related services, giving them the opportunity to steal more data and disrupt operations.

Unauthorized access. Often, developers are granted access to company repositories from their personal email accounts. These accounts are left vulnerable, especially after developers leave. Additionally, often developers are granted access to all of the company's repositories instead of just what they need, creating a wide-open attack surface.

Insider threats. A lack of proactive monitoring can allow malicious insiders to easily hide abnormal activities. A single developer accessing tens of repositories could be an early indicator of insider threat, and such behavior should be detected and flagged. 

Clean up login credentials. Remind developers that they should be careful with their GitHub login credentials. Limit access only to those developers who need to be involved in a project. When developers leave a project, their credentials should be revoked.

Double-check repository settings. The software behind GitHub, the software version control program Git, was originally developed for managing development of the Linux kernel. Both Git and GitHub are widely used in open source projects. Some developers, particularly those used to contribute to open source projects, treat all GitHub repositories as public, whether they're open source projects or not. Double-check your organization's GitHub configuration to ensure that access isn't any broader than it needed.

Don't mix secrets with public code. Remind developers to be careful about including login credentials and other highly sensitive information in code, GitHub wikis, or other GitHub content accessible to outsiders. Since the Uber breach, GitHub has urged developers to be careful about this, but a periodic reminder from the SecOps team never hurts.

Monitor GitHub for suspicious activity. What sort of activity merits suspicion? A sudden spike in source code check-ins, enabling someone to check out an unusually large amount of source code. Also watch for logins from unusual locations or logins or requests from users outside the organization.

Collect GitHub logs. The best way to continuously monitor GitHub is to collect logs of GitHub data for your organization's repositories. If you're not collecting GitHub logs now, start.

Perform a baseline security assessment of GitHub activity. Tools are available for analyzing activity reported in GitHub logs, so that you can define a baseline of normal activity that will make it easier for you to spot anomalies in the future.

Automate the monitoring of GitHub logs. You'll want to monitor GitHub activity routinely to ensure that your organization's source code is secure and that outsiders aren't trying to infiltrate your repositories. You may be able to write scripts to perform this automation, or you can seek out a pre-built automated solution.