把网站项目、自动化脚本或 AI 工具示例推到 GitHub 前，先按这套 SOP 做密钥泄漏预防：本地检查、push protection、告警处理和轮换记录都要有。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
AI 工具、网站发布脚本和自动化项目越来越容易把 API key、Webhook secret、数据库连接串写进示例代码。推到 GitHub 前先做密钥泄漏预防，成本远低于公开后再撤销、轮换和清理历史。
更新日期与来源依据
更新日期：2026-06-28。GitHub Docs 说明，secret scanning 会检测提交到仓库的 API keys、passwords、tokens 等硬编码凭据；公共仓库可自动免费运行。文档还说明 push protection 用于在未来泄漏发生前阻止相关提交，检测到告警时应立即轮换受影响凭据。
公开来源限制为三条：GitHub secret scanning、GitHub push protection、GitHub command line push protection。这里讨论防御性流程，不教绕过检测，也不提供滥用密钥的方法。
适用场景
- 你要把一个网站项目、自动化脚本、CLI 工具、AI agent 示例或课程代码推到 GitHub。
- 仓库里曾经出现 `.env`、配置文件、WordPress 应用密码、Cloudflare token、OpenAI key、Webhook secret 或数据库 URL。
- 团队成员会通过命令行、网页编辑器、Copilot、MCP 工具或自动化脚本提交代码，需要统一处理 push protection 提示。
- 你维护公开仓库，希望让用户复制示例时不会拿到真实密钥或内部地址。
不适用场景
- 已经发生生产密钥泄漏且可能被使用，应按事故响应处理：立即撤销、轮换、审日志、查滥用，再谈清理历史。
- 组织有成熟 Secret Protection、SIEM、审计和强制策略，应把这套 SOP 当个人项目版本，不替代企业安全流程。
- 需要扫描本机所有文件或他人私有仓库的场景，应先确认权限，不要把安全检查变成越权访问。
准备材料
- 一份密钥目录：列出项目可能用到的 key、token、webhook secret、应用密码、数据库 URL 和私有证书。
- 一份忽略规则：`.gitignore` 里明确忽略 `.env`、本地配置、导出备份、日志、临时凭据文件。
- 本地搜索命令：用 `rg` 查常见关键词和项目特有前缀。
- GitHub 仓库安全入口：Security and quality 或对应 Secret scanning alerts 页面。
- 轮换权限：确保你有权限撤销并重建 OpenAI、Cloudflare、GitHub、WordPress、数据库等凭据。
操作步骤
- 第 1 步，先从文件系统排除明显风险。确认 `.env`、`*.pem`、数据库 dump、WordPress backup、`config.local.*`、日志和临时导出不在 git 跟踪范围内。
- 第 2 步，用本地搜索查关键词。不要只搜 `API_KEY`，还要搜 `token`、`secret`、`password`、`Authorization`、`Bearer`、`DATABASE_URL` 和项目实际服务名。
- 第 3 步，检查 git 暂存区。运行 `git diff –cached`，确认即将提交的内容没有真实 key、内部域名、账号邮箱和不可公开路径。
- 第 4 步，开启或确认 GitHub secret scanning。公共仓库会自动覆盖一类场景；组织私有仓库要看是否启用 GitHub Secret Protection。
- 第 5 步，处理 push protection 提示。如果 GitHub 阻止 push，先判断是真密钥、测试假值还是误报。真密钥必须撤销轮换，不能只把那行删掉再继续推。
- 第 6 步，记录修复。把“发现时间、密钥类型、是否已撤销、替代变量名、影响范围、后续复查日期”写入私密安全记录，不写进公开 README。
提交前检查清单
- `git status –short` 只出现预期文件，没有 `.env`、备份、日志、截图和临时数据。
- `rg -n “(api[_-]?key|token|secret|password|authorization|bearer|database_url)” .` 查到的结果都为示例名、文档说明或环境变量名。
- README 只展示变量名，不展示真实值；示例值使用 `YOUR_API_KEY`、`example-token` 这类无效占位。
- GitHub 仓库 Security 页面没有未处理 secret scanning alert。
- 团队知道 push protection 被挡住时不能选择“绕过”来省事，除非有被授权的安全理由和记录。
实际例子：内容站自动发布脚本
一个 WordPress 内容站项目需要保存远端 SSH key 路径、WordPress 用户名、OpenAI key、图片生成配置和缓存清理命令。公开仓库里可以保留脚本结构和变量名，但真实值应放在本机密钥管理器、CI secret 或主机环境变量里。
rg -n "(OPENAI|CLOUDFLARE|WORDPRESS|WP_|TOKEN|SECRET|PASSWORD|DATABASE_URL|Authorization|Bearer)" .
git diff --cached
git ls-files | rg "(\.env|\.pem|backup|dump|log|private)"如果 `rg` 找到 `Authorization: Bearer sk-…` 这类真实值，处理顺序是撤销该 key、重建新 key、替换本地配置、删除提交内容、再提交。不要只清理 git 历史后继续使用旧 key。
常见坑
- 把 `.env.example` 写成真实 `.env` 的复制品。示例文件只能放变量名和无效示例值。
- 认为删除一行就安全。只要真实密钥被提交或推送过，就按已泄漏处理并轮换。
- 把 GitHub partner 自动撤销当成万能保护。GitHub 文档说明 partner secret 可能通知服务商，但你仍要检查自己的告警和凭据状态。
- 把 push protection 的 bypass 当普通按钮。绕过会留下风险，应该有授权理由和审计记录。
排错路径
- push 被阻止：看 GitHub 输出的 secret 类型和位置，确认是真值还是假值；真值先撤销轮换。
- 告警显示历史提交：撤销密钥优先，清理历史是次要动作；历史重写会影响协作者，需要单独计划。
- 误报太多：用项目自己的假值格式，必要时定义更清晰的示例命名，不要用看起来像真实 token 的字符串。
- 仓库多人协作：把这份 SOP 放进 CONTRIBUTING 或内部 runbook，并要求 PR 检查前完成本地命令。
可复制事故记录模板
发现时间：
发现方式：local rg / push protection / secret scanning alert
密钥类型：
出现位置：
是否进入远端：
撤销时间：
新密钥保存位置：
影响服务：
需要通知的人：
复查日期：维护建议：每月抽查一次公开仓库和私有自动化仓库；新增服务、CI、MCP、WordPress 应用密码或图片供应商时，把新的密钥前缀加入本地搜索表。