经过多年的停滞，开放 Web 应用程序安全项目 (OWASP)前 10 名名单终于出现了一些变化。

最值得注意的是，不安全的设计作为 Web 应用程序的第四大安全风险首次出现在列表中。

“如果我们真的想作为一个行业‘左移’，它需要更多地使用威胁建模、安全设计模式和原则以及参考架构，”OWASP 说。

这击中了头上的钉子。对于行业来说，这是一个很好的迹象，组织正在适应并继续负责任地向左移动，并指向我们一直在想象的一切即代码的未来。

OWASP 的这一补充最终认识到了组织努力解决安全问题的一个关键原因。今天的很多安全都是被动的，组织在部署应用程序很久后发现问题，在几乎每个行业的安全专业人员都太少的时候，让安全团队充当消防员。

为了有效地向前推进，我们需要转变思维。

研究表明，如果组织在设计中解决了这些相同的问题，他们将消除消防成本并显着提高开发人员的生产力。它还将使安全团队能够专注于安全的战略需求。

OWASP 的这一变化认识到，在做出关键软件设计决策时，安全需要在谈判桌上占有一席之地，并且需要以与 DevOps 团队被授权拥有和管理应用程序的安全设计和实施的方式相同的方式授权安全团队。

一个独特的转折点：DevSecOps

安全漏洞继续堆积，但许多组织还没有重新检查他们的反应方法，它忽略了导致问题的架构问题。我们不能继续以这种方式运作。

我们需要一种更加动态和全面的云原生应用程序安全方法。我们需要承认在开发生命周期太晚检测到错误配置的失败。以这种方式进行扩展是不可能的，并且您最终会在此过程中创建太多规则。

我们需要更积极主动的参与，这在速度为王的应用程序开发世界中可能很困难。

开发人员和 DevOps 团队应将安全视为值得信赖的合作伙伴，并在开发生命周期的早期让他们参与进来。他们应该明白，他们对安全负有共同的责任。安全团队应该采用适合开发人员工作流程的自动化，并通过使安全民主化来使他们的生活更轻松。

一切即代码的未来

如果我们能够继续负责任地向左移动，我们将继续以一种会产生连锁反应的方式推动行业向前发展，包括在 OWASP 前 10 名中。

在一个完美的世界里，我们会看到框架和应用程序基础设施解决了构成当今前 10 名中很大一部分的输入验证问题。这些问题应该不在列表中，前 10 名应该关注导致当前列表的系统性问题——比如不安全的设计。

随着我们迈向应用程序和基础设施之间界限模糊的一切即代码世界，OWASP 可能会更广泛地关注一切即代码，这将包括一类新的问题，例如云代码、基础设施即-代码、管道即代码和安全即代码。虽然肯定还有更多工作要做，但这将是一个强烈的信号，表明我们正朝着正确的方向前进。