git log -p 比 git diff 更适合查历史泄露，因其能逐条展开所有提交的补丁内容，覆盖已被删除但曾存在的敏感凭证，而 git diff 仅比对工作区或暂存区，遗漏历史快照。
为什么 git log -p 比 git diff 更适合查历史泄露？
因为敏感凭证常藏在已提交但后来被删掉的代码里，git diff 只比对工作区或暂存区，漏掉历史快照。git log -p 能逐条展开每次提交的补丁内容，覆盖所有可能埋雷的位置。
实操建议：
- 用
git log -p --all --grep=""配合grep做关键词扫描，比如git log -p --all | grep -i "password\|apikey\|secret" - 加
--since="3 months ago"限制时间范围，避免全量扫描拖慢脚本 - 注意
--all包含所有分支和 reflog，但不包含 stash；如需查 stash，额外加git stash list -p | grep -i ... - 某些凭证（如 Base64 编码的 token）会逃过明文匹配，后续得加解码逻辑，别只靠字符串匹配
怎么用 git ls-files 避免扫描二进制或忽略文件？
直接 git grep 扫整个工作区容易误报：.zip、.png、node_modules 下的第三方库都可能含 “password” 字样，但跟项目无关。
正确做法是先筛出真正受版本控制的文本文件：
- 用
git ls-files --exclude-standard获取干净的 tracked 文件列表 - 过滤后缀：
git ls-files --exclude-standard | grep -E "\.(js|py|java|env|yml|json|xml|ts)$" - 再对这些文件做行级扫描：
xargs -I{} sh -c 'grep -n -i "aws_secret.*[0-9a-zA-Z]" {} 2>/dev/null' - 跳过 vendor 目录：
git ls-files --exclude-standard | grep -v "/vendor/" | grep -v "/node_modules/"
git rev-list 如何精准定位首次引入敏感词的提交？
发现泄露后，光知道“有”不够，得快速定位谁、什么时候、在哪一行加的——这对追责和修复最关键。
用 git rev-list 结合 git blame 是最稳路径：
- 先用
git rev-list --all --grep="API_KEY"找到含关键词的 commit hash - 再用
git show <code>COMMIT_HASH--name-only 看改了哪些文件 - 对具体文件执行
git blame -w -M -C <code>FILE_PATH| grep -i "secret"，-w忽略空格变更，-M/-C支持移动/复制检测 - 注意：如果该行后来被修改过但关键词没删，
git blame显示的是最后一次修改者，不是原始引入者；必须配合git log -S
为什么正则写成 aws_[a-z]+_key 比 aws.*key 更安全？
宽泛正则会大量误报：比如注释里写 “aws usage key is deprecated”，或者变量名 aws_backup_key_path 是合法字段，但匹配 aws.*key 就报警，导致脚本不可信。
推荐策略：
- 用单词边界锚定：
\baws_[a-z]+_key\b，排除中间夹杂其他字符的情况 - 区分环境：
^SECRET_KEY=（.env 文件开头）、"token":\s*"[a-zA-Z0-9+/=]{20,}"（JWT-like token） - 排除常见误报模式：加
grep -v "example\|test\|demo\|placeholder" - 硬编码密钥往往带固定格式，比如 AWS access key 是
AKIA[0-9A-Z]{16}，比泛搜 “aws_access_key” 更准
真正难处理的是拼接生成的密钥（如 os.getenv("KEY_PREFIX") + "_prod"），这种静态扫描无能为力，得靠 pre-commit hook + 动态测试兜底。
