安全负责人机制：小团队怎么把插件安全文化做起来

多数团队把装什么插件当成个人选择，这正是插件安全文化始终建不起来的原因。安全负责人机制的解决办法很直接：给每个团队指定一个人认领这件事，而不是写一份没人会打开第二遍的规范。下面说的是没有安全团队的小团队里，安全负责人职责具体是什么、不增加人手怎么把机制启动起来，以及负责人该在哪里止步。

为什么一份规范不等于一种文化

试过这件事的团队几乎都是先写文档。文档很少带来改变，原因有三条，而且都跟写得怎么样无关。

• 会开完之后，文档就没有主人了。没有人被指定去注意上周二是不是多了一个插件，于是也就没人注意。
• 审查发生在安装之后，不是之前。等人来看的时候，插件的安装脚本已经跑完了，讨论变成了要不要删掉一个大家已经在用的东西。
• 分数存在，但没人被指定去看。躺在索引里的等级只是信息；每周一有人去查的等级才是一道控制。

负责人补上的正是这个缺口：他是一个人名，而不是一条规则。多数团队里规则已经有了，缺的是那个人。

安全负责人职责，具体一点

五件事，没有一件需要安全背景。

• 认领插件清单。仓库里一个文件，记录装了什么、是谁提出装的。
• 做新插件的第一位审查人。不是强制审批人，而是同事在安装之前会先问一句的人。
• 每周跑一遍分数。花十分钟对一遍索引，重点看等级发生变化的条目，而不是只看分数本来就低的那些。
• 让白名单保持真实。一个季度没人用过的条目就删掉，因为白名单过期正是被否掉的插件悄悄回来的方式。
• 有东西被撤下时写一条说明。一段话讲清删了什么、为什么，免得下一个人又装回来。

负责人每周做什么

一周四十分钟。让这件事长过一小时的团队，通常在第二个季度就把负责人弄丢了，因为这个角色会悄悄变成第二份工作。

不增加人手，怎么启动这套机制

你不需要招人，只需要给已经在审 pull request 的那个人一个名字。

• 每个团队一个，不是全公司一个。中央负责人不可能知道某个团队到底依赖哪个插件。
• 给他分数，不要给他规章。一个可以直接查的数字，比一份需要他先解读的文档更快落地。
• 把时间封顶。公开说清这就是每周四十分钟，而且说到做到。
• 每两个季度轮换一次。轮换能把知识摊开，也能避免这个角色固化成一个瓶颈。

负责人该在哪里止步

三条边界很重要，越过它们会把一个有用的角色变成背锅的角色。

• 高风险安装不由他一个人批。凡是碰到凭据或网络访问的，要有两个名字。
• 他不写规范。他汇报看到的情况，规则由别人来定。
• 他不是事故负责人。如果某个插件最后被证实是恶意的，那是一起有自己的流程的事故，不是负责人的失职。

负责人是那个注意到的人。一旦他变成独自决定一切的人，这套机制就坏了。

让第一位负责人撑过第一个月

第一个月决定这个角色能不能活下来。三件事能让它扎住。

• 从清单开始，不要从规则开始。把已经装了什么写下来，一个下午就能做完，而且产出是具体的东西。
• 把负责人和评分绑在一起。读等级是最有进展感的部分，也恰恰是能最早发现问题的部分。
• 公开汇报一次。一个月一条简短的消息说明变了什么，足以让角色被看见，又不至于变成一场考核。

完整索引在 dshquality.com，每个分数背后的四根支柱写在 /blog/dsh-quality-score-decoded。这一篇可以搭配白名单指南 /blog/setting-up-a-plugin-allowlist-for-your-dev-team、流水线接入 /blog/ci-cd-plugin-scanning，以及供应链那篇 /blog/plugin-supply-chain-security-team-enforcement。所有文章都在 /blog。

常见问题

• 需要几个负责人？五到十名工程师的团队配一个。人更少时组长就能兼任，人更多时清单会长到一个人认不全。
• 负责人需要安全培训吗？不需要。这个角色要做的是留意和记录，不是分析。真需要分析的事情应该上报，而不是在本地拍板。
• 负责人离职了怎么办？每两个季度轮换，并把清单放在仓库里而不是文档里。轮换正是让离职不至于变成一次中断的原因。
• 这和白名单有什么区别？白名单是一道挡住安装的控制措施；负责人是让这道措施保持最新的人，而这恰恰是白名单最容易坏掉的地方。