GitHub存档记录了所有公开提交，包括开发者试图删除的提交。强制推送通常会覆盖错误，如泄露的凭证，但GitHub会永久保留这些“零提交”的推送事件。通过扫描2020年以来的这些事件，发现了价值2.5万美元的漏洞赏金。与Truffle Security合作，开源了一个新工具，用于扫描GitHub组织中的这些隐藏提交。

本文由白帽黑客Sharon Brizinov撰写，详细介绍了如何通过扫描GitHub上的“Oops Commits”（即被强制推送删除的提交）来发现泄露的敏感信息。主要内容包括：

1. 背景与动机：Sharon Brizinov通常专注于OT/IoT设备的漏洞研究，但偶尔也会参与漏洞赏金活动。他通过之前的博客文章发现，GitHub上的删除操作并不能真正删除提交，这些提交仍然可以通过某些方式访问。基于此，他决定进一步研究如何大规模扫描这些被删除的提交，以发现潜在的敏感信息泄露。

2. GitHub提交删除的机制：GitHub会记录所有公开的提交，即使开发者通过强制推送（force push）删除了某些提交，GitHub仍然会保留这些“悬空提交”（dangling commits）。这些提交在GitHub的存档中显示为“零提交”的PushEvent事件。通过GitHub的Event API和GitHub Archive项目，Sharon能够扫描这些被删除的提交，并发现其中的敏感信息。

3. 自动化扫描工具的开发：Sharon与Truffle Security合作，开发了一个开源工具——Force Push Scanner，用于扫描GitHub组织中的这些被删除的提交。该工具通过GitHub Archive获取所有零提交的PushEvent事件，并利用TruffleHog扫描这些提交中的敏感信息。

4. 大规模扫描与结果：Sharon使用该工具扫描了自2020年以来GitHub上的所有“Oops Commits”，发现了大量活跃的敏感信息，包括GitHub个人访问令牌（PAT）、AWS凭证等。通过这些发现，他获得了约25,000美元的漏洞赏金。

5. 案例研究：Sharon分享了一个具体的案例，他在一个被删除的提交中发现了一个GitHub PAT，该令牌拥有对Istio项目的所有仓库的管理员权限。Istio是一个广泛使用的开源服务网格，拥有大量用户和贡献者。Sharon及时报告了这一问题，避免了潜在的供应链攻击。

6. 总结与建议：Sharon强调，删除提交并不意味着敏感信息被安全删除，一旦敏感信息被提交到GitHub，就应该被视为已泄露，并立即撤销相关凭证。他呼吁开发者和管理员提高对这类问题的认识，并采取相应的安全措施。

本文不仅展示了如何通过技术手段发现GitHub上的敏感信息泄露，还提供了实用的工具和方法，帮助组织和个人更好地保护自己的代码和数据安全。

评论内容主要围绕Git提交中的敏感信息泄露问题展开，以下是主要观点和论据的总结：

1. Git提交的不可逆性

• 观点：Git提交一旦公开，很难彻底删除，敏感信息可能永久存在。
• 论据：
  • "Git never forgets, this isn't really a shocking revelation."（Git永远不会忘记，这并不令人惊讶。） - SillyUsername
  • "Git is really a content addressed storage. This means all commits, even the ones not linked to any refs are still stored and addressable."（Git本质上是一个内容寻址存储。这意味着所有提交，即使没有链接到任何引用，仍然被存储并可访问。） - abhisek

2. 删除提交的局限性

• 观点：删除提交或强制推送并不足以彻底清除敏感信息。
• 论据：
  • "Deleting a commit is not enough, use BFG Cleaner, and force commit to change history."（删除提交是不够的，使用BFG Cleaner，并强制提交以更改历史记录。） - v3ss0n
  • "Not if you contact customer support and ask them to garbage collect your repo."（除非你联系客户支持并要求他们进行垃圾回收。） - oefrha

3. 密钥轮换的重要性

• 观点：一旦敏感信息泄露，应立即轮换密钥以降低风险。
• 论据：
  • "Once it is on the internet - it is always there so Rotate the key/secrets FIRST."（一旦信息在互联网上，它就永远存在，所以首先要轮换密钥/秘密。） - v3ss0n
  • "One more reason to activate key rotation."（这是激活密钥轮换的又一个原因。） - diogolsq

4. 预防措施

• 观点：开发者应采取预防措施，避免敏感信息被提交到Git。
• 论据：
  • "All devs should run open-source trufflehog as a precommit hook for all repositories on their local system."（所有开发者都应该在本地系统的所有仓库中运行开源的trufflehog作为预提交钩子。） - edverma2
  • "I started abusing environment variables. If you have enough discipline to spend 10 seconds configuring them, you'll never have to worry about magic strings accidentally getting sucked up into source control."（我开始滥用环境变量。如果你有足够的纪律性花10秒钟配置它们，你就不必担心魔术字符串意外地被吸入源代码控制。） - bob1029

5. GitHub的特定问题

• 观点：GitHub的某些功能（如活动标签）可能会永久记录敏感信息。
• 论据：
  • "The activity tab has everything. Any force push to hide ugly prototype code is kept forever."（活动标签记录了一切。任何强制推送以隐藏丑陋的原型代码都会被永久保存。） - Pwhy1
  • "GitHub keeps these dangling commits, from what we can tell, forever."（GitHub会永久保存这些悬空提交。） - oefrha

6. 替代工具和解决方案

• 观点：开发者可以考虑使用其他工具或平台来避免GitHub的问题。
• 论据：
  • "IMO Jujutsu is mature enough for daily usages, and Fossil is a neat alternative if one wants to drop GitHub completely."（我认为Jujutsu已经足够成熟，可以日常使用，而Fossil是一个不错的替代品，如果你想完全放弃GitHub。） - xlii
  • "Finding secrets in 'oops commits' can be tricky. You might want to try MailsAI to help track and manage sensitive data exposure."（在“意外提交”中查找秘密可能很棘手。你可以尝试使用MailsAI来帮助跟踪和管理敏感数据泄露。） - CHUCKZZZ

总结：

评论中普遍认为Git提交的不可逆性和GitHub的特定功能使得敏感信息一旦泄露很难彻底清除。开发者应采取预防措施，如使用预提交钩子、环境变量和密钥轮换，以降低风险。此外，联系GitHub客户支持进行垃圾回收也是一种解决方案。