保护你的Git仓库：最佳实践与不可信来源

保护Git仓库不仅仅是保持代码私有。一个仓库可能包含机密信息、可执行钩子、供应链风险、敏感历史记录以及影响每个克隆它的开发者的配置。

良好的Git安全实践有助于避免凭证泄露、不安全的自动化以及对未知来源代码的意外信任。基本原则很简单，但需要持续应用。

在机密进入Git之前保护它们

最安全的机密是那些从未进入仓库的机密。API密钥、SSH私钥、云凭证、数据库密码、令牌以及.env文件应完全远离Git。

将本地机密文件添加到.gitignore：

.env
.env.*
*.pem
id_rsa
id_ed25519

小心处理.env.example。该文件通常有用，但应包含虚假的占位值：

DATABASE_URL=postgres://user:password@localhost:5432/app
API_TOKEN=replace-me

不要粘贴真实值“仅用于测试”。Git历史会记住旧版本，即使你在后续提交中删除了一行。

如果你意外提交了机密，将其视为已泄露。从当前树中移除它，在颁发该凭证的服务中轮换凭证，然后决定是否需要清理历史记录。重写历史有助于减少未来的暴露，但不能保证机密从未被复制。

团队还应使用机密扫描。许多托管Git平台提供常见令牌模式的扫描。本地预提交工具可以在推送到达服务器之前更早地捕获错误。

有关相关的操作模式，请参阅掌握环境变量以进行配置和机密管理。

锁定访问和分支更改

仓库安全始于访问控制。给予人们所需的最小访问权限。仅审查代码的人可能不需要管理员权限。CI服务账户可能不需要重写分支的权限。

定期审查以下设置：

• 仓库管理员和所有者。
• 具有写入权限的协作者。
• 部署密钥和机器用户。
• 自动化使用的个人访问令牌。
• 接收仓库事件的Webhook。
• 分支保护规则。

受保护分支是最有用的控制之一。对于像main这样的重要分支，要求合并前进行拉取请求、状态检查和审查。除非团队有非常具体的理由，否则禁用强制推送。

在更高信任的环境中，签名提交或签名标签也可能有帮助。它们本身不能使代码安全，但可以证明提交或发布标签是由团队认可的密钥创建的。

谨慎使用标签进行发布。如果部署过程信任标签，限制谁可以创建或移动它们。移动的发布标签可能会混淆审计和部署。

谨慎处理不可信仓库

从不可信来源克隆代码很常见。立即运行它才是风险所在。Git仓库可能包含构建脚本、包生命周期脚本、Makefile、容器、CI配置以及在你的机器上执行代码的指令。

在运行任何内容之前，检查仓库：

git clone --no-checkout https://example.com/project.git
cd project
git log --oneline -5
git status

然后检查高风险文件：

• Shell脚本，如install.sh或bootstrap.sh。
• package.json中的包脚本。
• CI文件，如.github/workflows/、.gitlab-ci.yml或类似路径。
• Dockerfile和compose文件。
• Makefile。
• 特定语言的依赖清单。

不要从随机的README中运行curl | bash设置命令。如果项目需要安装程序，请下载它，阅读它，并在可能的情况下在一次性环境中运行它。

Git钩子值得特别提及。.git/hooks/中的钩子在克隆仓库时通常不会作为活动钩子传输。这很好。但仓库可能包含为你安装钩子的脚本。在运行这些脚本之前阅读它们，因为钩子可以在提交、合并、变基和推送期间执行。

对于未知代码，使用隔离。临时虚拟机、容器或锁定开发环境可以减少脚本行为异常时的爆炸半径。不要将SSH密钥、云凭证或生产kubeconfig挂载到用于不可信代码的环境中。

保持仓库历史记录和文件整洁

当仓库整洁时，安全性更容易。大型二进制文件、生成的归档文件、供应商机密和旧配置转储使审查更困难并增加风险。

使用.gitignore处理本地文件，使用.gitattributes处理文件处理规则。例如：

*.sh text eol=lf
*.png binary
*.jpg binary

如果项目需要大文件，考虑是否适合使用Git Large File Storage。标准Git不适合大型构建工件或媒体文件。直接存储它们可能会减慢克隆速度并使敏感文件清理更加困难。

审查拉取请求中的安全敏感更改，而不仅仅是应用程序逻辑。注意：

• 新的凭证或令牌。
• 脚本中的新网络调用。
• 依赖源更改。
• 新的CI权限。
• 部署脚本的更改。
• 隐藏重要文件的宽泛.gitignore更改。

还要注意子模块。它们指向外部仓库和特定提交。如果项目使用它们，请仔细审查子模块URL和更新。

何时寻求专业帮助

如果机密被推送到公共仓库、受保护分支被意外强制推送、或未知贡献者更改了CI或部署自动化，请引入安全工程师、DevOps负责人或事件响应负责人。

如果你怀疑仓库历史记录被篡改，也应寻求帮助。保留证据可能比快速清理更重要，尤其是在公司环境中。

保护Git仓库归结为有纪律的信任。保持机密不泄露、限制访问、保护重要分支，并在运行之前检查不可信代码。这些习惯可以在大多数仓库安全问题演变为事件之前预防它们。