本文不涉及基于代码关键字匹配的常见GitHub监控。而是从GitHub账号出发，通过人际关系获得一些代码搜索所没有的优势。 疑点突然出现 问题是从一个阳光明媚、迷人的下午开始的。我喝了娃哈哈，看着我认为是世界上最优雅的代码。然而，当我上传到GitHub私有仓库时，嘴角的笑容停留在10秒24毫秒前的阳光里，因为我发现上传显示的用户不是我。也就是说，提交页面并没有显示我帅气的头像。我，这件事有点奇怪：a．这个人是谁？b.我的机器被劫持了？C。我的帐户遭到黑客攻击？d.GitHub出了什么问题？e.一些不为人知的原因？ 一个问题比较好回答，点进去发现是一个很普通的用户，我不会被黑，不会吧，职业尊严让我强行排除了这个选项，但是我的一个顾虑是ta你能看到吗我的代码？这么优雅的代码，ta会不会觉得丢人？所以后来出于对他情绪的考虑，清空了自己的代码。 对于b，我更换了多台机器，发现还是一样的问题。也是出于职业尊严，我的机器不可能都被hack，所以问题肯定不在b。 然后仔细过滤了最近的GitHub登录记录，也排除了c的可能；然后问了周围的童鞋，d的问题也排除了。 目前只剩e个理由了，但这句话其实就相当于什么都不说了，因为所有的未知都可以归于未知。 追根究底 问题到这里就进入了死胡同，简单的描述是：不知什么原因，我的github的committer变成了不知名的人，换了多台机器后，问题还是重复。一般遇到这种情况，我的习惯是从头梳理整个流程，站在全局的角度去分析可能出现问题的环节。最紧迫的是重新梳理所有流程，然后不断尝试，那么问题来了，从写代码到下载Git，再用Git提交到GitHub，是一个怎样的流程？ Git需要先下载到本地。在本地下载时，需要使用HTTP协议。HTTP协议基于TCP。说到TCP，就需要了解三次握手.... 半小时后... 看16位微处理器芯片8086微处理器总线接口单元（BIU）和执行unit(EU)knowledge...感觉再深挖一下，就要开始学习二氧化硅的化学反应了。哦，知识。. 只好另辟蹊径，找了一个熟悉Git的强力外援。我们先试了……再试……又试了……终于，功夫不负有心人，找到了问题的症结所在。这一段我不是故意跳过的，真是一个乏善可陈的过程。 总之，看下面重点： 这个问题的根本原因是使用分发源仓库安装的Git默认内置了邮箱地址和用户名，然后GitHub通过上传时默认使用Git。配置的邮箱进行识别，如果用户邮箱存在（已注册或在GitHub注册），则显示匹配的用户名，否则显示Git配置中的用户名。验证后发现这个邮箱不一定是注册邮箱，但是在settings中添加的Everything是可以关联的，也就是刚才说的注册邮箱，即使你没有验证邮箱的归属权限，如下图： 而且使用Gitconfiguser.name和Gitconfiguser.email特别奇怪这两个命令都显示为空，好像从来没有执行过命令一样，但是在使用Gitlog的时候，实际会显示提交本次commit的用户名和邮箱地址，这是Git在本次发行版和邮箱中内置的默认账号。 放云见日 上面说了那么多，那这东西有什么用呢？我一直坚持一个观点：安全总是和场景有关，所以想要知道危害是什么，首先需要想象一些可用的场景。 这里最基本的使用方式就是伪造别人提交代码，但这其实对我们用处不大。准确的说，更多的是一种恶作剧的味道。 还有其他更好用的场景吗？其实在写这篇文章之前，我还在犹豫。众所周知，GitHub的很多用户都提交了一些敏感的东西，作者并不想在现实中。发现了，不过上面说的接口可以通过批量爆破邮箱获取对应的用户名。那么也可以获得那些不愿公开身份的用户的联系方式。 说的有点远了，回到正题中的GitHub监控问题。目前，GitHub监控始终是基于代码搜索中的关键字匹配。谁知道谁用它——它很难用。所以目前很多人也在努力爬虫和更好的过滤。但是这个过程中还有一个盲点，就是在发现非法上传的时候，不能非常准确的定位到具体的个人。 说完传统监控的缺陷，我们其实找到了一个新的应用场景，因为入职信息注册会写到我们平时的邮箱里（我还没入职，所以基本都是填私信常用邮箱），所以可以通过该接口获取对应的用户账号。也就是说，安全团队基本上都有部分员工注册的GitHub账号。这时候是否可以对非法上传公司代码的监控进行分级管理，重点监控。而且更重要的是，这也解决了方便发现问题和定位人员的问题。 至于操作过程，还是比较简单的。新建一个项目，然后用脚本修改你的用户邮箱进行提交。这里我以修改自己的邮箱为例： 然后推送到GitHub，***在GitHub上可以看到绑定了对应邮箱的用户，如下图（项目地址：https://github.com/daysdaysup/TSRC_TEST): 其他的就不用多说了。套用一句流行的打油诗：懂了自然懂。剑客剑客之梦，事已成，远去隐身名。 ***特别感谢师兄吴恒对本文撰写的帮助。
