来自另一侧的调度：激励对齐
Source: Dev.to
引言
这是 Dispatch From the Other Side 系列的第三篇文章。
前文链接
自从第一次听到查理·芒格关于激励的名言后，它一直在我脑中挥之不去：
“告诉我激励，我就能预见结果。”
这句话解释了我一直遇到的一个现象。开发团队并不是因为不在乎而忽视安全问题；他们是在对自己的衡量方式作出理性的反应。
这正是我们在上一篇文章中探讨的杠杆式方法如此有价值的原因。与其要求团队改变工作方式，不如降低合规的成本。当常规做法变得容易时，大多数团队会选择它。
对比的做法
我曾合作的一个漏洞管理团队在一个低风险且暂无修复方案的发现上联系了开发团队，并阻止其进入生产环境。安全团队的绩效衡量是消除已知漏洞，而开发团队的绩效衡量是交付可用软件。未能解决这种紧张关系会比任何一次未修复的漏洞更快侵蚀信任。
逐步提高标准
开发团队用于处理安全问题的时间有限。我发现缓慢提升标准比让“完美成为好事的敌人”更有效。在将新的云配置错误检测纳入正式规则集之前，我会先征求开发团队的反馈。这让他们有时间准备，也在强制执行前赢得了认同。
合作而非监管
有时发现问题的人数远远超过能够修复问题的人数。我会提交 Pull Request 来修复安全配置问题，而不是把负担全部压在开发团队上。经过几次这样的操作后，团队会更早地把我拉进来，讨论如何彻底去除不安全的选项。这类做法把关系转变为合作伙伴，并表明你对他们的成功投入了关注。
安全是质量的一个维度
安全是整体质量的一个维度。团队在管理运营风险的同时也在管理安全风险。如果安全补丁未经充分测试或仓促上线，可能会影响系统可用性。安全债务与功能债务、运营债务、架构债务竞争——它并非孤立存在。我见过许多利益相关方要求开发团队对某个问题采取纠正措施，却没有意识到还有多少其他团队也在提出同样的要求。
对齐激励
当激励对齐时，信任随之而来。这种转变使安全从对立关系转为合作伙伴关系，并提升了那些仅靠工具改进无法解决的问题的影响力。
展望未来
随着生成式 AI 加速软件的构建，这些激励差距可能会进一步扩大。关键在于安全是否能够随之演进——这将是我在最后一篇文章中探讨的内容。