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.

Improve this question
11
  • 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
    Commented Feb 3, 2019 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
    Commented Feb 3, 2019 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
    Commented Feb 3, 2019 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
    Commented Feb 4, 2019 at 3:50
  • 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
    Commented Feb 4, 2019 at 10:31

4 Answers 4

Reset to default
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.

Improve this answer
5
  • 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
    Commented Feb 3, 2019 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
    Commented Feb 4, 2019 at 5:07
  • 1
    @Qwertie that should really be the only answer to this question...
    – Conor Mancone
    Commented Feb 4, 2019 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
    Commented Feb 4, 2019 at 15:23
  • I'm not sure that "unfortunately" is the right word
    – Lightness Races in Orbit
    Commented Feb 5, 2019 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.

Improve this answer
3
  • 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
    Commented Feb 4, 2019 at 5: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
    Commented Feb 4, 2019 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
    Commented Feb 4, 2019 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?

Improve this answer
1
  • 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
    Commented Feb 4, 2019 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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .