在安全编码的未来中，人为因素扮演着怎样的角色？

随着网络威胁日益增多，企业在安全性、实用性和速度之间不得不进行日常权衡，而这一过程也使自身暴露在风险之中。我们需要全新的安全编码方法，因此 Secure Code Warrior 与 Evans Data Corp. 合作，针对开发者对安全编码、安全代码实践和安全运营的态度进行了初步研究（点击此处下载白皮书）。

该报告揭示，尽管“老派”的被动思维仍占据主导地位，但人们越来越意识到需要更主动的解决方案，将开发者自身转化为第一道防线。

任何关于采用安全编码实践的探索，都必须从了解参与实施的人员、他们对该实践的看法以及他们的实施能力开始。这进而引出了难题中最关键的部分——如何赋能他们从一开始就更安全地编写代码，并以更快的速度、更自信地交付高质量代码？

安全编码——我们现在处于什么阶段，又需要做出哪些改变？立即 下载信息图表《人为因素》。

当前视角——被动与主动

当询问开发者和开发经理他们认为哪些活动与安全编码相关时，排名前三的回答是：

• 在已部署的应用程序上使用扫描工具。
• 手动审查代码中的漏洞。
• 积极且持续地编写能够抵御漏洞的软件。

正如我们所见，前三名回答中有两个仍然侧重于被动方法——第一个依赖于工具（扫描器），第二个依赖于开发者（即人为）执行手动检查。

与此同时，所提名的三项活动中有两项依赖于人为因素。这表明人们越来越将安全视为一个人的问题。但在所有被提名的活动中，最能说明问题的是第三项，它指出了人为因素在从源头上编写能够抵御漏洞的软件方面的重要性。这凸显了向“左移”的转变——一种主动且预防性的方法，将安全融入到软件开发生命周期（SDLC）的最初阶段。

安全在 SDLC 中处于什么位置？

当询问开发者和开发经理他们认为安全代码实践应如何融入 SDLC 时，意见各不相同。55% 的经理认为安全编码已融入整个开发过程，而只有 43% 的开发者持相同看法。这种差异可能反映了这两类群体在 SDLC 中角色的不同。管理层通常较少参与实际的编码工作，倾向于从更高层面审视问题，而开发者可能更关注具体的细节。

但从整体安全和代码质量的角度来看，令人担忧的是，只有 13% 的开发者和 10% 的经理认为安全代码实践应融入设计阶段——即 SDLC 的最开始。这是一个巨大且尚未实现的机遇。根据 IBM 的一项研究，修复发布后代码中的漏洞，其成本是发现并修复初期漏洞的 30 倍。1 这为一种全新的、以人为本的主动式软件安全防御提供了强有力的激励，使开发者能够从一开始就更安全地编写代码。软件安全不能仅靠依赖工具来解决——它必须考虑到人为因素。

人为因素准备好了吗？

97% 的受访开发者认为他们接受过充分的安全编码培训，95% 的人认为安全编码培训对他们的职业生涯很有价值。但在全盘接受这些说法之前，我们需要问：为什么代码漏洞仍然如此普遍？开发者声称拥有安全代码专业知识，是否仅仅是出于虚荣心？证据确实指向了这一点。在更谦虚的承认中，超过 88% 的受访开发者承认安全编码很难学习，91% 的开发经理承认安全编码实践难以实施。当被问及在实施安全代码方面的主要个人顾虑时，28% 的开发者认为学习过程具有挑战性，而 24% 的人认为学习过程枯燥乏味。这表明开发者培训确实需要改进。

人为因素需要什么？

为了克服“挑战性”因素，有价值的安全培训需要一个“脚手架”过程，支持开发者一步步建立安全编码技能。为了实现最大的相关性和即时适用性，培训应使用他们每天使用的特定语言和框架进行。

为了克服“枯燥”因素，安全代码培训需要以实践方式进行——事实证明，这对开发者而言比过时的课堂教学或“观看视频”模式更具吸引力。这些培训应包括实时模拟，让开发者能够在安全的环境中应对有时具有风险的安全挑战。目标应该是教会开发者如何在工作时发现并修复代码中的漏洞，并将安全编码融入他们的日常工作流程中。另一个关键的赋能因素是 IDE 内置的 Linting 和辅导功能，它能帮助开发者在编码时不断学习和提升技能，从而在过程中预防和消除漏洞。

如果您想了解如何为您的开发者提供这种全新水平的以开发者为中心的工具和培训，请预约演示。

您也可以下载白皮书《从反应到预防：应用安全的新面貌》。

‍