CODEWITHSUNDEEP
gittfsazure-devops
Shuja Hanif
Shuja Hanif

Reputation: 75

How Git source Control security works?

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.

Upvotes: 1

Views: 180

Answers (2)

VonC
VonC

Reputation: 1329662

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.

Upvotes: 1

user3159253
user3159253

Reputation: 17455

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.

Upvotes: 1

Related Questions