不良的编码模式会导致严重的安全问题……那么，我们为什么要鼓励它们呢？

本文曾发表于 DZone。现已更新并在此同步发布。

‍

在过去漫长的岁月里，我们一直在讨论软件开发生命周期（SDLC）中的“左移”策略，即从软件开发之初就纳入安全最佳实践。DevSecOps 的出现是一次巨大的飞跃，这在很大程度上归功于它强调安全责任共担，以及赋予开发者在编写代码时防范常见漏洞的能力。

我们同样清楚——而且已经清楚了很久——选择何种安全编码培训来吸引并提升开发者技能至关重要。仅出于合规性要求而采取的低投入方案，无法培养出未来顶尖的安全人才，大多数安全意识专业人士对此已有共识。动态且与实际场景相关的学习方式效果最佳，但关键在于必须深入理解其中的细微差别。

如果我们想在对抗威胁行为者时拥有一线生机——毕竟他们 总是 比组织领先一步——开发者就需要一个全面的培训环境，通过分层学习不断积累植根于最佳实践的技能。

由开发者驱动的防御性安全措施并非万能灵药。

我们的核心理念是：开发者是预防性安全战略的中心，从代码层面开始向上延伸。这一点毋庸置疑，具备安全技能的开发者是防范不良编码模式引发的常见安全漏洞（例如最近破坏力极强的 Log4Shell）的最直接途径。

然而，我们用于提升开发者技能的防御技术各不相同，即使它们可能被归入同一类培训中。

举个例子，想象一下如果有人教你烤蛋糕，却只告诉你“不要做什么”。“不要烤过头”、“别忘了放鸡蛋”，这种指导留下了太多的解读空间，极易导致最终成品惨不忍睹，就像 Nailed It! 节目里的翻车现场。防御性安全教育也是如此；告诉开发者 不要 做什么只是对话中非常有限的一部分，无法提供真正建立防御思维的实用建议。你可以告诉开发者“不要错误配置 API”，但如果他们不了解什么是正确且安全的配置，就很容易出错。

如果开发者不从根本上理解漏洞的运作机制、危害性、成因模式，以及在实际开发场景中如何通过设计或编码模式来修复漏洞，他们就无法有效减少漏洞。采用 阶梯式教学方法，通过层层递进的知识构建，能让开发者全面掌握如何编写安全代码、保护代码库，并成长为具备安全意识的开发者。当然，这种分层学习的一部分也应致力于进攻端，理解攻击者的思维方式；这对于磨练横向思维能力至关重要，而这种能力在威胁建模和防御策略中价值连城。

强化不良编码模式是我们必须警惕的陷阱。

一些开发者学习方法存在一个不幸的现实：即使培训中包含了进攻性技术，其“防御”部分有时反而会强化不良习惯，即便它们在技术上验证了代码的安全性。

生产高质量代码应是所有软件开发的基础，但“质量”的定义似乎仍有争议。现实情况是，不安全的代码不能被视为高质量代码，即使它功能完备且外观精美。关键在于，安全 的代码也不一定就是高质量代码。换句话说，不良的编码模式或许能修复一个安全问题，但在此过程中可能会引入另一个问题，甚至导致软件彻底崩溃。

让我们看一个关于修复身份验证漏洞的不良代码示例，以及符合最佳实践的最安全版本：

‍

using System;

using System.Collections.Generic;

using System.Linq;

using System.Threading.Tasks;

using Microsoft.AspNetCore.Authorization;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

‍

namespace BadFixesAPI.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    public class AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext();

‍

        [HttpGet(Name = "GetAlerts")]

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

        public IEnumerable<Alert> Get()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

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

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

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

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            return context.GetAlerts();

        }

    }

}

‍

第一个代码片段没有任何身份验证检查，这极其不安全。第二个片段虽然进行了身份验证，但未能检查用户角色及其权限是否足以访问所请求的信息。第三个片段则同时检查了用户身份验证以及其是否被授予“管理员”角色。在大多数情况下，“最小权限原则”应成为访问控制的常态，因此必须设置并检查角色，确保信息仅在必要时才可被访问。

开发人员的首要任务是构建功能。虽然他们并非故意忽视安全性，但往往缺乏避免不良编码模式的技能，而衡量优秀工程师的标准也鲜少包含安全编码能力。如果功能足够出色，我们实际上是在间接鼓励这些坏习惯，这种思维方式必须改变。问题在于，一些学习路径所倡导的动手代码修复方式，可能会强化那些虽然安全但质量低劣的代码。如果仅采用“安全/不安全”的二元评估，而不深入探讨这是否是解决漏洞并维护软件完整性的最佳方案，那么许多细节中的隐患就会被忽略。

如果不引导开发人员经历完整的安全编码流程，这种方法只会延续它试图解决的问题。试想一下，如果我们考取驾照仅凭能否将车开到目的地：即便闯了红灯、撞坏了篱笆、差点撞到行人，只要到了目的地就算合格。我们完成了目标，但实现目标的过程才是最重要的。

必须让开发人员有动力去关注如何创建安全的软件。

现代开发人员面临多重压力，他们觉得安全培训枯燥乏味也就不足为奇了，尤其是当培训内容与日常工作脱节，且占用他们处理截止日期和优先事项的时间时。在缺乏定期、适宜的学习机会和辅助工具的情况下，强行将安全编码纳入KPI考核也是完全不公平的。然而，安全软件开发的重要性不言而喻，让开发人员认同这一点至关重要。

作为一名前开发人员，我们通常希望把工作做好，而因高质量的产出被视为佼佼者是非常有动力的。激励开发人员参与持续的安全技能提升是理所当然的，他们应当因重视代码级安全而获得奖励。安全倡导者计划、漏洞赏金计划和黑客马拉松都是营造积极安全文化的绝佳机会，那些积极参与的人应当获得相应的回报。