代码出笼：为什么安全开发人员可以无限制地开发

本文原载于 SD Times.本文已更新并在此联合发表。

‍

在现代社会的大部分时间里，技能验证一直是我们生活的一个方面，它赋予我们有效性，为我们打开一扇扇原本无法打开的大门。例如，对于大多数人来说，驾驶是一项重要的成人仪式，我们需要通过一系列标准化的评估，以确认我们可以驾驶一台重达四千磅、时速超过一百英里的机器。失误，尤其是高速行驶时的失误，可能会让你失去这项特权，甚至是人命。

但是，如果对某些人来说，驾驶不仅仅是日常的便利，而是一种精英职业呢？一个人可以继续他们的技能提升之旅，并有可能成为一名 F1 赛车手，在那里他们可以操作比任何普通人都要快的机器，而不会在高速行驶中出现巨大的失误。 

为此，令人费解的是，大多数开发人员在开发关键基础设施、汽车、医疗技术等所有领域的代码时，都没有首先验证自己的安全能力。另一方面，有安全技能的开发人员已经多次证明他们了解如何安全地构建事物，为什么还要因为所有的安全门而在不断放缓的开发流程中与其他人一起排队呢？业界认为这不是疏忽，而是常态。 

我们通过广泛的研究发现，大多数开发人员根本没有将代码中的安全性放在首位，而且缺乏必要的常规教育，无法解决许多常见的安全漏洞。他们往往是导致安全速度看起来像痴人说梦的部分原因，许多支持安全的开发人员感觉自己被困在高速公路的慢车道上，跟在一群学车者的后面。 

尽管如此，安全领域仍在缓慢前进，对开发人员拥有经过验证的安全技能并能立即投入工作的需求也在不断增加。拜登政府关于改善国家网络安全的行政命令特别要求对美国政府软件供应链中的任何供应商及其开发团队的安全实践进行评估。按理说，大多数部门对开发人员安全技能的重视程度只会与日俱增，但在几乎没有行业标准评估的情况下，企业如何证明自己的安全计划正在提高可验证的开发人员安全技能，而又不会使交付陷入困境，或阻止具有安全意识的开发人员展翅高飞？

基于成绩的访问控制：它能行得通吗？

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

我们大多数从事安全业务的人都清楚地意识到，软件正在吞噬整个世界，而运行空气炸锅的嵌入式系统代码就其可被利用的可能性而言，与维持电网正常运行的代码并无二致。我们的生命和关键数据都受到威胁行为者的摆布，每个开发人员都必须明白，如果受过适当的教育，他们有能力强化自己的代码。这需要对组织的安全文化进行认真的升级，但要真正实现 DevSecOps 式的责任共担，开发人员确实需要一个理由来更加关心他们所扮演的角色，而转变他们心态的最快方法也许就是将代码库访问与安全编码学习成果挂钩。

以 BFSI 领域的企业为例，很有可能存在包含客户数据或存储信用卡号等有价值信息的高度敏感存储库。那么，我们为什么要假定每个获准访问的工程师都具有安全意识，符合严格的 PCI-DSS 要求，并且能够快速、顺利地对主分支进行更改呢？虽然有些人可能确实如此，但在这些知识得到证实之前，限制对这些精密系统的访问要安全得多。

面临的挑战是，在大多数公司中，制定 "代码授权 "方案将是一项艰巨的任务，而且根据培训解决方案的不同，有些过于人工化，无法支持任何类型的安全速度目标。不过，综合教育和工具的正确组合可以成为开发人员驱动的防御性安全策略的核心。 

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

找到与高速业务目标和工作流程相辅相成的开发人员技能提升解决方案是成功的一半，但要想切实减少代码级漏洞，就必须克服 "一劳永逸 "式的合规性培训。对于成功证明自己的开发人员来说呢？编码世界是他们的天下，他们不必受到安全控制的束缚，因为安全控制认为他们无法掌握基础知识。 

与开发环境无缝集成的实践技能提升为工程师提供了真正理解和应用安全编码概念所需的环境，这些集成可用于有效管理对关键系统的访问，确保那些在学习成果方面表现出色的人能够不受阻碍地执行最高优先级的敏感任务。它还能更容易地实施奖励和表彰，确保安全技能开发人员被视为同组人员中的佼佼者。 

就像生活中的许多事情一样，幸运总是眷顾勇敢的人，而打破现状，采用开箱即用的方法来验证开发人员的技能，正是我们在不牺牲速度的前提下提升未来可接受代码质量标准所需要的。