1. 密钥不是“贴在服务器背面的便签纸”：为什么 Secrets 管理失效会直接击穿 CI/CD 安全底线我见过最惊险的一次线上事故，发生在凌晨两点。一个本该只触发测试流水线的 PR，意外把生产数据库凭证塞进了构建镜像，并通过docker push推到了公开仓库——不是因为代码写错了，而是因为.github/workflows/deploy.yml里一行secrets: ${ { secrets.DB_PASSWORD }}被误放在了jobs.build.steps.run的 shell 脚本里，而非env或with字段下。GitHub Actions 在执行时，把整个字符串原样展开，而那个密码明文出现在了 build log 的第 47 行，被日志采集系统自动归档、索引、暴露。这不是孤例。过去三个月，我们团队在 7 个不同项目中复现了三类高频密钥加密错误：环境变量注入时机错位、Secrets 跨作业泄漏、以及 YAML 模板渲染阶段的提前解密。它们共同指向一个被严重低估的事实：GitHub Actions 的 Secrets 不是“加密后存进保险柜”，而是“运行时按需解密并注入进程环境”。一旦你写的 workflow 文件本身存在结构漏洞，再强的 AES-256 加密也形同虚设。这和你在本地用 AI 编程工具（比如 Cursor、Trae 或 Claude Code）生成 CI 配置时的体验高度相关。AI 工具能秒级输出一个带secrets字段的 Y