源码托管前必须清理的敏感数据类型
开发者在提交代码到GitHub、GitLab等平台时，常常会无意间将以下敏感信息留在代码库中：
自动化扫描工具推荐
| 工具名称 | 适用语言 | 检测能力 |
|---|---|---|
| GitGuardian | 全语言 | 实时监控+历史扫描 |
| TruffleHog | 全语言 | 熵值检测+正则匹配 |
| Gitleaks | 全语言 | 规则自定义+CI集成 |
彻底清理Git历史的三种方法
BFG Repo-Cleaner使用指南
这个Java工具比git filter-branch快10-50倍，特别适合大仓库：
java -jar bfg.jar replace-text replacements.txt my-repo.gitGit filter-branch操作流程
虽然速度较慢但更灵活：
git filter-branch force index-filter
"git rm cached ignore-unmatch config/database.yml"
prune-empty tag-name-filter cat -
all 完全重建仓库
对于极端情况可以考虑：
预防敏感信息泄露的日常实践
开发团队应该建立这些防护机制：
企业级代码审计方案
中大型企业需要建立多层次的防护体系：
清理完Git历史后发现旧代码还能在某些网站看到？这其实挺常见的，因为像GitHub这样的平台和搜索引擎都会缓存代码内容。就算你在本地仓库彻底清除了敏感信息，那些第三方镜像站点、代码搜索引擎可能已经抓取并保存了历史版本。特别是像Sourcegraph、GitHut这类专门做代码搜索的服务，它们的数据更新往往会有1-3天的延迟。
遇到这种情况别慌，有几种应对方法可以试试。首先直接联系平台支持团队提交删除请求，大多数正规平台都有数据清除流程。其次记得去Google Search Console提交内容移除申请，这样能加快搜索引擎更新缓存的速度。另外别忘了检查archive.org这类网页时光机，它们可能保存了历史快照。整个过程可能需要耐心等待3-7天，期间 持续监控那些可能缓存了代码的站点，必要时可以多次提交清除请求。
常见问题解答
已经提交到公开仓库的敏感信息该如何处理？
发现泄露后应立即执行以下步骤：1) 立即撤销泄露的密钥或凭证 2) 使用BFG或git filter-branch清理历史记录 3) 强制推送更新后的仓库 4) 通知可能受影响的相关方。对于特别敏感的信息， 直接联系平台支持团队。
如何确保团队新成员不会误提交敏感信息？
建立代码提交前的三重防护机制：1) 在开发环境配置pre-commit钩子进行本地扫描 2) 在CI流程中加入敏感信息检测步骤 3) 设置代码仓库的push拦截规则。同时要对新人进行专门的代码安全培训，重点讲解.gitignore配置和密钥管理规范。
哪些文件类型最容易包含敏感信息？
需要特别检查这些文件类型：1) 配置文件(.env/.properties/.yml) 2) 数据库脚本(.sql) 3) 日志文件(.log) 4) 测试数据文件(.json/.csv) 5) 文档文件(.md/.txt)。其中.env文件在5-10人的小团队项目中最常出现密钥泄露问题。
自动化工具能否检测出所有类型的敏感信息？
虽然工具能检测90%以上的常见敏感信息，但仍存在局限：1) 自定义加密格式可能被误判 2) 拆分存储的凭证难以识别 3) 图片中的文字信息无法解析。 结合人工代码审查，特别要检查5-20个历史提交记录中的变更内容。
清理Git历史后为什么还能在某些网站看到旧代码？
这是因为公共代码平台和搜索引擎会有缓存机制，处理方案包括：1) 提交删除请求给平台方 2) 在Google Search Console提交移除申请 3) 检查archive.org等网页存档站点。整个过程可能需要3-7个工作日才能完全生效。
