获取GitHub上的repo被clone/download的相关信息

本文最后更新于2015年7月4日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

搜索关键字:
  • github how to know how many people download my repo
  • site:help.github.com clone stats
参考解答:
  • 获取clone信息

http://stackoverflow.com/questions/10056638/how-to-get-github-clone-stats

https://github.com/blog/1873-clone-graphs

https://help.github.com/articles/about-repository-graphs/

  • 获取download信息

http://stackoverflow.com/questions/4338358/github-can-i-see-the-number-of-downloads-for-a-repo

http://stackoverflow.com/questions/6198194/how-to-see-count-of-project-downloads-on-github

下面是获取libgit2这个项目的下载[次数]信息的方式:

https://developer.github.com/v3/repos/downloads/

 

参考链接:

=

=

=EOF=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/2301.html

《获取GitHub上的repo被clone/download的相关信息》上有18条评论

  1. Prevents you from committing secrets and credentials into git repositories (防止您将机密和凭证提交到git仓库中)
    https://github.com/awslabs/git-secrets

    git-secrets 会扫描 commits、commit messages 和 --no-ff合并 以防止在git仓库中上传机密信息。如果在上述任何地方发现与您配置的禁用正则表达式模式相匹配,则提交将被拒绝。

  2. 你们玩过的github泄露最好用的是那个?

    GSIL 和 X-patrol 还不错

    另外一个方式就是:
    采取粗颗粒业务关键词搜索之后,得到一批仓库地址,然后clone到本地,基于hound引擎[https://github.com/etsy/hound]做本地的正则代码搜索。

    https://github.com/FeeiCN/GSIL
    https://github.com/MiSecurity/x-patrol
    https://github.com/0xbug/Hawkeye
    https://github.com/UnkL4b/GitMiner
    https://github.com/mschwager/gitem
    https://github.com/repoog/GitPrey
    https://github.com/ezekg/git-hound
    https://github.com/dxa4481/truffleHog
    https://github.com/shengqi158/svn_git_scanner

  3. 旧树开新花——再谈GitHub监控(一种定位人员的方法)
    https://security.tencent.com/index.php/blog/msg/132

    本文不涉及常见的基于代码关键字匹配的GitHub监控。而是从GitHub的账户出发,通过人的关系来获得一些代码搜索不具有的优势。

    简单描述下就是:因为某些未知原因,我的GitHub的提交人变成了未知的某人,而且在换了多台机器之后,问题依然重复。
    这个问题引发的根本原因是使用某发行版源仓库安装的Git默认内置了一个邮箱和用户名,然后GitHub在上传的时候识别用户是默认通过Git中配置的邮箱来识别,倘若用户邮箱存在(在GitHub注册或者登记)则显示匹配到的用户名,否则会显示Git配置中的用户名,验证之后发现这个邮箱不一定是注册邮箱,而是在设置里添加的都可以关联到,也就是刚刚提到的登记邮箱,即使你没有验证邮箱的归属权限。

    而且尤其比较诡异的是使用Git config user.name 和Git config user.email这两个命令查看均显示为空,就像这个命令从未执行一样,但是在使用Git log的时候才会真正显示提交本次commit的用户名和邮箱,也就是该发行版Git内置的缺省账户和邮箱。

    上边说了那么多,那么这个东西有什么用呢?我一直秉承一个观点:安全总是跟场景相关的,所以要想知道这个有什么危害,首先需要做的就是设想一些可利用的场景。

    在这里最基本的利用方式是可以伪造别人去提交代码,但是这个对我们来说其实并没有什么太大的用处。准确来说,更多有一种恶作剧的味道。

    那有没有什么其他的场景是比较有用的,其实在写这篇文章之前,我还是比较犹豫的,众所周知,GitHub有很多用户提交了一些比较敏感的东西,而作者是不想在现实中被发现的,但是上述提到这个接口,可以通过批量爆破邮箱从而获得对应的用户名。那么也有可能获得了那些不愿意公开自己身份用户的联系方式。

    扯的有点远了,还是回归到题目当中GitHub监控的问题,当前GitHub监控一直是基于代码搜索中的关键字匹配,真的是谁用谁知道——那是相当的难用。所以目前很多人也是在爬虫和更好的过滤上下功夫。但是这个流程还有一个盲点存在,就是在发现违规上传的第一时间并不能特别准确的定位到具体的个人。

    说完传统监控的缺陷同时,我们其实也找到了新的利用场景,因为入职信息登记都会写到自己的常用邮箱(还没有入职,所以基本填写自己私人常用邮箱),那么可以通过这个接口来获得对应的用户账户,换句话说,安全团队基本就有了部分员工注册的GitHub账户,这个时候违规上传公司代码的监控是不是可以做一些分级管理,重点监控。而且更重要的一点,这也解决了发现问题简单、定位人员困难的问题。

    至于操作过程,就相当简单了,新建一个项目,然后使用脚本修改自己用户邮箱进行commit,在这里我以修改自己的邮箱为例:
    之后push到GitHub上去,最后在GitHub上就可以看到绑定了对应邮箱的用户,如下图(项目地址:https://github.com/daysdaysup/TSRC_TEST):
    至于剩下的就不用再多说了。套用一句比较流行的打油诗:懂的自然懂,刀剑侠客梦,事了拂衣去,深藏身与名。

  4. 如何利用云安全运营中心监测数据泄露
    https://mp.weixin.qq.com/s/HQyYfoi_7I-tisd5yWAk7w

    数据泄露的“冷静三问”
    1、典型的数据泄露事件有哪些?
    2、数据泄露产生的主要原因是什么?
    3、为避免数据泄露事件,我们能做什么?

    关于数据泄露那些事儿
    1、数据泄露定义及常见分类
    Github代码类数据泄露事件
    网站入侵类数据泄露事件
    网络黑市交易类泄露事件
    合作商接口类数据泄露事件

    2、数据泄露产生的根本原因是什么?
    “策略”不规范,“企业”两行泪。

    数据泄露的根本原因可能多种多样,总结起来,几乎都可以归类为两种,一种为企业对于数据的技术管控策略不足到导致的数据泄露,另外一种则是数据安全管理策略或制度上缺失导致敏感数据被未授权的访问。

    技术方面,网站/平台/应用/系统因为存在安全问题,如系统漏洞或配置失误、数据脱敏手段和数据加密措施缺失、异常操作审计手段缺失、敏感信息泄露发现机制缺失等,都可能导致攻击者利用获取到敏感数据;

    管理方面,由于开发人员或实习员工安全意识薄弱、或对合作商缺乏数据使用约束条款或限制措施等,导致数据未授权公开或被非法滥用,也是导致数据外泄另外一大主要原因。

    3、出现数据泄露事件,我们能做什么?
    这里我们重点针对比较典型的、且危害较大的Github代码泄露、黑市数据交易这两种行为,探讨我们能够能在技术上落地的手段和管理上的控制思路。

    技术管控策略
    1)严禁员工私自搭建代码管理工具,需使用公司统一授权的代码管理工具(git,svn)进行代码管理;
    2)严格管控项目代码权限,人员变动(转岗、离职)需及时回收代码权限;
    3)大型项目使用 submodule(子模块)进行划分,对项目进行实行权限最小化原则;
    4)不把代码存放在外部网站,如:Github、Onedrive等网站
    5)对Github、地下交易市场等网站进行敏感信息泄露监测,当出现敏感信息时,关注进行自查确认,避免问题扩散。

    合规管理策略
    1)制定《源代码开源安全管理》,开源需经过开源流程评估;
    2)对合作商的接口的使用范围约束条款、限制或监督审计等
    3)对内部员工的合同法律约束,高压线措施

    如何更好的配置监测规则?
    规则1:基于云业务场景的规则——云API密钥规则
    规则2:基于帐号维度的规则——帐号ID+帐号关键词
    规则3:基于域名场景的规则——域名/IP+业务关键字/帐号组合
    规则4:其他场景的规则——开发人员英文名/全拼+开发关键字+…

    如果真的出现泄露事件该如何处理?
    1、 发现有敏感信息泄露事件时,第一时间是通知开发确认,若属实则联系开发或作者在Github上进行删除或脱敏处理,当被fork到大量人员时或事件影响较大时,则可以考虑联系GitHub DMCA(数字千年版权法案处理规则)向GitHub发送邮件进行处理,要求进行删除,并同时针对内部受影响系统开展自查,修改帐号密码等;
    2、 建立一套泄露监测处理规范,比如出现泄露后的敏感信息删除或修改,涉及敏感信息的系统或服务器的内部安全自查、内部的安全意识宣告,代码管理平台或工具建设等。

    没有绝对的安全,如同没有绝对完美的安全系统,也因此,就有了安全运营的概念,即通过持续的运营对抗,来弥补企业安全体系木桶的“短板”(漏洞、弱口令)。

发表评论

电子邮件地址不会被公开。 必填项已用*标注