把漏洞和泄密检查前移到提交前，AppSec 终于开始长到开发桌面上

网络安全

发布日期: 2026-05-05

导语：
到 2026 年 5 月 5 日，网络安全领域里最值得工程团队动手试的一批更新，都指向同一件事：应用安全的起点正在前移。GitHub 在这一天宣布，Secret scanning with GitHub MCP Server 正式 GA，同时 Dependency scanning with GitHub MCP Server 进入 public preview。换句话说，扫描密钥泄露和依赖漏洞这两件过去主要发生在提交后、合并后甚至上线后的事情，现在开始被推到“你还没 commit 之前”。

这不是简单的“扫描更早一点”而已。它意味着 AppSec 的交付方式在变。安全团队不再只是把规则挂在代码仓库和 CI 末端，而是开始把能力下沉到开发者正在使用的 AI 编码代理、CLI 和 IDE 里。谁先把这条链条跑顺，谁就更有机会把安全变成开发动作的一部分，而不是开发后的补锅流程。

1. 为什么这次变化比表面上更重要

很多团队过去也说“安全左移”，但做法常常比较粗暴：加更多 pre-commit hook、加更长的 CI、加更多门禁，最后开发者只觉得流程更慢。MCP 这次的变化不一样，它不是单纯在某个固定节点上再塞一个检查器，而是把扫描能力直接交给了正在执行任务的 agent。

秘密扫描这边，GitHub 说得很清楚：MCP-compatible agent 或 IDE 可以在你提交前就检查当前改动里有没有暴露凭据，而且会遵守你现有的 push protection customization。依赖扫描这边则更进一步，agent 可以通过 dependabot toolset 把依赖信息送去 GitHub Advisory Database，返回受影响包、严重级别和建议版本；必要时还可以本地调用 Dependabot CLI，对变更前后依赖图做 diff。

这两件事合起来，意味着安全检查不再只是“阻止你”，而是“在你写代码的时候帮你修正方向”。

2. 为什么安全团队应该特别重视这种交付方式

传统 AppSec 最大的问题之一，不是工具不够多，而是反馈来得太晚。
密钥已经进了仓库，漏洞依赖已经进了主干，CI 跑完才告诉你有问题，大家自然会把安全看成返工来源。

而前移到 MCP / agent 这一层之后，反馈窗口变了：

开发者还在当前任务上下文里。
风险还没扩散到主干和更多环境。
Agent 已经拿到了修改意图，能给出更接近动作的建议。

这会明显降低安全建议被忽略的概率。说白了，同一句“这里有问题”，在 PR 合并前一天和编码当下说出来，效果完全不是一个量级。

3. 一套可以直接落地的改造流程

第一步，先选“高频误伤点”，别一口气全量铺开。
我会先从 secret 和依赖两类风险切入，因为这两类问题最适合结构化检测，也最容易在开发早期给出明确处理建议。

第二步，把 MCP 工具集装进开发主路径。
如果团队主要用 Copilot CLI，就按 GitHub 给的方法启用 dependabot toolset，并安装 advanced-security@copilot-plugins。如果以 VS Code 为主，就把对应插件和 /secret-scanning、/dependency-scanning 工作流配进去。

第三步，设计标准提示词，而不是只给功能。
比如：

Scan my current changes for exposed secrets and show me the files and lines I should update before I commit.
Scan the dependencies I added on this branch for known vulnerabilities and tell me which versions to upgrade to before I commit.

很多团队把工具装上去就结束了，结果没人会稳定使用。你得把触发方式和团队习惯一并设计出来。

第四步，把“预提交发现”与“提交后治理”连起来。
开发前移检查不是要替代仓库级 secret scanning、Dependabot alerts、SBOM 或 code scanning，而是增加一道更便宜的拦截层。仓库级和组织级能力仍然要保留，用来做审计、历史追踪和统一治理。

第五步，建立绕过机制，但别让它失控。
GitHub 提到 secret scanning 工具会尊重你现有的 push protection customization，这非常重要。绕过行为必须保持和仓库/组织策略一致，不然开发桌面上一套、服务端一套，只会制造新的混乱。

4. 如何避免把“左移”做成“更烦”

安全左移失败，通常不是因为大家反对安全，而是因为体验太差。要避免这个问题，我建议记住三条：

第一，扫描结果必须可操作。
不要只说“有风险”，要能告诉开发者是哪个文件、哪一行、推荐改成什么版本、为什么这样判断。

第二，把检查范围限定在“当前改动”。
一次性把整个仓库历史债务甩给正在开发的人，注定会被抵触。MCP 这类能力之所以适合前移，就是因为它天然更适合围绕当前 diff 工作。

第三，保留人为判断空间。
尤其依赖漏洞扫描，不能把所有发现都等同于必须立即阻断。团队还是要有分级处理策略。

5. 把运行时上下文接上，安全价值会更大

同一天 GitHub 还让 Code-to-cloud risk visibility with Microsoft Defender for Cloud 正式 GA。这个消息和 MCP 扫描放在一起看，很有意思：前者解决“你正在改的东西有没有已知问题”，后者解决“这些问题是否真的跑在生产里、是否 internet-exposed、是否处理 sensitive data”。

所以更成熟的安全流程应该是这样的：

开发桌面上先拦 secret 和依赖风险。
提交后在仓库和组织层继续统一扫描。
对高优先级问题，再结合运行时上下文判断是否优先修复。

这样一来，安全不再只是“发现问题”，而是“在对的时间用对的证据处理问题”。

6. 本周建议立刻执行的动作

在一支试点团队里启用 MCP secret scanning 和 dependency scanning。
为 CLI 和 VS Code 各准备一套标准提示词和短文档。
核对现有 push protection customization，确保前移检查与仓库策略一致。
统计一周内在提交前被拦下的 secrets 和依赖问题数量。
把这些结果和提交后告警、运行时风险上下文放到同一张周报里。

7. 结语

5 月 5 日这批更新最有价值的地方，不是“多了两个扫描入口”，而是 AppSec 终于开始真正长到开发者桌面上了。安全如果永远停留在仓库门口和流水线末端，就只能反复制造返工。现在平台已经把 secret 和依赖检查推到了编码当下，团队要做的不是再等等看，而是尽快把这层能力揉进日常开发动作里。真能做到这一点，安全和开发的关系会轻松很多。