CI/CD 流程中存储 Git 私有 token 最安全的方式是使用 CI/CD 平台提供的加密秘密管理功能（如 GitHub Secrets 或 GitLab CI Variables），严禁将 token 硬编码在代码仓库或构建脚本中。适用场景涵盖所有自动化构建、部署流程，风险边界在于需防止 token 被打印到构建日志或被第三方行动滥用。

快速处理思路

大部分 CI/CD 平台通过网页界面配置秘密变量，部分支持命令行工具设置。GitHub Actions 可使用 GitHub CLI 设置，GitLab CI 主要在网页端操作，Jenkins 凭据管理器支持 API 调用。操作前确认当前使用的 CI/CD 平台版本支持加密存储功能。

为什么会这样

硬编码 token 会导致凭证随代码提交进入版本历史，即使删除文件也无法清除历史记录。CI/CD 平台的秘密管理功能会在存储层加密数据，并在运行时注入环境变量，同时自动脱敏构建日志。公开资料中没有看到可靠的量化数据表明哪种平台加密算法更安全，但主流平台均遵循行业标准的加密存储实践。

分步处理

第一步生成最小权限 token。在 Git 托管平台创建 Fine-grained token，仅勾选当前 CI/CD 流程所需的仓库权限和只读权限，避免使用拥有全权访问能力的 Classic token。

第二步存入 CI/CD 秘密管理。进入 CI/CD 平台设置页面，找到 Secrets 或 Variables 菜单，新建变量名如 GIT_TOKEN，将 token 值粘贴到价值栏并开启加密选项。GitHub Actions 对应 Settings > Secrets and variables > Actions，GitLab CI 对应 Settings > CI/CD > Variables。

第三步在流水线中引用。在 YAML 配置文件中通过平台语法引用变量，GitHub Actions 使用${{ secrets.GIT_TOKEN }}，GitLab CI 使用$GIT_TOKEN。避免在echo或print命令中直接输出该变量。

第四步定期轮换凭证。设置日历提醒每 90 天或半年更新一次 token，生成新 token 后更新 CI/CD 秘密变量，并在 Git 平台撤销旧 token。

怎么验证是否生效

检查构建日志中是否出现***脱敏符号。触发一次包含该 token 使用的构建任务，查看日志输出，确认 token 值未被明文打印。使用git log -p检查代码仓库历史，确认从未有 token 明文提交记录。若发现历史提交中包含 token，需立即撤销该 token 并使用git filter-repo工具清洗历史记录。

常见坑

避免将秘密变量传递给第三方 Action 或插件。部分第三方构建插件可能记录输入参数到外部日志服务，导致 token 泄露。不要在脚本中使用set -x调试模式，该模式会打印所有执行命令及环境变量值。限制秘密变量的作用范围，仅在需要的特定 Job 或 Stage 中注入，而非全局环境变量。

常见问题

Token 已经泄露到代码历史怎么办

立即在 Git 平台撤销该 token 并生成新 token。使用git filter-repo或BFG Repo-Cleaner工具清除历史记录中的敏感数据，强制推送清理后的仓库。

可以在本地环境变量存储 token 吗

不建议在本地长期存储，仅适合临时调试。本地环境变量容易因配置文件误提交而泄露，生产环境必须使用 CI/CD 平台秘密管理。

Jenkins 如何安全存储 Git token

使用 Jenkins 凭据管理器（Credentials Binding Plugin）。在 Jenkins dashboard 选择凭据->系统->全局凭据，添加 Secret text 类型，流水线中使用withCredentials块调用。

参考来源

• GitHub Docs, "Encrypted secrets", https://docs.github.com/en/actions/security-guides/encrypted-secrets
• GitLab Docs, "CI/CD variables", https://docs.gitlab.com/ee/ci/variables/
• Jenkins Docs, "Credentials Binding Plugin", https://plugins.jenkins.io/credentials-binding/