笔者原来在涉猎git监控产品时，就只做了敏感关键词监控。后来在工作中逐渐发现，对于一般量级的企业单位，其实复合型的监控平台更符合这类企业的需求。

那么，对于git方面的监控，我们应该做些什么呢？

复合型监控

敏感关键词监控

对于类github监控，敏感关键词监控是基础，目前主要监控点有以下几种：

敏感email地址
敏感多级子域名
ssh key
物理机key
云平台key
硬编码的pwd
关键域名+敏感路径+敏感key的拼接
（比如https://xxx/host/{ip}?key={YOUR_API_KEY}）
组织单位标识
关键数据库名、表格名、字段名、连接字符串
vpn配置字符串
smtp配置字符串

大部分类github平台，查询应该是需要登录的，这里以github举个例子。

我们可以用session认证，不过只有前100页的查询限制。

当然，大家也可以用key+api接口，个人没采用过这个接口，据说默认搜索前5000个项目。

所以利用好语法是很重要的，我们要精确地对需要监控的关键词，进行综合定位：

搜索路径中有nsa的代码或者文件中有nsa的代码
nsa in:file,path

搜索用php写的包含userid的代码,文件名为flag，扩展名为txt
userid language:php filename:flag extension:txt

匹配关键字nsa且搜索大小为100字节的xml代码
nsa language:xml size:100

搜索conf目录下包含pass的xml代码
pass path:conf language:xml

除去名为normal_name的repo
-repo:normal_name

搜索star大于20，20<fork<30的项目
stars: >20 fork: 20..30

另外，类github平台如果做了查询限制，可以考虑采用以下几点去绕过：

IP池
多账号轮询
UA池
降频处理

安全监控

在大一点的企业平台，做项目管控时，会接入gitlab或者类github平台的私有项目。

那么，如果要坚持精简的原则，我们需要完成哪些基础点呢？

第一，版本监控 每次漏洞大规模爆发时，常常需要去检查下，己方线上环境的组件，是否出于漏洞影响范围之内。

因此，维护和及时更新IT资产的checklist库，无论是实现的半自动化还是自动化监控，都是有一定积极作用的。

第二，安全审计 对于项目本身，我们需要做一些代码安全审计和日常扫描。

一般在代码上线，以及测试分支代码变更时，在条件允许的情况下，都应该触发自动化安全扫描。

在CI自动化和日常扫描时，一旦检测到问题，需要发送报告到安全运维人员过审，再决定要不要通告开发人员，去进行整改或者代码回退。

对于代码本身，可提供配置文件或者接口，供第三方软件，进行安全审计，这里不再多提。

舆情监控

现如今类github平台因为某些zz原因，成为了某些有心人撰写博客和放新闻的地方。

笔者当初做舆情监控接口的时候，也添加了对这类平台的接口支持，效果感觉尚可。

平台优化Tips

关键词定制

如果我们在开发后期，想要去定制一些关键词咋办？

存在配置文件的情况下，我们可以做关键词命中。

一旦触发命中我们自己添加的关键词（不一定是标准搜索语法），也会直接通过微信或者邮件，将结果推送到负责人那里。

规则可配置

规则配置可以是多样化的，比如类github平台定期巡检，更新触发扫描，主动扫描检查。

多少时间没响应，会自动再次触发报警推送，多种方式报送警报消息。

制定repo或者author白名单，避免更多的误报。

优化读取的内容，指定显示关键词前后文行数。

设置关键词权重，避免大量冗余数据掩盖了低频高危数据。

污点化

在为了防止企业git项目被泄露到公网，我们在命名规范时，可以尝试制定编码规范，必须带上容易识别的特征，或者带上关键词。

这样有个好处，在代码泄露时能及时监控到，但防君子不防小人，内部人员可能会做关键词替换。但这种情况，也可以通过一些特殊技巧去提升保密性。

另外，白帽子提交速度可能比监控响应更快，这就需要考验规范制定者的素质了。

参考文章

深入分析一款简单的Github信息泄露爬虫

Github代码高级搜索小技巧

基于Github的源码白盒扫描工具Raptor

Github信息泄露专项