You can only get rid of WAF if you fully implement security into your development process and audit the process via code reviews and annual tests. But DevSecOps can’t be realistically implemented for all web apps in the enterprise environment, so WAF will stick around because it still has a job to do.
The WAF is not dead, what’s left?
DevOps and the continuous integration and continuous deployment (CI/CD) pipeline provide an excellent opportunity to implement security, especially if your agile methodology includes security sprints. It allows for security to be built into the apps from the start, rather than taking the traditional route of applying it later, which is not only inefficient but – in the frenetic pace of CI/CD – can be overlooked, ignored, or forgotten.
Although security for all web apps should be built-in from the start, our experience shows that it is usually only applied to the “crown jewels,” like the company’s primary customer portal or client payment systems. In an enterprise environment, it’s not unusual for a company to be running old apps in which code is no longer maintained or apps integrated through acquisition.
Additionally, departments such as R&D and marketing frequently implement custom or third-party applications. This app proliferation can result in more than 50% of public-facing web applications in an organization being managed by DevOps or other disparate IT groups. These apps will need additional mitigation controls, which is where WAF comes in.
