1

My company is contemplating a move from SVN to TFS and are evaluating both Team Foundation Version Control and GIT. While Git offers excellent branching and merging functionality, an extreme cause of concern is the local cloning of the repository on a developer's machine. Source code security is paramount to company's management and therefore they are hesitant to move from a Centralized Version Control system.

Can anyone shed some light on this problem? How can we keep the source code safe so that no runs away with it? And if Git is for us or not.

Shuja Hanif
  • 75
  • 3
  • Technically git is a distributed VCS. This means that a developer has a complete access to all files in a repository and usually* to a full history of a particular repository. * one can skip some parts of the history while cloning (see https://git-scm.com/docs/partial-clone) but in this case that person can't make new commits of their own. But look: if a developer has access to files, they already have a chance to steal it, don't they? – user3159253 Nov 20 '19 at 05:19
  • So we cant actually enable any security which will stop code theft? – Shuja Hanif Nov 20 '19 at 05:41
  • I have edited my answer with other challenges posed by Git. – VonC Nov 20 '19 at 07:02
  • What's stopping developers from getting files from SVN and emailing the contents to their personal accounts? Or printing out a copy of the code and stuffing paper into a backpack? – Daniel Mann Nov 20 '19 at 13:06

2 Answers2

1

I have been through this evaluation process before.

The conclusion is: the security of a distributed code is no more or less than a centralized one: once you checkout a codebase, you can exfiltrate and "run with it", no matter the version control system.

The difference is, you could have an archive of the all history instead of the latest, but that makes little difference in term of security.

Code theft is not linked to the VCS used, but relies on other measures (blocking internet storage services, blocking write access to USB, ...)

As I mentioned in "Distributed Version Control Systems and the Enterprise - a Good mix?" back in 2011(!), Git poses other challenges in an enterprise settings:

  • authentication
  • authorization

For those, Git alone is not enough: you need a server which will manage users (GitHub Enterprise, Gitlab, Gitea...)

And I have seen concern over authorship as well (you can create a commit "as" anyone you want: the user.name is just a string), leading to pgp-signed commits to better identify/validate the author.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

Too long for a comment.

Consider a situation when your company doesn't use a VCS at all, just plain old files and zip archives. What measures can be introduced to prevent developers from "stealing the code"?

From my personal experience: first and foremost is an NDA, that is, a non-technical, purely juridical measure.

Then you can prevent a particular developer from accessing a particular set of files. That is don't let'em see secret files at all. Only trusted persons deal with secret code and data.

Then you can limit ability of a developer to use USB and other external devices. But I doubt this particular measure is an effective one. Why? Because usually you can't control a person 100% of time, anyway a robber can send an e-mail with an attachment, upload secret files to a remote server or use steganographic techniques to hide precious parts of the code inside cats photos.

All in all the principal point is to know a secret, not to share or steal a secret.

Back to GIT: you can split the whole set of sources into pieces of different value, put these pieces into separate repositories each, with different access rights to a given repository and then link one repository into another using GIT Submodules if you wish to re-create a whole source tree. Thus privileged persons would have access to the whole source tree, while less trusted developers (say. those on probation) will be given access only to certain "insecure" pieces.

user3159253
  • 16,836
  • 3
  • 30
  • 56
  • Thanks man. I think I can pitch these scenarios as probable solutions. We already have a similar implementation regarding unsecure pieces and splitting of the main code. – Shuja Hanif Nov 20 '19 at 06:58