为什么源码托管前必须清理敏感信息？
最近GitHub上又爆出多起企业源码泄露事件，都是因为开发者直接把包含数据库密码、API密钥的代码上传到了公开仓库。你可能觉得”我的项目不重要，没人会看”，但黑客的爬虫可不会挑食——它们会批量扫描所有公开仓库，专门寻找这类低级错误。
去年某电商平台就因为员工把AWS密钥硬编码在JavaScript文件里，导致黑客盗取了价值200万的云计算资源。更可怕的是，这些泄露的密钥往往会被转卖到暗网，形成长期的安全威胁。
源码中常见的敏感信息类型
硬编码的凭证信息
容易被忽视的敏感数据
| 信息类型 | 危险等级 | 常见位置 |
|---|---|---|
| 数据库密码 | 高危 | .env/config.json |
| API密钥 | 高危 | 源代码注释 |
| 加密密钥 | 致命 | security.py |
自动化扫描工具推荐
GitLeaks
这个开源工具能像猎犬一样嗅出代码库中的敏感信息，支持50多种凭证模式识别。安装后只需运行gitleaks detect -v，它就会扫描整个项目历史，连三年前提交的密码都能找出来。
TruffleHog
专门检测高熵字符串的神器，特别擅长发现那些随机生成的密钥。它会分析git提交历史中的每个字符变化，比正则表达式检测更精准。集成到CI/CD流程后，能自动阻断包含敏感信息的提交。
AWS CLI的credential-scanner
如果你是AWS用户，官方提供的这个扫描工具一定要试试。它能识别出IAM密钥、S3桶权限等AWS特有的敏感配置，还能给出具体的风险评分。
手动检查的七个关键步骤
用IDE的全局搜索功能，查找所有=、:后面的字符串值，特别是包含”key”、”secret”、”pass”等关键词的变量
从根目录开始，逐层检查每个config/目录，重点查看.yml、.properties、.toml等配置文件
很多开发者会不小心在构建脚本里写入apt-get install的密码或者wget的认证信息
测试用例里经常包含真实的手机号、身份证号等测试数据
确保日志文件、本地环境配置等没有被意外提交
有时候敏感信息会藏在被合并的分支里
启动服务时，注意观察控制台是否打印了数据库连接信息等敏感日志
Git历史记录彻底清理指南
就算你已经删除了敏感文件，它们在git历史中仍然存在。这时候需要用到git filter-branch这个核武器级命令：
git filter-branch force index-filter
"git rm cached ignore-unmatch config/database.yml"
prune-empty tag-name-filter cat -
all 这个命令会重写整个git历史，永久删除指定文件的所有痕迹。注意操作前一定要备份仓库，因为改写历史会影响所有协作者。
对于更复杂的清理需求， 使用BFG Repo-Cleaner工具。它比原生git命令快10-100倍，特别适合大型仓库：
java -jar bfg.jar replace-text passwords.txt my-repo.git敏感信息的正确存储方式
该用环境变量的时候别偷懒！现代应用都应该遵循12-Factor原则，把配置严格隔离：
.env文件（记得加入.gitignore）对于必须加密存储的数据，推荐这些方案：
HashiCorp的开源密钥管理工具，支持动态生成临时凭证
云服务商提供的托管解决方案，自带审计日志
支持YAML/JSON/ENV文件加密，能与git完美配合
如果已经在用Ansible，这是最轻量级的解决方案
自动化扫描工具就像安检设备一样，虽然能快速筛查可疑物品，但总会有把水杯误认为危险品的情况。这些工具主要依靠正则表达式和熵值分析来识别敏感信息，所以遇到类似密码格式的正常代码（比如测试用的假密码”123456″）就可能误报。更麻烦的是漏报问题，特别是那些不符合常见模式的业务敏感信息，比如你们公司内部使用的特殊格式的API密钥，工具很可能直接放行。
实际使用中 搞个”三重安检”方案：先用GitLeaks扫一遍基础敏感词，再用TruffleHog查高熵字符串，最后用自己写的业务规则补刀。我们团队就吃过亏，有次漏掉了一个特殊格式的数据库连接字符串，后来专门为这种格式写了自定义规则。记住，工具给出的结果永远需要人工复核，特别是对那些标记为”可疑但不确定”的条目要重点检查。
如何判断代码中哪些信息属于敏感信息？
敏感信息通常包括能直接访问系统或数据的凭证（如密码、API密钥）、个人隐私数据（如身份证号、银行卡号）以及内部系统配置（如数据库连接字符串）。一个简单的判断标准是：如果这段信息泄露可能导致系统被入侵或用户隐私曝光，就必须视为敏感信息。不确定时可以问自己”这个信息公开后会不会被黑客利用”。
已经提交到Git仓库的敏感信息该如何补救？
如果敏感信息已经提交到Git仓库，需要立即采取三步措施：1) 使用git filter-branch或BFG工具从历史记录中彻底删除相关文件；2) 在相关服务平台（如AWS、支付接口）立即轮换所有泄露的密钥；3) 通知可能受影响的相关方。注意仅仅删除最新提交是不够的，必须清理整个git历史。
为什么.env文件加入.gitignore后仍然可能泄露？
常见的错误场景包括：1) 开发者在早期提交中忘记添加.gitignore，后来才补上；2) 将.env.example重命名为.env时忘记先删除原文件；3) 在合并分支时忽略冲突导致.env被意外提交。最保险的做法是使用pre-commit钩子检查敏感文件，并在CI流程中加入自动扫描。
自动化扫描工具会误报或漏报吗？
所有扫描工具都存在一定误报率（把正常代码识别为敏感信息）和漏报率（未能发现真正的敏感信息）。 组合使用2-3种工具（如GitLeaks+TruffleHog），并配合人工审查。对于高熵字符串（如加密密钥）的检测准确率通常能达到90-95%，但对业务特定的敏感数据（如内部接口地址）可能需要自定义规则。
小型个人项目也需要这样严格处理吗？
绝对需要。黑客的自动化工具不会区分项目规模，很多个人开发者的测试用密钥被盗后，会被用来发起DDoS攻击或挖矿。曾有案例显示，一个学生练习项目泄露的API密钥导致云服务商产生数千元账单。即使是私人仓库也应做好防护，因为你无法保证仓库永远不会意外转为公开。
