敏感数据暴露，留给Git的时间只有20秒！

​作者 | codingwoman

译者 | 布加迪

策划 | 言征

大家可能都会面临这样直冒冷汗的敏感秒情形：在使用Git进行版本控制时不小心推送了重要的密钥或超大文件
？要知道 ，在敏感数据公开暴露20秒后，数据时间再去删除这些密钥可能已经为时太晚了！暴露

人非圣贤
，敏感秒孰能无过
？数据时间本文会分享介绍几个笔者在用的好技巧
，这样在Git时  ，暴露再也不用担惊受怕了
。敏感秒

一
、数据时间永远不要推送非必要的暴露文件和信息

Git中一类不需要的内容是非常大的文件。如果不小心提交了一个大文件到存储库，云计算敏感秒这肯定会限制你拉取或推送文件所需的数据时间时间；如果文件大于100MB ，甚至还会显示错误。暴露

其次，敏感秒作为软件开发圈中的数据时间一员，这个忠告应该听过很多次
 ：永远不要将机密信息推送到存储库。暴露拥有芝麻粒大点资源的攻击者就可以通过窃取泄露的密文（secrets）和密钥来危及许多GitHub用户。然而，许多同行却对此不太当回事 。

因此，我想分享几个统计数据 。

我能进行另一个提交后删除它吗？

不。事实上 ，源码库这比刚才的那件事还要危险。不要天真地以为，当他们从存储库中删除文件后，文件再也访问不了。这正是Git的用途所在。它会跟踪你的文件版本历史记录，以便你在想要恢复更改时可以恢复。

通过以下列方式进行提交以删除文件，你无异于将网上的陌生人引向存放密文的位置 。

复制$ git commit –m “Remove api key”1.

只需你搜索一下，源码下载就可以看到这有多频繁。更明确地说，截止2023年1月5日笔者撰写这篇文章期间
，在GitHub上搜索查询“remove api key”，返回了100万+提交，查询“remove password”返回了735K+提交 。

随着ChatGPT大行其道，人们试图编写Python脚本来试用它 ，我发现无数的OpenAI API密钥散布在GitHub的各个角落。

这将引发严重后果 ！

二、那该怎么办？

当我们考虑从Git历史记录中删除提交时 ，首先想到的是建站模板立即将分支的顶端更改为旧的提交。这使我们安全地回到密钥不存在于存储库中的时候 。

复制1 $ git reset <SHA1>2 $ git commit -

am message

3 $ git push -f <remote-name> <branch-name>1.2.3. 1.但已有一段时间了，是否为时太晚 ？

好吧，如果你遇到的问题与大文件有关，总是可以使用git filter-branch从历史记录中删除过去的信息/文件
。此外 ，还有一个极好极简单的方法 ，香港云服务器我常常使用它。

见识一下BFG-Repo-Cleaner ！这是一个用Scala编写的工具，可以删除大文件（比如预训练的模型或无法丢弃的大PDF文件）或麻烦的blob（比如API密钥
、密码和密文），其功能就像git filter-branch ，但速度更快。

GitHub的官方推荐也建议使用BFG-Repo-Cleaner来清除文件 。

说明 ：我最近被告知git filter-branch已被弃用。现在可以使用git filter-repo或直接使用上面提到的模板下载BFG工具。

2.可以松口气了吗？

不
，还不能松口气。当然，你可以随时使用这个工具删除大文件。然而，在将不必要的凭据推送到公共存储库之前，仍然应该小心为好
。如果你最近在GitHub上泄露了密文 ，应该尽快用上面提到的工具收回密文。

此前，有一篇名为《Git会有多糟糕
？揭秘公共GitHub存储库中的密文泄露》的论文首次全面深入分析了GitHub上的密文泄露。研究人员在文中评估了两种不同的挖掘密文的方法
 ：一种能够实时发现99%的新提交的含有密文的文件，另一种利用了覆盖13%的公共存储库的大快照 ，其中一些可以追溯到GitHub创建时的快照。

你认为大多数被发现的密钥都用于测试吗 ？好吧 ，告诉你一个可怕的消息：研究人员估计，所有发现的密文中89.10%是敏感信息。几个趋势 ：密文减少最明显的时候是在发现后的第一个小时，所有发现的密文中6%被移除。存在时间超过一天的密文往往长期存在——第一天结束时，12%以上的密文消失了 ，而16天后，只有19%的密文消失了。密文和文件被删除的速度大大超过代码库被删除的速度：用户没有删除代码库，而是创建新的提交以删除文件或密文。最后
，最重要的结论是 ：发现GitHub上分享的密文的平均时间为20秒左右，从半秒到4分钟不等 ，密文在一天中的什么时间被推送没有任何影响。所以在你不小心推送之后，留给你弥补的时间 ，比想象的要少得多。

三、结语

GitHub应该对可能暴露密文的提交 ，实行严格得多的政策或检查
。或者至少将新注册的帐户引到相应的说明文档发出警告。笔者认为这对于刚开始踏上编程之旅的新人来说尤为重要。开发人员（尤其是新手）应该知道如何安全地公开源代码
，以及忽视这么做可能面临的后果。

如何才能避免意外提交？这里给出几点建议：

避免使用像git add.或git commit-a这样的catch-all命令 ，而是使用git add filename。单独暂存文件也可以更好地跟踪提交方面的更改 。你总是可以在流行的文本/源代码编辑器（比如Visual Studio Code）的源代码控制组件中使用暂存选项 
。始终查看你的文件更改。使用git diff--cached，密切关注工作树上的变化。还有其他类型的工具可以帮助你避免提交像git-secrets这样的密钥 。你还可以使用预提交钩子。

原文链接：http://www.codingwoman.com/git-the-good-the-bad-and-the-ugly/