把 Security 和 Quality 放到一块以后，治理就不该再各自为政了

数字治理

发布日期: 2026-04-06

导语：
截至 2026 年 4 月 6 日，数字治理里一个很值得反复咀嚼的变化，是 GitHub 在 4 月 2 日把顶层 Security 导航正式改成了 Security & quality。从表面看，这只是导航改名；从治理角度看，它其实很像一个清晰的表态：安全问题和代码质量问题不该再被拆成两套彼此独立的流程。
这条变化又正好和另外两组更新撞到一起了。4 月 2 日，Copilot organization custom instructions 正式 GA；4 月 6 日，代码评审指标又能区分 active/passive。三条消息放在一起，组织已经很难再维持原来的分工方式了：安全、质量、AI 使用习惯、组织规则，本质上都在一条链上。

1. 为什么这次导航改名值得认真看

如果只是界面换个标签，当然没必要大书特书。
但 GitHub 这次明确写了：它是在为即将到来的 GitHub Code Quality GA 做铺垫，目的是把 code quality findings 和 security alerts 放到同一个问题治理面里。

这说明平台方的判断已经很清楚：
一个仓库的风险，不该只看漏洞数，也不该只看 lint 通过率，更不该把两者分别交给两个完全割裂的小组处理。

现实里的很多问题本来就跨界。
配置错误会演变成安全问题。
低质量代码会放大安全漏洞修复成本。
AI 生成的差异如果没有质量护栏，也会迅速变成安全负担。

2. 组织为什么总把治理做碎

因为碎着做在短期里看上去更容易管理。
安全团队管安全规则，平台团队管质量规则，开发团队管 AI 使用规范，法务团队管条款和数据边界。每个小块都能写出自己的制度，但落到仓库里时，开发者面对的却是一堆互相不对齐的约束。

这会导致两个后果：

开发者把规则视为多个独立噪音。
组织永远拿不到一张完整的治理图。

现在 Security & quality 这个入口被明确放在一起，其实是在提醒组织：问题已经不再允许你这么拆。

3. 一套更现实的治理收口方式

第一步，改视图。
别再只看安全工单或只看质量报表。真正有价值的是把安全发现、质量发现、代码评审使用数据和 AI 规则命中情况放到一个周报里。

第二步，改规则归属。
像 Copilot organization custom instructions 这种能力，本身就是治理工具。它不该只归某个单独工具管理员管理，而应该和代码规范、安全规则、质量门禁一起制定。

第三步，改度量。
4 月 6 日 active/passive CCR 指标说明了一个很重要的事：组织不能只统计“策略开了没有”，还得统计“人到底有没有参与”。这一点对安全和质量同样适用。

第四步，改协作机制。
安全团队、平台团队、质量团队至少要共享一部分规则库和复盘机制，而不是各做各的季度回顾。

4. 具体该怎么落地

先列出现有安全、质量、AI 规则分别由谁维护。
找出其中重复、冲突、口径不一的部分。
选几个高风险仓库试行统一视图。
把 code review active/passive、代码质量发现、安全发现、AI 自定义指令一起纳入仓库健康度。
对规则命中率低、覆盖率高但参与度低的场景做专项访谈。

5. 最容易被忽略的误区

一个误区是“放到一起看会让责任不清”。
恰恰相反。责任不清往往来自视图分散，而不是来自统一视图。

另一个误区是“安全和质量不是一回事”。
它们当然不是一回事，但在仓库治理层面，它们早就共享同一批人、同一套流程、同一段代码和同一条修复路径了。

6. 建议本周执行的动作

把安全和质量周报合并成一版联合视图。
将 Copilot custom instructions 纳入治理规则清单。
对 active/passive code review 数据做第一次解释型复盘。
为高风险仓库定义统一的治理健康度指标。
停止用分散报表来描述同一批仓库。

7. 结语

治理最容易做成什么样？制度很多，视图很碎，人人有报表，没人有全貌。GitHub 把 Security 改成 Security & quality，本质上是在替大家把这层窗户纸捅破。到了 2026 年 4 月，真正成熟的组织不会再满足于“每个团队各管一段”，而是会开始把安全、质量和 AI 行为放在同一张地图上看。只有先把地图拼起来，治理才不会继续碎下去。