A key approach to shifting security left is moving perimeter-focused security solutions down the stack by placing them in front of services and other infrastructure components, such as containers and container orchestration systems or API management systems and gateways.

While this does allow for more granular security, it's not a free lunch for developers. Just saying "The WAF will stop it" subverts the entire thinking and purpose of shifting left. Rather, developers must move from thinking of Web application firewalls (WAFs) as a prophylactic, to instead thinking of WAFs as a crucial part of their secure coding test process. Here's how they can accomplish that.

The Explosion of WAFs and Cloud-Native Software

While many companies still deploy WAF appliances, the fastest-growing segment of this market is WAF software that runs in the cloud. With the rise of cloud-native architectures and ephemeral infrastructure, more organizations are putting WAFs deeper into their application stacks — right in front of microservices. Some are even using WAFs for internal protection to enact robust zero-trust frameworks. So, the new reality is, developers are far more likely to come into close contact with WAFs today than at any point in the past. That said, WAFs at the microservice level are not foolproof.

Before Deploying the WAF: Secure Coding Is Critical

To start, developers must create applications under the assumption that all security controls can and will fail. This is important because it encourages them to build applications that are secure by default. Secure coding means using basic design principles — like code minification to obscure code — while ensuring that all variables and calls are checked against the OWASP Top 10 vulnerability list. There are dozens of ways that attackers can exploit poorly written code, including SQL injection, cross-site scripting, broken access controls, and file upload vulnerabilities.

A key part of this effort is to ensure developers are running linters and formatting checkers against all code. Usually, you will want developers to run code through software composition analysis (SCA) to identify risky dependencies and libraries that require updates. A secure coding process and mentality is more critical now because cloud-native microservices have turned security inside out.

At this point, the application security or DevSecOps teams run the code against some sort of simulation and add the WAF. For many developers, this is the end of the story. They assume, "We have deployed a WAF. We're safe now." They are wrong. Increasingly, the applications developers ship microservices, linked via APIs. Developers "own" their microservices and APIs and are responsible for security. The microservices and APIs may have highly specific rules and optimizations that can impact WAF behaviors and policies. Each application is different, and many unique APIs emerge.

For microservices, developers tend to rapidly ship code and make faster iterations on microservices because those smaller applications are loosely coupled and do not impact other applications. That makes for greater agility but also greater security risk if the changes are not run through the same cumbersome security process as observed at application launch.

Learning to Think Like a WAF Operator

Developers should always ask themselves before they ship code, "How will this impact my WAF coverage and security posture?" This question is good because it teaches them to think about how WAFs are working and not working — in other words, threat modeling.

Threat modeling is critical because there are known ways that attackers work around WAFs or exploit WAF weaknesses. For example, by default, Kubernetes exposes APIs for services and connections. Locking down Kubernetes APIs without messing up functionality is notoriously difficult, particularly if you're changing the applications and service calls in the applications on a regular basis. Recently, Shadowserver Foundation calculated that 84% of Kubernetes APIs servers had left themselves exposed to detection on the public Internet.

Understanding a WAF is a key precursor to threat modeling and, by extension, thinking like a firewall operator. Some WAF comprehension is tacit knowledge. For instance, tuning a WAF to limit false positives and false negatives to an acceptable level remains challenging. Developers looking to shift left can piggyback on experienced WAF operators to learn the tuning process and, in turn, better understand how the WAF responds to real-world traffic. Today, some organizations also deploy machine learning to help developers easily tune their WAFs by making rule and policy suggestions based on unsupervised learning across multiple WAFs.

Better WAF Comprehension Leads to More Secure Code

Even better, good WAF comprehension also transfers over into more secure coding. Developers that intimately understand WAFs — and have hands-on experience tuning them — benefit from tacit knowledge that is difficult to teach, and experience that goes beyond Open Web Application Security Project (OWASP} checklists. An equally good practice is, in a safe environment, to have developers work alongside red-team members to see how a smart attacker might compromise their apps and bypass default WAF settings.

The bottom line is simple: Developers, take time to know your WAF and learn its weaknesses. WAF wisdom will help you write secure code now and save your apps from being hacked in the future.