GitHub始终是攻击者的重点目标，原因在于它处于软件供应链的核心位置，能为威胁行为者提供三样最渴望的东西：源代码、密钥凭证，以及可以肆意利用的自动化流水线。
Datadog安全研究团队在过去数月中持续追踪一种被其定义为"持续性规律"的GitHub API滥用行为。这类行为的目的是绘制企业组织及其成员的详细画像。单独来看，这些请求"平淡无奇"，但一旦跨越多个环境持续数周，甚至发展为大规模代码克隆，危险性便急剧上升。最大的挑战在于，这类行为与正常的API调用模式高度相似，难以区分。
Beauceron Security的David Shipley表示，由于许多开发生命周期存在安全漏洞，GitHub一直是犯罪分子入侵企业的宝库，攻击者通常的目标是API密钥和云端凭证。
"如今，随着所有人都被要求借助AI智能体编程来更快地完成更多工作，泄露的凭证宝库很可能比以往更大，"他说，"简而言之，套用旧时淘金热的一句话：'那山头里有黄金。'"
安全与合规公司DataBee的首席技术官Scott Miserendino对此表示认同。"GitHub是开源和企业项目中最受欢迎的源代码仓库，"他说，"其庞大的项目体量，加之托管着众多广泛使用的热门软件，使其成为攻击者的重点目标。"
他指出，对私有代码仓库进行未经授权克隆等知识产权盗窃行为，可被用于获取专有软件的使用权，或发现可供利用的安全漏洞。
第二种常见攻击手法，是搜索包含热门软件默认凭证的代码仓库。攻击者利用这些凭证，可以针对生产环境中存在的账户或某些设备默认安装的账户，开发并测试攻击方案。
Datadog高级安全工程师Julie Agnes Sparks在一篇博客文章中写道："这些活动并非出自单一攻击者，而是定制化自动扫描工具、对泄露凭证的机会性滥用，以及由'幽灵'账号（即一次性账号）组成的协作网络的混合体。"
Sparks解释称，出于设计考量，GitHub有"相当大比例"的API接口无需身份验证即可访问。对这些API的请求通常会返回标准的HTTP 200响应。
这意味着威胁行为者可以详细绘制出一个组织的公开代码仓库、成员信息、关注对象、收藏项目以及互动过的项目。她表示，这类流量与正常API调用混杂在一起，因此不会引发警觉。
此外，GitHub仅在用户与私有仓库交互时才会收集地理位置数据，记录访问者身份及所用访问令牌，而与外部资源的交互则不作记录。这限制了基于地理位置和VPN/代理的溯源能力。
攻击者通常使用自定义或听起来合法的用户代理进行自动化数据抓取，并利用GitHub"幽灵"账号——这些账号创建于两到五年前，此后一直处于休眠状态。
这种方式极具吸引力，因为正如Sparks所指出的："一个拥有多年历史的账号，看起来比同一周注册就开始抓取数据的账号更具可信度。"
这些账号通常会在同一时期对多家企业发起短暂的"爆发式"活动，持续时间仅为一到三周，随后便停止使用。研究人员识别出超过50个幽灵账号，分布于多个用户代理之下，并按名称聚类为不同家族，例如user432023、user412023或kobalt*等。
部分攻击活动还利用了真实GitHub用户的合法账号，这些用户曾无意间将OAuth令牌或个人访问令牌（PAT）暴露在公开内容中，或其终端设备遭到入侵或以其他方式被泄露。
攻击者使用的数据渗出工具名称各异，包括GitHub-Company-Scraper、GitHub-Scraper-Tool/1.0和GitHubAnalytics/1.5等，刻意设计为与正常数据分析流量相混淆。Sparks指出，大量请求指向开源查询语言/graphql接口，该接口"非常适合"对企业、用户和代码仓库进行批量查询；而标准REST接口则被用于组织架构映射。
Sparks表示，此类攻击活动的焦点"集中而一致"，真正的隐患"在于累积效应"。单独来看，这些请求针对的是无需身份验证的公开代码仓库，且能成功返回响应，但这极少能真正"获取"企业仓库的实质性访问权限。
然而，一组账号在数周内同步活动、使用共享的GitHub账户并携带版本化定制工具，则代表着一种更为令人警惕的系统性行为。她举例说明了一个事件：数十个不同的合法但已被入侵的GitHub用户账号，在短短几分钟内对同一组织发起API请求——尽管该次攻击因目标指向私有代码仓库的提交路径而最终失败。
Sparks指出，"如果监控了正确的字段"，这些行为是可以被检测和追踪的，例如识别用户代理、令牌类型、自治系统号（ASN）或尝试执行的操作等字段。
"用户代理、事件活动和行为者名称，是发现环境中未授权活动的关键线索，"Sparks强调道。她建议重点审查GitHub审计日志中异常的用户代理行为，尤其是那些延伸至私有代码仓库的行为——平台在此类场景下还会记录IP地址、行为者名称和程序化访问类型。
企业还应启用GitHub审计日志流式传输、建立用户代理基线，并主动开展威胁狩猎。最重要的是，她表示企业应针对自身GitHub组织建立专属检测机制，并指出："了解自己环境中什么是正常行为，这一点至关重要。"
Miserendino补充说，简而言之，企业应遵循安全最佳实践，包括：为所有账号启用多因素认证（MFA）、定期审查用户访问权限、删除闲置或不必要的账号，以及扫描代码仓库中以明文存储而非保存在密钥管理系统中的凭证。
Q&A
Q1：GitHub API滥用攻击具体是怎么运作的？
A：攻击者利用GitHub大量无需身份验证即可访问的公共API接口，使用自定义自动化工具对企业组织、成员信息、公开代码仓库等进行批量抓取，绘制出详细的企业画像。由于这类流量与正常API调用高度相似，很难被察觉。攻击者通常还会使用创建多年、长期休眠的"幽灵"账号，使其看起来更像合法用户，从而降低触发警报的风险。
Q2：企业如何检测和防范GitHub API被滥用？
A：Datadog研究人员建议企业重点监控GitHub审计日志中的异常用户代理行为，尤其关注涉及私有代码仓库的访问记录。同时应启用GitHub审计日志流式传输、建立正常用户代理基线，并主动开展威胁狩猎。基础安全措施同样不可忽视，包括为所有账号开启多因素认证、定期审查用户权限、删除闲置账号，以及扫描代码仓库中明文存储的凭证。
Q3：AI智能体的大量使用会加剧GitHub上的安全风险吗？
A：会的。安全专家David Shipley指出，随着越来越多的企业引入AI智能体辅助编码以提升效率，代码仓库中积累的API密钥、云端凭证等敏感信息只会越来越多。这意味着一旦相关仓库遭到攻击或凭证泄露，攻击者能够获取的"战利品"也将远超以往，整体安全风险因此进一步上升。