买方要求启用 GitHub Secret Scanning，究竟需要哪种服务？
买方只说"需要 GitHub Secret Scanning"时，先分流到功能启用、历史告警分诊、推送保护部署或自定义模式与响应设计，再承诺范围。
买方只发来一句“我们需要 GitHub Secret Scanning”，你无法直接判断他要哪种服务：可能是功能启用、历史告警分诊与凭据轮换、推送保护部署，也可能是自定义模式与响应设计。四条路线的负责人、交付物和报价各不相同，所以正确的做法是先把请求分流，再承诺范围。密钥扫描（secret scanning）是 GitHub 检测代码仓库内容中暴露凭据的功能；凭据（credential）指能访问系统或服务的机密信息，例如访问令牌、私钥或数据库密码。对销售负责人来说，这两个定义直接决定报价起点：你报的每一项都要落到仓库、告警和人员上，起点判断错了，报价单上的每一行都会跟着偏。
通话里的每一句承诺，之后都会变成合同条款。而“我们需要 secret scanning”这句话本身，把代码仓库、历史范围、现有告警、凭据负责人、推送保护范围、绕过规则、自定义模式、验收方式和响应负责人全部留成了空白。销售负责人要做的，就是把这些空白变成可以逐条回答的问题。
一句话请求，四条服务路线
先统一三个术语。推送保护（push protection）在检测到的机密进入仓库之前就将其拦截，而不是事后才报告。绕过（bypass）是推送被拦截时的一次有意放行；GitHub 文档写明，仓库级绕过会生成告警和审计日志事件，所以绕过是可观测的，不是隐形的。自定义模式（custom pattern）是你定义的组织特有格式，用于覆盖 GitHub 内置模式识别不到的凭据类型。REST 应用程序编程接口（API）是 GitHub 列出的推送保护覆盖面之一，与命令行推送、GitHub 网页提交、文件上传并列。
- 路线一，功能启用：在指定仓库上打开扫描，设置默认值，确认告警出现。
- 路线二，历史告警分诊与凭据轮换：处理现有告警清单，找到每条凭据的负责人，定义轮换路径。
- 路线三，推送保护部署与绕过治理：启用拦截，指定绕过审批人——GitHub 的默认与委派绕过设置仍然需要一个具名策略负责人。
- 路线四，自定义模式与响应设计：编写模式，约定验收测试，指定新告警的响应人。
复合请求：一条什么都没说清的询盘
下面的买方请求是复合示例，由真实询盘中反复出现的说法拼成，不是任何一位客户的原文：
“We need GitHub secret scanning org-wide. Repos with years of history, some alerts already showing, and we want to stop developers pushing keys. We also have an internal token format to flag. Can you quote a scope?”
下面这条 Telegram 消息同样是示意文本，不是客户原文：
“Need secret scanning set up. Legacy repos, alerts already appearing, want push protection on, one custom format to flag. What would that cost?”
两条消息都没有回答下方矩阵的任何一行。经由聊天渠道到达的请求比正式询价文档短得多，留白是常态而非例外——这正是网络安全需求如何在专业社群中形成所说的：渠道越短，分流责任越在卖方这一侧。
决策矩阵：每条路线报价前需要什么
八项标准、四条路线。每一行读作“这条路线的报价前提”。
| 标准 | 功能启用 | 历史分诊 | 推送保护 | 自定义模式 |
|---|---|---|---|---|
| 仓库与历史范围 | 指定仓库、当前分支 | 完整历史、过往推送 | 指定仓库、当前推送 | 模式会命中的仓库 |
| 当前告警 | 不需要 | 完整清单、严重级别 | 不是重点 | 真实与误报样本 |
| 凭据负责人 | 不需要 | 必须，附轮换路径 | 不需要 | 响应设计需要 |
| 推送保护范围 | 不需要 | 不需要 | 指定仓库与覆盖面 | 不需要 |
| 绕过规则 | 不需要 | 不需要 | 指定审批人与升级路径 | 不需要 |
| 自定义模式 | 不需要 | 不需要 | 不需要 | 规格加误报控制目标 |
| 验收方式 | 告警出现 | 清零或双方认可 | 测试机密被拦截 | 样本命中、干净样本不报 |
| 响应负责人 | 不需要 | 每条告警指定 | 绕过审批人 | 指定的响应人 |
四列不需要全部填满：如果买方只要功能启用，其余三列的“不需要”就是你的范围边界。没有回答任何一行的请求，报价就是空头支票。反过来，如果买方同时提到告警、推送拦截和内部令牌格式，就像上面的复合请求那样，你要报的是两到三条路线的组合，而不是一个笼统的“扫描启用”。矩阵不是问卷的全部，但八行齐了，范围就清晰了。
关键事实与证据边界
GitHub Docs 的 Secret scanning 页面（2026 年 8 月 3 日访问）将密钥扫描描述为检测仓库内容中的暴露凭据，并把告警、自定义模式、有效性检查和合作伙伴模式处理分开说明——这正是“启用密钥扫描”不是一个单一交付物的原因。GitHub Docs 的 Push protection for secret scanning 页面（2026 年 8 月 3 日访问）列出受保护的覆盖面：命令行推送、GitHub 网页提交、文件上传、REST API 请求，以及列出的公开仓库交互；文档同时写明，仓库级推送保护在有人绕过拦截时会产生告警和审计日志事件，默认与委派绕过设置仍需具名策略负责人。Telegram 隐私政策（2026 年 8 月 3 日访问）将机器人描述为独立的第三方服务，可带或不带消息访问权限运行，并提示第三方机器人开发者应先征得许可再访问数据。
这三个日期是当前文档的访问日期，不是关于买方的信号。它们的作用是锚定工具今天的行为；范围由买方自己的仓库决定。文档不提供任何证据说明这位买方要哪种服务——那正是你要在电话里问出来的。如果买方在邮件里附上了仓库清单或现有告警导出，那些才是分流的输入；文档日期不是。
为什么分流重要：一个示例
假设买方回答：“大约 30 个仓库，生产配置，历史从最开始就有。现在显示的告警是主要问题；推送保护暂时不做。“那么分流为：功能启用加历史告警分诊与凭据轮换。推送保护、自定义模式、绕过规则和响应负责人，在买方指名之前全部留在范围外。
仍然未知的是：每条暴露凭据归谁所有、其中是否还有效、未来绕过由谁审批。这些必须由买方或他们的安全负责人确认，你只记录为待决问题。同样的分流模式也出现在 SLSA 供应链来源证明（SLSA provenance）接入请求里——只报一个标准名，不报构建系统与产物范围，风险相同，解法相同：先分流，再报价。
为什么这对你重要：报价单上的每一行都会变成合同与交付承诺。把四条路线混进一个报价，要么承诺了做不了的部分，要么漏掉了要做的事；而把范围问清楚，报价可以分开列、分阶段交付，每一部分都有明确的验收方式。分阶段的报价也让买方先看到告警分诊的产出，再决定是否追加推送保护。
FAQ
怎么判断买方需要的是推送保护，还是只要启用密钥扫描？ 问开发人员推送密钥时应该发生什么：如果推送必须被拦下，属于推送保护范围；如果事后留一条记录就够，功能启用加告警分诊就能覆盖。
推送保护的绕过审批应该由谁负责？ GitHub 的默认与委派绕过设置需要一个具名策略负责人。按仓库组各指定一名审批人，并在报价前确认买方确实有这个人。
需求会议之前，怎么估算自定义模式请求的规模？ 请对方提供一条真实示例字符串和一条不匹配的正常字符串。这两条就够设计模式和验收测试了。
下一步
把八项标准整理成一张清单发给买方：仓库、历史深度、当前告警、凭据负责人、推送保护范围、绕过规则、自定义模式、验收方式、响应负责人。九个答案，一个范围。等这九项都回了，再决定报价从哪条路线开始。
如果请求经由 Telegram 群而不是邮件到达，TOP Prospect 可以帮你监控那个渠道：它只处理你主动连接且有权访问的 Telegram 群，保留来源证据，产出的是供复核的候选项而不是事实认证，最终决定由人作出，也不会自动联系群成员——需求判断与服务范围始终分开。详见 telegram business signal intelligence。
常见问题
怎么判断买方需要的是推送保护，还是只要启用密钥扫描？
问开发人员推送密钥时应该发生什么：如果推送必须被拦下，属于推送保护范围；如果事后留一条记录就够，功能启用加告警分诊就能覆盖。
推送保护的绕过审批应该由谁负责？
GitHub 的默认与委派绕过设置需要一个具名策略负责人。按仓库组各指定一名审批人，并在报价前确认买方确实有这个人。
需求会议之前，怎么估算自定义模式请求的规模？
请对方提供一条真实示例字符串和一条不匹配的正常字符串。这两条就够设计模式和验收测试了。
