不安全源码管理

要解决的问题

部署流水线里一个高频失误，是把版本控制目录原样带到了线上。Web 服务器可能对 /.git/ 返回 403 禁止列目录，但 /.git/HEAD 这类具体文件仍返回 200。攻击者拿到 HEAD 中的 ref: refs/heads/xxx 引用，再逐文件抓取 config、logs/HEAD、objects/ 下的 pack 块，就能在本地把整个仓库拼回来——包括提交历史中残留的凭证和内部地址。SVN、Mercurial、Bazaar 存在同构问题。

核心能力

按版本控制系统分四条探测线：

• Git：先探 /.git/HEAD 确认引用格式，再区分 403 与 404——目录 403 而 HEAD 200 是高置信度暴露信号。恢复可用 arthaud/git-dumper、internetwache/GitTools、WangYihang/GitHacker。
• SVN：1.7 之前看 /.svn/entries，之后看 /.svn/wc.db（SQLite 表结构可直接查询），工具用 anantshri/svn-extractor，也可手工取 pristine blob。
• Mercurial / Bazaar：以 /.hg/requires、/.bzr/README 作为存在性指纹，分别接 sahildhar/mercurial_source_code_dumper 与路径遍历。
• 周边产物：/.DS_Store（用 gehaxelt/ds-store、lijiejie/ds_store_exp 离线解析）、/.env、常见备份后缀。NGINX 的 location /.git { deny all; } 只拦目录列，拦不住单文件请求。

使用边界

仅用于已获授权的评估。恢复出的凭证和 URL 一律按敏感数据处理，不要越界外传真实数据。若工作区同时装有 recon-for-sec 和 recon-and-methodology，先由它们完成范围划定、限速与指纹识别，再做针对性 VCS 校验，避免把大规模发现与逐文件抓取混在一轮里。