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

很赞哦!（75199）