代码破茧而出：为何安全开发人员可以无限制发布

本文最初发表于 SD Times。经更新后在此转载。

‍

在现代社会的大部分时间里，技能验证一直是我们生活的一部分，它赋予我们合法性，并为我们开启了原本无法触及的大门。例如，驾驶对大多数人来说是一项重要的成人礼，我们必须通过一系列标准化评估，以证明我们有能力驾驭重达四千磅、时速可超百英里的机器。一旦失误，尤其是在高速行驶时，你可能会失去这项特权，甚至付出生命的代价。

但如果对某些人来说，驾驶不仅仅是日常的便利，而是一项精英职业呢？一个人可以继续提升技能，并有可能成为一名 F1 车手，他们被允许操作那些普通人在高速下极易出错、难以驾驭的赛车。

因此，令人费解的是，大多数开发人员在编写支撑关键基础设施、汽车、医疗技术及其他各类系统的代码时，竟然无需先验证其安全能力。另一方面，那些已多次证明自己具备安全构建能力的开发人员，为何还要因为各种安全门禁，而被迫与其他人一起排队等待日益缓慢的开发流程？业界并不认为这是一种疏忽，反而将其视为常态。

大量研究表明，大多数开发人员在编写代码时根本不优先考虑安全性，且缺乏应对常见安全漏洞所需的常规教育。他们往往是导致“高速安全”成为空谈的原因之一，许多具备安全意识的开发人员感觉自己就像被困在高速公路慢车道上，前面还跟着一群新手司机。

尽管如此，安全领域正在缓慢前行，市场对能够快速上手且具备验证安全技能的开发人员的需求日益增长。拜登政府的《改善国家网络安全行政令》明确要求对美国政府软件供应链中任何供应商的开发团队进行安全实践评估。可以预见，各行业对开发人员安全技能的重视程度只会不断提高。然而，在缺乏行业标准评估的情况下，企业如何才能在不拖累交付进度、不阻碍安全意识强的开发人员发挥才能的前提下，证明其安全计划确实提升了开发人员的可验证安全技能？

基于能力的访问控制：这行得通吗？

最小权限安全控制是许多组织的核心原则，其理念是根据工作需要，为每个角色分配软件、数据和系统的访问权限，仅此而已。这种方法——尤其是与零信任授权原则相结合时——有助于缩小攻击面。实际上，我们应该将这一策略同样应用于 API 权限及其他基于软件的用例，并将其作为标准。

我们大多数安全从业者都深知软件正在吞噬世界，从空气炸锅的嵌入式系统代码到维持电网运行的代码，在潜在的可利用性方面并无本质区别。我们的生活和关键数据正处于威胁行为者的掌控之中，每一位开发人员都必须意识到，通过适当的教育，他们有能力加固自己的代码。这需要组织安全文化进行重大升级，但为了实现真正的 DevSecOps 式共同责任，开发人员确实需要一个关注自身角色的理由。或许，改变他们思维方式最快的方法，就是将代码仓库访问权限与安全编码的学习成果挂钩。

以银行、金融服务和保险（BFSI）领域的组织为例，很可能存在包含客户数据或存储信用卡号等宝贵信息的高度敏感仓库。那么，我们为什么要假设每一位获得访问权限的工程师都具备安全意识、符合严格的 PCI-DSS 要求，并且能够快速且无事故地对主分支进行更改？虽然对某些人来说确实如此，但在证明其具备相关知识之前，限制对这些敏感系统的访问会安全得多。

挑战在于，在大多数公司中，实施“编码许可”方案将非常艰巨，而且根据培训解决方案的不同，这种方式可能过于手动，难以支持任何形式的“高速安全”目标。然而，将整合式教育与工具相结合，可以成为以开发人员为驱动的防御性安全战略的核心。

有效的培训整合并非不可能。

寻找既能兼顾高速度业务目标又能融入工作流的开发人员技能提升方案，只是成功了一半。但只有更进一步，超越“一劳永逸”式的合规培训，我们才能真正看到代码级漏洞的显著减少。至于那些成功证明了自己的开发人员？编码世界任其驰骋，他们不必再被那些假设他们无法掌握基础知识的安全控制所束缚。

与开发环境无缝集成的实践技能提升，为工程师真正理解和应用安全编码概念提供了必要的背景。同样的集成也可用于有效管理对关键系统的访问，确保那些学习成果优异的人能够毫无阻碍地处理最高优先级的敏感任务。这也使得实施奖励和认可变得更加容易，确保具备安全技能的开发人员在团队中被视为榜样。

正如生活中的许多事情一样，机遇偏爱勇敢者。打破现状，采用开箱即用的开发人员技能验证方法，正是我们提升未来代码质量标准且不牺牲速度所需要的。