开发人员如何定义“安全编码”？

本文曾发表于 TechRepublic，现经更新后在此转载。

‍

要营造一种让安全团队与开发团队目标一致的环境，是一场艰难但必不可少的战役。我们仍任重道远，但阻碍双方协同合作、共同承担软件安全责任的障碍已日益清晰。明智的企业正致力于优化战略以规避这些陷阱，寻找高效的前进路径，并充分发挥 DevSecOps 以人为本的潜力。

我没料到的是，关于什么是安全编码，目前尚无定论。近期与 Evans Data 合作开展的一项全新研究明确揭示了这一观点。《2022 年开发者驱动的安全状况调查》深入探讨了 1200 名活跃开发者的核心见解与实践经验，阐明了他们在安全领域所持的态度及面临的挑战。

其中一个主要发现是，仅有 14% 的开发者在编码时将安全视为优先事项。虽然这表明仍有巨大的改进空间，但也证实了我们已知的事实：在开发者的世界里，功能构建至高无上，他们仍未做好将安全融入基因的准备。然而，结合开发者对安全编码定义的调查数据来看，这确实令人担忧。

这些认知源于开发者的日常工作经验，也反映了许多组织的现状：在应对常见漏洞的斗争中，开发者并未被置于核心地位。赋能开发者至关重要，但在此期间，我们必须尽快就“安全编码”的范畴以及对具备安全技能的开发者应有何种期待达成共识。

我们需要揭开开发者世界中安全工作的神秘面纱。

网络安全在任何时候都是一个多面且棘手的难题。虽然安全编码只是整体格局中的一部分，但它却是系统中一个需要专业关注的复杂环节。

调查显示，对于普通开发者而言，安全代码的概念相当孤立，他们的认知范围往往局限于单一类别，而非对基础知识及更深层面的整体把握。开发者倾向于依赖使用现有的（或预先批准的）代码，而不是编写无漏洞的新代码。虽然对第三方组件的安全意识（尤其是补丁管理，Log4Shell 事件就是一个很好的例子：自去年 12 月以来，仍有 30% 的实例未打补丁）以及对现有代码的测试非常重要，但仅凭这些并不能达到功能性安全编码的能力水平。

代码层面的漏洞是由掌握了不良编码模式的开发者引入的，而 KPI 中对编写安全代码缺乏重视（加上平庸的安全文化），只会进一步强化这种现状，使其成为一种可接受的标准。

安全领导者可以通过确保开发团队了解安全编码的全貌，从而在提升初步意识和识别最紧迫的知识缺口方面发挥重要作用。测试和扫描预先批准的代码只是一项职能，但要减少漏洞，还需要针对当前使用的语言和框架，进行良好的、安全的编码模式实践培训。

背景信息对于开发者技能提升至关重要，在业务安全目标方面，必须让他们参与其中。

许多组织需要升级其安全计划。

随着软件驱动技术的爆发式增长，过去十年网络安全事件频发，我们都在疲于应对那些全天候寻找高价值系统漏洞的威胁行为者。

DevSecOps 方法论建立在人人共担安全责任（包括开发者）的理念之上，这是软件开发生命周期（SDLC）从始至终的首要考量。问题在于，特别是在大型企业中，他们距离将 DevSecOps 作为标准来实施可能还非常遥远。2017 年，项目管理协会的一项研究显示，51% 的组织仍在使用瀑布式开发模型。该研究距今已有五年，但考虑到大型企业变革的缓慢程度，不太可能已经迅速转型为最新的安全导向方法论。这些遗留流程为试图通过全面战略来防御网络威胁的安全专业人员制造了重重困难，而将开发者及其需求融入这一格局更是一项挑战。

然而，我们不能以此为借口。企业中的安全专家可以利用开发者来提升战略水平；他们只需要熟悉开发者的需求，并将其视为防御体系的一部分。开发者需要全面的培训，任何安全责任的落实都必须尊重他们的技术栈和工作流程。

安全编码 = “太难了”而被束之高阁？

Evans Data 的研究显示，高达 86% 的开发人员认为实践安全编码极具挑战，92% 的开发经理也承认其团队需要更多关于安全框架的培训。令人担忧的是，48% 的受访者承认他们明知代码中存在漏洞却仍选择发布。

这描绘了一幅令人不安的图景。总体而言，开发人员似乎既没有获得频繁且充分的培训，也没有接触到足够的良好安全实践和规范。透过现象看本质，这凸显了问题的核心：开发人员在工作中并未将安全视为优先事项。此外，他们所接受的培训既无法建立信心或提升实践技能，也无法帮助他们理解发布漏洞代码所带来的影响。

Colonial Pipeline 勒索软件攻击是过去一年中破坏性最大的供应链安全事件之一，引发了人们对美国东海岸一半天然气供应可能无限期中断的恐慌。幸运的是，他们很快恢复了运营，但这在业界引起了极大的忧虑。这是公众首次直面网络事件对物理世界造成严重影响的时刻，而这些领域通常被认为与软件驱动无关，也不易受到网络攻击。所有这些混乱竟源于两个陈旧且未修补的漏洞，其中之一就是众所周知且隐蔽的 SQL 注入。如果开发人员真正意识到发布漏洞代码的后果，他们就会明白，在任何情况下这都是不可接受的商业风险。

功能性的“人员-流程-工具”（P-P-T）并非开发人员的职责。

如果没有经过深思熟虑的战略，著名的“人员、流程和工具”黄金三角就无法实现。如果不考虑开发人员的需求和挑战，他们也无法融入有效的安全流程中。

提升开发人员主导的安全水平需要重大的文化转变，而这始于能够让工程师和安全团队达成共识的教育路径。