Security Incentivization: An Empirical Study of how Micropayments Impact Code Security
这项实证研究表明，将团队层面的激励与自动化安全指标挂钩，可显著降低代码安全问题的密度，尤其是在后端组件中，且不会人为夸大代码量，从而验证了类微支付式奖励在提升软件安全性方面的有效性。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象你正在运营一门烹饪课，学生必须制作一顿复杂的多道菜大餐。通常，老师只根据食物的美味程度和摆盘的整洁度来评分。安全就像是厨房里的“食品安全”部分：它不会让食物更美味，如果你做得对，没人会注意到；食物只是不会让人生病。因为没人看到好处，学生常常为了节省时间而跳过安全步骤。
这篇论文提出了一个简单的问题：如果我们给学生提供一项特殊奖励，以鼓励他们保持厨房安全，会发生什么？
实验：两个厨房的故事
研究人员开设了一门为期一学期的烹饪课，共有 84 名学生，分为 14 个团队。他们将课程分为两组：
- “仅口味”组（对照组）： 这些学生被告知：“如果你减少厨房里杂乱、无组织的食材（通用代码质量）数量，就能获得奖励。”
- “安全优先”组（实验组）： 这些学生被告知：“如果你减少厨房里的安全隐患（安全问题）数量，就能获得奖励。”
为了衡量这一点，研究人员使用了一支自动化的“厨房检查员”团队（名为 Bearer、Detekt 和 mobsfscan 的软件工具）。这些检查员每隔几周就会扫描学生的代码（即食谱），统计存在多少安全隐患。
机制：“安全评分”
研究人员并非仅仅统计隐患的数量，而是关注改进。
- 想象一名学生一开始有 100 个安全隐患。
- 如果他们修复了其中的 50 个，他们的“安全评分”就会上升，并获得奖励。
- 关键在于，他们不仅统计隐患的总数，还统计每行食谱中的隐患数量。这确保了团队不能仅仅通过编写数百万行杂乱的代码来掩盖问题。他们必须真正让代码变得更干净。
结果：后端与前端
研究发现了一些有趣的结果，可以通过“前厅”与“后厨”的类比来理解：
- 前厅（应用程序/界面）： 这是顾客看到的餐厅部分——菜单、服务员、装饰。在实验中，这是用 Kotlin 编写的移动应用程序。
- 后厨（服务器）： 这是厨房、储藏室和管道系统。在实验中，这是用 Java 编写的服务器。
发生了什么？
- 安全组胜出： 获得安全奖励的学生所编写的代码，其安全隐患数量明显少于获得通用整洁度奖励的小组。
- 厨房更干净了： 安全组的“后厨”（服务器）变得几乎一尘不染。到学期结束时，他们的服务器几乎没有安全隐患。
- 餐厅仍然有些凌乱： 有趣的是，安全组的“前厅”（应用程序）仍然存在不少隐患，尽管比对照组少。看来学生们将额外的精力集中在服务器（厨房）上，因为那是安全“重体力活”发生的地方，或者是因为厨房感觉对项目的生存更为关键。
- 没有作弊： 学生们并没有仅仅通过编写更多代码来稀释问题。两组编写的代码数量以相同的速度增长。安全组只是让他们的代码更好，而不仅仅是更大。
结论
该论文得出结论，如果你为开发人员提供明确、可衡量的奖励以修复安全漏洞，他们确实会去修复。这就像告诉一位厨师：“如果你让厨房达到零卫生违规，你就能获得奖励。”厨师会突然开始擦洗地板并检查冰箱温度。
然而，研究人员也指出，这是一群学生，而不是真实餐厅里的专业厨师。虽然这种方法在课堂上奏效，但他们建议我们需要观察该方法在现实世界中是否适用于有偿专业人士和更长期的项目。
简而言之： 金钱（或成绩）会说话。如果你让人们为安全而获得报酬，他们就会变得更安全，尤其是在软件的“厨房”部分，即使“餐厅”部分仍需要更多的工作。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。