敏感数据暴露，留给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/