但事实上，如今现代应用生命周期加快了 DevOps 的更新发布频率，而传统 WAF 根本无法跟上发布步伐，并且 WAF 维护流程较为复杂，需要耗费大量人力资源。
面对这一挑战，安全专业人士应该怎么做？什么会阻止 Web 应用成为组织基础架构的前门？我们知道 DevOps 会不断开发新代码，但如何确定 WAF 是否还值得维护或者是否已无药可救？
下面让我们仔细了解一下 WAF 如何才能跟上 DevOps 的速度。
上下文逻辑是关键所在
网络安全旨在监控使用相同协议的静态网络，而 WAF 旨在保护相差甚远的 Web 应用。每个应用都是独一无二的，每段代码也都互不相同，并且各自都有一系列漏洞。在引入云存储和 DevOps 加速之前，WAF 就被认为只是一种“平庸的”安全解决方案。使用位于应用前面而非内联的解决方案意味着无法进行上下文分析。如果没有上下文来帮助理解正在交互的应用内容，WAF 演进的自动化速度就无法跟上应用演进的速度。
学习不停歇
机器学习的改进只是在一定程度上解决了这个难题。虽然复杂的 WAF“只”需学习一个月即可创建应用基线，但放任应用在一个月内不受保护实在太久了。人类难免需要介入，帮助校准 WAF，但维护工作的负担也会因此加重。如果 WAF 在内容或代码每次发生更改时都需要花时间学习和创建基线，那么为了减少警报和创建异常，管理员需要开展大量工作。
自动化关系成败
面对持续交付，WAF 不可能在没有人类干预的情况下有效保护 Web 应用免受逻辑攻击。实际上，大多数 WAF 都不处于警报模式。过度拦截存在巨大的风险，因为大量警报会造成警报疲劳。也许管理员可以进行微调，以便使用拦截规则保护应用的敏感部分，而应用的其余部分则由处于警报模式下的 WAF 使用模式匹配及其他简单技术加以保护。但这会导致安全解决方案无法随着应用的发展自动部署以防止新的逻辑攻击。
加速还是弃用
原生云计算关乎敏捷性。2015 年需要花两周时间才能创建完的内容现在只需几秒钟即可完成。借助新型微服务，您可以在几分钟内大幅更改应用。在这种新环境下，考虑使用依赖学习或手动配置的标准传统应用安全解决方案会很荒谬。
每当开发人员调整和对外发布代码，都是单方面的举动，无需与安全人员协商。如果您使用的 WAF 假设环境中的一切都是通用的，则意味您的 WAF 已经失效，是时候放弃使用了。
WAF 已成过去，DevOps 时代来临。现在是时候进行取证分析，以确定您的 WAF 是否尚可使用，还是已成为累赘。请回答以下几个问题：
• 您的 WAF 是专为云设计的吗？
• 您的 WAF 能否辨别合法流量用户和恶意流量用户？
• 您的 WAF 可以辨别合法查询和 BOT 及其他 OWASP 攻击向量吗？
如果上述问题的回答均为“否”，那么是时候评估您的云应用安全性了。
