不良的编码模式会导致重大的安全问题... 那么我们为什么要鼓励他们呢？

这篇文章的一个版本出现在 DZone。它已在此处更新和发布。

‍

考虑到软件开发之初的安全最佳实践，我们已经讨论了 SDLC 中的 “向左移动”，这似乎是永恒的。DevSecOps 是一次伟大的飞跃，这在很大程度上是由于强调安全责任的分担，以及具有安全意识的开发人员在编写代码时能够阻止常见漏洞。

我们也知道，长期以来，我们也知道，为吸引和提高开发人员技能而选择的安全代码培训会使一切变得不同。仅以合规为动机的省力解决方案并不能培养未来的聪明安全头脑，大多数安全意识专业人员已经解决了这个问题。动态的、与情境相关的学习是最好的，但了解其中的细微差别至关重要。

如果我们要有机会与威胁行为者作战，而他们 总是 在组织中抢占先机——开发人员需要一个全面的培训环境，通过分层学习不断培养以最佳实践为基础的技能。

开发者驱动的防御性安全措施不是自动获胜的。

我们的理念围绕着开发人员在代码层面上处于预防性安全策略的中心地位。这是理所当然的，具有安全技能的开发人员为阻止在不良编码模式中明显存在的常见安全漏洞提供了最简单的途径（例如 Log4Shell，举一个最近的毁灭性例子）。

但是，我们可以采用的防御技术来提高开发人员的技能确实各不相同，即使它们可以理所当然地存在于同一个培训桶中。

例如，假设你被告知如何烤蛋糕，只根据不该做的事情使用指示。“别把它烤得过头” 和 “别忘了鸡蛋” 让它有待解释，而且错误的可能性很大，最终结果适合 搞定了！。防御性安全教育也是如此；什么 不 做事是对话中非常有限的部分，没有提供任何实际建议，无法真正以防御性心态行事。你可以告诉开发者，“不要错误地配置那个 API”，但如果不了解什么是正确和安全的配置，就有很大的出错余地。

如果不对漏洞的工作原理、它们为何危险、导致漏洞的模式以及哪些设计或编码模式在他们的世界中有意义的环境中修复漏洞有基本的了解，开发人员就不会对漏洞减少产生积极影响。一个 脚手架方法 让知识层层全面了解安全编码、保护代码库以及成为具有安全意识的开发人员意味着什么。是的，分层学习的一部分应该专门用于进攻和了解攻击者的心态；这对于磨练横向思维技能至关重要，而横向思维技能在威胁建模和防御策略中非常宝贵。

强化不良的编码模式是我们不可忽视的陷阱。

一些开发人员学习方法的一个不幸现实是，“防御” 部分——即使训练是使用攻击性技巧进行的，也会强化坏习惯，即使它们是在技术上验证代码安全性。

高质量代码的生产应该是所有软件开发的基准，但是 “质量” 的定义似乎仍有待商榷。现实情况是，不安全的代码不能被视为高质量的代码，即使它在其他方面既实用又美观。关键在于 安全 代码本质上不是高质量的，也是。换句话说，不良的编码模式可以解决安全问题，但这样做会引入另一个问题，或者有可能完全破坏软件。

让我们来看一个质量差的代码示例，其形式是修复身份验证中断的问题，以及最安全的版本以实现最佳实践：

‍

使用系统；

使用系统集合.Generic；

使用 System.Linq；

使用 System.Threading.Tasks；

使用微软 ASPNETCore.astorization；

使用微软.aspnetCore.http;

使用微软 AspnetCore.mvc；

‍

命名空间 badfixesapi.Contro

{

[路由（“api/ [控制器]”）]

[API控制器]

公共类警报控制器：ControllerBase

{

私有数据库上下文 = new databaseContext ();

‍

[HttpGet（名称 = “getAlerts”）]

//不确保用户已通过身份验证

公共 IEnumerable G <Alert>et ()

{

返回 context.getAlerts ();

}

‍

[HttpGet（名称 = “getAlerts”）]

//确保用户已通过身份验证，但不检查任何角色

[授权 ()]

公共 IEnumerable <Alert>getBadFix ()

{

返回 context.getAlerts ();

}

‍

[HttpGet（名称 = “getAlerts”）]

//确保用户已通过身份验证，并且他们具有 “管理员” 角色

[授权（角色 = “管理员”）]

公共 IEnumerable <Alert>getGoodFix ()

{

返回 context.getAlerts ();

}

}

}

‍

在第一个片段中，没有检查用户是否已通过身份验证，这几乎不安全。第二种虽然在执行身份验证检查方面更好，但未能调查分配的角色以及权限是否足够高，无法提供所请求的信息。第三个检查两个用户的身份验证 和 他们被分配了 “管理员” 角色。在大多数情况下，最低权限访问控制应成为常态的时代，设置和检查角色至关重要，以确保只有在必要时才能访问信息。

开发人员的首要任务是构建功能，虽然安全性不是故意置于次要地位，但他们不一定具备避免导致安全漏洞的不良编码模式的技能，而且优秀工程师的基准很少包括安全编码能力。如果这些功能足够棒，我们就会间接鼓励这些坏习惯，而正是这种心态必须改变。问题在于，一些学习途径鼓励动手修复代码的方式也有可能强化安全但质量不合标准的代码。通过应用二进制 “是的，这很安全/不这不安全” 的评估，而不是更深入地研究它是否真的是解决错误和维护软件完整性的最佳方法，细节中有些魔鬼会被忽视。

这种方法无需引导开发人员完成整个过程以获得安全编码的完整视图，它试图解决的相同问题就会永久化。想象一下，如果我们仅凭驾驶车辆到达目的地的能力而获得驾照；尽管我们开了红灯，开车穿过树篱并且差点错过了人行横道才到达目的地，但还是通行证。我们完成了目标，但我们为实现目标所经历的旅程最为重要。

开发人员需要能够更加关心创建安全软件。

现代开发人员必须保持大量精力，他们发现安全培训无聊也就不足为奇了，尤其是在实施安全培训时没有考虑到他们的工作日并使他们偏离最后期限和优先事项的情况下。当他们没有通过定期、合适的学习机会和补充工具所积累的技能时，改变他们的关键绩效指标，将重点放在安全编码上也是完全不公平的。但是，安全软件开发的重要性怎么强调都不为过，让开发人员支持这一点至关重要。

作为前开发者，总的来说，我们 想 出色地完成工作，在质量产出方面被视为比其他人更胜一筹，这非常有激励作用。激励开发人员参与持续的安全技能培养是不费吹灰之力的，他们应该因为认识到代码级安全的重要性而获得奖励。安全冠军计划、漏洞赏金和黑客马拉松可能是建立积极安全文化的绝佳机会，而那些卷起袖子参与的人应该获得战利品。