24

We are developing a kind of social platform. It starts as a closed beta for a limited number of users, but the goal is to reach millions of subscriptions.

We are currently limited on resources, both infrastructure and e.g. DevOps. So we are using GitLab for versioning our source code.

Let's assume, we make it and in few years the service has million users. How do you feel about using GitLab for versioning of the source code at this stage? Do you see it as a significant security threat? A few reasons to consider:

  • there is no possible real warranty that staff from GitLab cannot investigate the source and find security holes or some sensitive configuration.
  • GitLab staff could sell sourcecode to some third party
  • GitLab may be forced to provide the sourcecode to some government, without us to know it

I know the points will sound paranoid. The purpose of the network is completely legal and ethical, but I believe any service of this kind must protect the privacy of its users. The plan is to move to our private servers later, but we have to start somehow.

So, do you think it is OK to use private GitLab or Bitbucket repositories for the early phase of the project, or is it an unacceptable security threat?

Disclaimer: I don't claim GitLab would do anything of the described.

Peter Mortensen
  • 877
  • 5
  • 10
ooouuiii
  • 389
  • 2
  • 6
  • 38
    Some people might say `... any service of this kind must protect privacy of it's users.` while keeping your source code private is a contradiction. Privacy aficionados aren't exactly wild about closed-source software. – Ella Rose Feb 03 '19 at 15:27
  • 42
    _"investigate the source and find [...] some sensitive configuration."_ - (Sensitive) configuration should not be in the source repo in the first place ;) – marcelm Feb 03 '19 at 20:42
  • 13
    Note that if you are really concerned, you could host your own GitLab or other platform. You mention infrastructure as an issue, but this could easily be done on a free hosting platform. – multithr3at3d Feb 03 '19 at 23:03
  • 1
    The legality of "selling your code" falls under what code license you use and Gitlab's terms of service. You also must obey whatever the laws of whatever nation has jurisdiction over the code (I'm not sure about the details) – qwr Feb 04 '19 at 03:50
  • There is no such thing as a completely legal and ethical social platform. If it gets popular it will attract people from many countries, and countries have different laws which aren't always compatible. And people have different ideas of what's ethical. And let's not ignore the fact that there are countries with laws regarding social networks that most people consider unethical. – kasperd Feb 04 '19 at 06:10
  • You _don't_ need Gitlab to host your repository. You can send patches via email just like it's done in Linux kernel development, sending patches back and forth, with everyone having their own clone of the repo, etc. Even the GitHub page is simply a backup mirror for the Linux Kernel itself. – code_dredd Feb 04 '19 at 07:52
  • 5
    "*code versioning platform*" - you really need to distinguish the code versioning *tool* (Git), the code repository *server* (Gitlab), and the DevOps *platform* (Gitlab CI). Those are all independent from each other. – Bergi Feb 04 '19 at 10:31
  • 1
    If you worry about unauthorized changes to your code you can have a local copy and verify the commit history regularly. Git is good in representing the entire tree/commit history with a single hash. – eckes Feb 04 '19 at 11:55
  • Great lesson all these hints. I know the source code is not the most imoprtant asset. Imagine your early project stage is half a year of intensive development in spare time. No miracle, but you are building horizontally scalable app with different cacheing layers with edge technologies, that sometimes doesn't have mature solution for your problems. If we got current source in the beginning, it would definitely helped us to be farther today. I want to contribute to OS, but first, I want the opportunity to succeed with it. Do you think e.g.paypall would, if they go OS from start, when Cofinity? – ooouuiii Feb 04 '19 at 22:01
  • Specifically, gitlab is one of the few platforms that has a turn-key self-hosted free/oss solution, so if you like git, gitlab, and gitlab ci/cd it is not out of the question for a small team to self-host, eliminating all your concerns. I manage a 30 user set up as an EE, it can't be that hard :) – crasic Feb 05 '19 at 01:22
  • 1
    And even for something like bitbucket: I pray on a daily basis that they compromise any code I have in private repositories. The damages and compensation to be expected of a class action suit will surely be worth a lot more than the code stored... – Markus W Mahlberg Feb 05 '19 at 12:35

4 Answers4

69

Unfortunately, you are the ones responsible of seeing if your threat model is justified or not. Therefore, we cannot simply give a definite "yes" whether we see using the platform as a security threat or not.

However, there are two points that I'd like to expand on:

  • You seem to be extremely worried about the source code containing vulnerabilities and that the disclosure of it would mean that an individual or party could identify them.

Personally, I would not feel confident about providing a service to users where its security relies on the source code not being open source. To me, this is some sort of security by obscurity. In the best world, you want your platform to be as solid even if the code leaks. Therefore, I would highly suggest that you partner up with some pentesters/code reviewers, or at least some developers that are very security-aware.

  • You mention wanting to move to private versioning servers.

Just do this right away and be done with this. At the risk of sounding blunt, I would question your technical skills if this seems to be a complicated or expensive step considering that you are starting off. Gitlab even offers a self-hosted solution; just make sure to review the platform and to block any communications with their servers if that part worries you.

Best of luck.

Simon
  • 3,182
  • 4
  • 26
  • 38
  • 1
    Thank you for great feedback. Both points are completely valid. We are going to open source lots of the code-base, when the service succeed. While the security is part of the design, I want independent audit first. Different aspect is, we already invested months of the development time, solved lots of problems and we cannot lose this as our starting advantage if it shows, the market wants this kind of platform.We can start e.g. our own virtual server with git server, then we have to take care of security patches of the server. In this stage, we are mainly developers, not sysadmins / devops. – ooouuiii Feb 03 '19 at 15:39
  • 47
    @ooouuiii The source code is worth less than you might think. Its unlikely you have developed anything revolutionary as any competent developer could build a website for 1M users. The real value is in the marketing, business side and userbase. If someone wanted to compete with you they would write their own software which would suit their needs better and be better understood by them. – Qwertie Feb 04 '19 at 05:07
  • 1
    @Qwertie that should really be the only answer to this question... – Conor Mancone Feb 04 '19 at 14:23
  • 10
    "Personally, I would not feel confident about providing a service to users where its security relies on the source code not being open source." Exactly. It's always important to remember Kerckhoff's Principle here: your threat assessments should always begin with the assumption that "the adversary knows the system." – Mason Wheeler Feb 04 '19 at 15:23
  • I'm not sure that "unfortunately" is the right word – Lightness Races in Orbit Feb 05 '19 at 16:17
23

@Simon has already provided a fantastic answer, but I'd like to add in response to this point:

there is no possible real warranty that staff from Gitlab cannot investigate the source and find security holes or some sensitive configuration

Configuration does not belong in the repository. Configuration should be combined with code at deployment, not before, as per the third factor of twelve.

To do so, have your application read configuration values from the environment at runtime. In the case of, for instance, Django, this would involve you defining your secret key as such:

import os


SECRET_KEY = os.environ['DJANGO_SECRET_KEY']

And having systemd (or whatever runs your project) set that environment variable.

As @Ave notes in the comments below, you would only store your production secrets on your production's build step and servers. You would set spurious or random secrets for your CI servers, staging servers, and whatever else. If the issue is trust with your repository host with regard to secrets, then you can opt to use Chef, Spinnaker, Puppet, or whatever else you may choose, rather than your repository host's CD.

Adam Barnes
  • 403
  • 2
  • 8
  • 8
    As far as I am aware its one of the big features of gitlab that you add your configuration to it and gitlab is able to automatically deploy and monitor your servers. I guess if you didn't trust gitlab you would just not use that feature however. – Qwertie Feb 04 '19 at 05:08
  • 1
    The configuration would not be stored in the source code, but still on the platform. "*whatever runs your project*" is precisely the Gitlab CI tool. – Bergi Feb 04 '19 at 10:29
  • 6
    @Bergi obviously the secrets CI would use for tests and such wouldn't be the same as production secrets. If you're talking about Gitlab CD (continuous deployment), this is a valid argument, though, but if you don't trust Gitlab with it, you can simply not use that feature. – ave Feb 04 '19 at 11:21
5

There are multiple options except for Gitlab (including pure Git). Gitlab is an open-source/open code project so that you can install it on your private server, so nobody except your team have access.

Which, raises, I believe, more prominent issue - your staff know security holes or some sensitive configuration and could sell the source code to some third party or the government. Even more, your staff has access to the data, which is much more critical and sensitive than source code. How do you plan to address this?

Maxim Kuleshov
  • 151
  • 5
  • Tough one. We are clearly not there yet and we need to go there by iterations, searching for best practices for this setup. Currently, I imagine something like different stage-environments (like dev, integration, uat, preprod, prod). Prod environment in different subnet with restricted and logged access to data. Ok, we probably cannot protect source-code, but i mean it really for the initial product stage, when we are not yet fulltime on it. The infrastructure security will certainly evolve with the project a lot. – ooouuiii Feb 04 '19 at 21:31
1

Why not use a private gitlab instance, this would alleviate any of your concerns!

If your platform is to reach millions of users you could at least have a $5 a month cloud instance to run this on.

But your concern comes from employees/ admins of SaaS platforms you use having ultimate access to your platforms, this would be true of any cloud service provider or even physical dedicated server provider (assuming disks arent encrypted) in which case run a on premise server.

At this point you have to ask yourself how sensitive/ likelihood people would be that interested in your system

user6858980
  • 99
  • 2