Git 源代码控制安全性如何工作?

How Git source Control security works?

我的公司正在考虑从 SVN 迁移到 TFS,并且正在评估 Team Foundation 版本控制和 GIT。虽然 Git 提供了出色的分支和合并功能,但最令人担忧的是在开发人员机器上本地克隆存储库。源代码安全对公司的管理至关重要,因此他们对从集中式版本控制系统转移犹豫不决。

任何人都可以阐明这个问题吗?我们如何保证源代码的安全,以免有人逃之夭夭?如果 Git 是否适合我们。

我以前经历过这个评估过程。

结论是:分布式代码的安全性不亚于集中式代码:一旦你检查了一个代码库,你就可以渗透和"run with it",无论版本控制系统如何。

不同之处在于,您可以拥有所有历史记录的存档而不是最新的,但这在安全性方面几乎没有区别。

代码盗窃与所使用的 VCS 无关,而是依赖于其他措施(阻止 Internet 存储服务、阻止对 USB 的写入访问,...)

正如我在 2011 年 (!) 的“Distributed Version Control Systems and the Enterprise - a Good mix?”中提到的那样,Git 在企业设置中提出了其他挑战:

  • 身份验证
  • 授权

对于那些,仅 Git 是不够的:您需要一个服务器来管理用户(GitHub Enterprise、Gitlab、Gitea.. .)

而且我也看到了对作者身份的担忧(你可以创建一个提交 "as" 任何你想要的:user.name 只是一个字符串),导致 pgp-signed commits 更好identify/validate作者。

评论太长了。

考虑这样一种情况,您的公司根本不使用 VCS,只使用普通的旧文件和 zip 存档。可以出台哪些措施来防止开发者"stealing the code"?

个人经验:首先是NDA,即非技术性的纯司法措施。

然后您可以阻止特定的开发人员访问一组特定的文件。那就是根本不要让他们看到秘密文件。只有受信任的人才能处理密码和数据。

然后您可以限制开发人员使用 USB 和其他外部设备的能力。但我怀疑这一特殊措施是否有效。为什么?因为通常你不能 100% 地控制一个人,无论如何,强盗可以发送带附件的电子邮件,将秘密文件上传到远程服务器或使用隐写技术将珍贵的代码部分隐藏在猫的照片中。

总而言之,最主要的一点是知道秘密,而不是分享或窃取秘密。

返回 GIT:您可以将整组源拆分为不同值的片段,将这些片段分别放入单独的存储库中,对给定存储库具有不同的访问权限,然后 link如果您希望重新创建整个源代码树,请使用 GIT Submodules 将一个存储库转换为另一个存储库。因此,有特权的人可以访问整个源代码树,而不太受信任的开发人员(比如试用期的开发人员)将只能访问某些 "insecure" 部分。