开箱即用的代码：为什么安全开发人员可以不受限制地交付

这篇文章最初出现在 SD 时报。它已在此处更新和发布。

‍

在现代的大部分时间里，技能验证一直是我们生活的一个方面，它赋予了我们有效性，也为我们打开了原本无法获得的大门。例如，对于大多数人来说，开车是重要的通行仪式，我们预计将通过一系列标准化评估，以确认我们拥有一台重达四千磅的机器，能够以每小时超过一百英里的速度行驶。错误，尤其是速度方面的错误，可能会使你失去这种特权，甚至是人的生命。

但是，如果对某些人来说，驾驶不仅仅是一种日常便利，而成为一种精英职业，该怎么办？一个人可以继续他们的技能提升之旅，并有可能成为一名 F1 车手，在那里他们可以操作比任何平民实际操作速度更快的机器，而在高速行驶时出错的可能性很大。

为此，似乎令人困惑的是，大多数开发为关键基础设施、汽车、医疗技术以及介于两者之间的所有东西提供支持的代码的开发人员在没有事先验证其安全能力的情况下就这样做了。另一方面，由于存在种种安全门户，为什么具有安全技能的开发人员需要在不断放缓的开发流程中与其他所有人一起排队，他们一再证明自己知道如何安全地构建东西？业界并不认为这是一种疏忽，这是常态。

我们从广泛的研究中得知 大多数开发人员根本不优先考虑代码中的安全性，并且缺乏应对许多常见安全漏洞所需的常规教育。它们往往是高速安全似乎是白日梦的部分原因，许多具有安全功能的开发人员觉得他们被困在高速公路上的慢车道上，身后是一群学习型司机。

尽管如此，安全世界正在缓慢向前发展，对开发人员拥有经过验证且能够立即投入使用的安全技能的需求越来越大。拜登政府的 关于改善国家网络安全的行政命令 特别要求对美国政府软件供应链中任何供应商的供应商及其开发群体的安全做法进行评估。合乎逻辑的是，对开发人员安全技能的重视只会在大多数领域增加，但是由于行业标准评估几乎没有提供任何帮助，组织如何才能证明其安全计划正在提高可验证的开发人员安全技能，而不会使交付屈服，也不会阻止具有安全意识的开发人员张开翅膀呢？

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

最低权限安全控制是许多组织的支柱，其想法是每个角色在工作环境中根据需要知道的基础上分配对软件、数据和系统的访问权限，仅此而已。这种方法，尤其是与零信任授权原则相结合时，有助于全面控制攻击面。而且，实际上，我们应该申请 同样的 API 权限策略，以及其他基于软件的标准用例。

我们大多数从事安全行业的人都高度意识到软件正在吞噬世界这一事实，而运行空气炸锅的嵌入式系统代码实际上与维持电网正常运行的代码就其可被利用的可能性而言，并没有什么不同。我们的生活和关键数据受威胁者的摆布，每个开发人员都必须了解在接受适当教育后他们所拥有的强化代码的能力。这需要认真升级组织的安全文化，但要真正实现DevSeCops式的共同责任，开发人员确实需要有理由更加关心他们所扮演的角色，而改变思维方式的最快方法可能是将代码存储库访问权限与安全的编码学习成果联系起来。

例如，如果我们以BFSI领域的某个组织为例，很可能会有高度敏感的存储库包含客户数据或存储信用卡号等宝贵信息。那么，我们为什么要假设每位获得访问权限的工程师都具有安全意识，符合严格的 PCI-DSS 要求，并且能够快速且无事故地对主分支进行更改？尽管对某些人来说可能如此，但在这些知识得到证实之前，限制访问这些精密系统要安全得多。

挑战在于，在大多数公司中，制定 “代码许可” 方案将是艰巨的，而且视培训解决方案而定，手工过于手动，无法支持任何类型的速度目标。但是，综合教育和工具的正确组合可以成为开发人员驱动的防御性安全战略的核心。

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

寻找既能补充高速业务目标又能补充其工作流程的开发人员技能提升解决方案是成功的一半，但加倍努力超越 “一劳永逸” 式的合规培训是我们开始看到代码级漏洞显著减少的唯一途径。对于成功证明自己的开发者来说？好吧，编程世界是他们的牡蛎，他们不必受到假设无法掌握基础知识的安全控制措施的阻碍。

与开发环境无缝集成的动手技能提升为工程师真正理解和应用安全编码概念提供了所需的背景信息，这些相同的集成可用于有效管理对关键系统的访问，确保那些在学习成果方面表现出色的人不受阻碍地完成优先级最高的敏感任务。它还使实施奖励和表彰变得更加容易，从而确保具备安全技能的开发人员在他们的队伍中被视为有抱负的人。

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