Recently some non-technical managers where I work found out that GitHub has a repository with code from "Hidden Tear" which is a ransomware application. The immediate reaction was to ban GitHub, which is something that we use extensively to get open source code. The only way to access GitHub again is by proving that the site is safe. This would be easy to do if I were convincing software developers, however I am speaking with people who have never written a line of code. I have been told that if I want to use code from GitHub or view pages on the site I need to do the following:

  1. Show the site is safe and will not infect our computers
  2. Create an open source policy for use when determining the safety of code found on GitHub.

My first step was to go through a list of companies and government organizations that use GitHub. I believe that this will start to calm fears that the site is going to infect all computers with ransomware. I will expand on this by describing what GitHub is, what it does and why it is valuable.

The problem is that I don't have much experience writing policy documents. I'm hoping to find someone with some knowledge about policy that could share some of their experiences in writing open source usage policy. From what I understand our policy should be a step by step guide to determine whether or not we can use a specific library/plugin.

  • 24
    Show the site is safe and will not infect our computers -- You can't. How would one prove this about any website? Sep 22, 2015 at 21:25
  • 55
    Looks more like a Workplace question to me: "How do I deal with crazy stupid management."
    – bmargulies
    Sep 22, 2015 at 21:27
  • 7
    Do you not have a technical manager you can leverage against this non-technical manager? It is possible for the security people at your company to create rules for groups. The idea is to allow your developers access to Github while the restriction remains in effect for all other employees. Rather than prove the safety of Github, try proposing this as an alternative.
    – ThisClark
    Sep 23, 2015 at 14:42
  • 3
    The core of this question seems to be about writing an open source policy for a company, rather than assessing the security of a particular website, and as such I see it as very much on topic. Sep 24, 2015 at 7:59
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Zizouz212
    Sep 24, 2015 at 21:14

4 Answers 4


I'm a solo programmer, not any firm. But suppose if I were to form a small firm tomorrow and decided to write a security guideline regarding what to allow/disallow from github, it will be implemented something like this:

  1. Only allow github.com domain and not github.io. Reason is that the latter is a web-hosting playground where any random developer can place any random javascript to be executed like some others have said. The former, on the other hand, is from the official company and relatively safe.

  2. Create a policy to blacklist/whitelist downloads with certain extensions. EXE and DLL are the worst if you are on windows platform as these are arbitrary binaries that can just do anything on your machine including causing havoc. If you are as paranoid as me, you will take the whitelist approach and just ban everything except the ones that you need (for example, .php, .py, .js, .html, .css, etc. if you are running a FOSS project).

  3. Create a policy to install only from the official sources. On Windows machines, not giving admin rights to your every user should be a norm. Only personnel from IT depts should do that, so the user can't cause any damage to their systems even in the rare instance that they did end up downloading something bad.

  4. Create a policy to maintain a list of developers who are granted commit access to the git repositories. Don't give any commit access to the main repos unless it is absolutely necessary. If possible, include a code-review process in workflow whereby, the dev sends a pull-request and reviewer later integrates the code after a thorough check. This process will ensure that no malware gets through past your build process, either wittingly or unwittingly.

  5. Create a policy to revoke commit access as soon as a dev leaves the firm. This will ensure that no "blame-game" takes place that usually happens when a dev leaves a company.

  1. Show the site is safe and will not infect our computers

It's not "safe". GitHub allows anonymous users to upload anything they want including malware. You could get infected by downloading/executing code or visiting anything on the "github.io" domain where arbitrary javascript (and therefore 0-day browser exploits) might be found (github.com is safer than github.io).

  1. Create an open source policy for use when determining the safety of code found on GitHub.

The only way to determine the safety of source code is to go through one line at a time and carefully read every single line.

With major projects, you might assume somebody else has already done this, but that's not a safe assumption. For example OpenSSL's security was completely compromised in 2011 but code reviewers failed to notice the problem until 3 years later. Criminal organisations were aware of the problem long before it was fixed and companies were compromised.

Small businesses using open source Word Press plugins are continuously being hacked, we see it almost every day where I work. Smart companies avoid the problem by refusing to use random word press plugins and your company policy should be the same.

In general there are two things you need to worry about:

1. The most scary is an actively malicious attack, for example in 2013 a version of phpMyAdmin was being distributed with a "sync_server.php" script who's entire purpose was to execute arbitrary PHP code provided in POST.

2. More common than that and your primary concern, is plain stupidity. There is a ton of open source code available online containing serious security flaws that are almost as bad as an intentional back door. Far too often these issues are not discovered until organised crime starts taking advantage of them – and they usually attack individual companies rather than the entire internet, further increasing the chances that they can attack over and over again before the bug is discovered/fixed.

What you need to do is make a risk/reward analysis. Outline the risks of allowing access to GitHub in detail, and then outline the rewards, and conclude with your case that the rewards outweigh the risks.

Developers should not be allowed to use code on GitHub (or from anywhere else) unless they understand the risk and each project's quality must be judged individually. How strict your policy is should depend on how much harm would result in a successful attack.

The largest and most successful corporations in the world have all decided that the rewards outweigh the risks – doing so is necessary to remain competitive. But don't pull in open source code lightly.

  • 14
    The only way to determine the safety of source code is to go through one line at a time and carefully read every single line. That sounds overly optimistic Sep 24, 2015 at 1:12
  • 3
    @NicolaPeluchetti It's a necessary condition, but not a sufficient one.
    – user253751
    Sep 24, 2015 at 11:08
  • 3
    The site is probably safe, what you download from it might be tainted. Just like any random site on the web, this one might infect your brain with the dreaded "open source" virus...
    – vonbrand
    Feb 1, 2016 at 2:54

There is a giant problem with the logic behind this fuss. Storing the source code of malware is not strongly correlated with being infected with malware.

Consider http://www.metasploit.com/. It's a tool used by people protecting against intrusion -- and also by people looking to perform intrusion. Or any number of other resources used by people who study malware.

Yes, github.com could turn out to contain active malware -- but so could anything else where arbitrary websites are hosted. Does your management prohibit access to all of AWS? Google apps? Heroku? Sourceforge? Bitbucket? There's a list of about a million places that allow people, including bad people, to set up web sites. Does your employer really maintain a white list of only sites that they like? And what do they do when one gets broken into, and turned into a malware distribution apparatus?

So, this has nothing much to do with open source, except insofar as github.com is a hard place to avoid if you want to use it. You could have this debate about every wordpress blog site in creation; those get compromised approximately once every five minutes.

  • 16
    Sourceforge is arguably more of a problem in the current environment, as there have been recent cases of that site, by policy, placing Adware into installers. E.g. developer.com/daily_news/… Sep 23, 2015 at 12:34
  • 1
    As a matter of fact, many companies block any of the well-known sites that provide downloads, usually done done by filtering software they bought. E.g., until our company did actually start to develop an integration into Google apps, those were blocked for us, Google Drive in particular. Personally, I think that the way to officially gain access to Github is outlined rather well in this case - provided that the requests for the safety evaluation and code usage policy (pretty sure that there is one for that already, but it might focus on licensing) are not just ways to deny that forever. Sep 23, 2015 at 14:23
  • @NeilSlater the result of that fiasco has been SF and /. being put up for sale. AFAIK they haven't found a buyer yet; I'd be even more cautious about it until the sale's completed and we know who the new owner is (or longer if it's someone we've never heard of). Sep 24, 2015 at 13:03

Perhaps you could get access approved on a per-project basis on GitHub? For example, say you wanted to use code from https://github.com/google/zopfli you could somehow get that approved and then be able to download/use the relevant files. Annoying, but better than having to write 100% of your code from scratch.

Also, if they're particularly concerned about ransomware, something like first testing code in a VM that can be trashed at a moment's notice might help them to feel like it's safer?

  • 10
    As a front-end developer, this would be particularly annoying - I go through and test so many libraries to see if they fit use cases that I would be requesting 50+ libraries/pages/what-have-you a week.
    – Seiyria
    Sep 23, 2015 at 19:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.