It’s easy to start security by beginning at the end – using external, late-cycle, full-system testing such as penetration testing (I might call this something like DevTestOpsSec). This testing is great for demonstrating that the application/system doesn’t contain any of the vulnerabilities enumerated in OWASP, but this black-box testing is not the most efficient way to actually produce code that is more secure.
We don’t want to rely on black-box testing as a way to secure our software or find bugs, as much as we want to use it to prove that the software is secure. So if the penetration testing finds a vulnerability, we need to ask ourselves why and try to address the root cause underlying the problem.
This is when we move from a “test security in” to a security-by-design mentality. For this, you’ll find static application security testing (SAST) tools such as static code analysis, with support for OWASP.
But SAST is a pain, isn’t it?
The beauty of static analysis is that you don’t need to have the whole application or system finished, so you can start checking for security problems much earlier in the cycle (to shift-left security testing). If you’re doing security late or near the end of your development (DevOpsSec), you can use static analysis to push security earlier, before testing even begins, while the code is actually being written (DevSecOps).
The ugly side of static analysis is that it has a reputation for being very noisy, for example producing hundreds or even thousands of violations right when you thought you were ready to release. Luckily there are some very good strategies for dealing with this. Here are a few things to keep in mind:
- Don’t save security testing until the end. Instead, start running static analysis as soon as you start coding. If you wait and only run it as part of your CI/CD pipeline, then the findings will pile up and overwhelm your development team. Run it on the desktop to find problems, and run it in CI/CD to simply verify that the code was built properly
- Fine-tune your configuration. Some static analysis checkers may not be needed in the context of your code. Check your application and determine which security risks matter for you and only work on those. Never look for issues you don’t plan on fixing.
- The age of the code matters. The age-old “If it ain’t broken, don’t fix it” should apply to legacy code. Only run the most critical security scanners against older code. Minor issues will waste our time and these changes bring their own new risk. Never check code you don’t plan on fixing.
- It’s all about risk. SAST tools find both real vulnerabilities as well as potential ones. Not all findings have the same potential risk. OWASP has helped by defining risk for each item in the Top-10 based on how easy it is to exploit a weakness, how easy it is for someone to find the weakness, and what the actual impact of the exploit may be. Use this helpful information to prioritize and triage your SAST findings:
The power of prevention
I’d like to emphasize something that is important if you want to truly harden your application. It’s very easy to test for security, but more difficult to build for it. Luckily, static analysis checkers come in different flavors. Some checkers look for typical problems like tainted data and try to figure out if there is a flow in the application where it could happen. These are the most common checkers in many SAST tools. The bigger value in static code analysis lies in checkers that enforce two special things:
- A pattern that is frequently associated with problems in the past. While this may not be as interesting looking as a specific stack trace to an exploit, it can be much more thorough to simply fix everything that is weaker than it should be than to only fix issues that have a proven attack vector.
- Requirements of specific types of coding to ensure proper functioning. Automotive and aircraft standards like MISRA and JSF rely on this technique to ensure functional safety. The same technique of requiring good code in addition to flagging bad code will help you build more-secure applications.
Ironically, this is the approach that safety-critical industries have used for decades with hardware and software, but somehow in cybersecurity we think we can test security into an application and don’t need to focus on building secure code. Leverage the full capabilities of proactive static analysis in addition to early-detection checkers to get the most value.
Summary
Getting OWASP Top 10 won’t be easy if you’ve never focused on security, but it is achievable. DAST is a simple way to get started with the Top 10, and then using SAST will help you shift your security testing left.
Implemented properly, SAST can even prevent problems, not just detect them, so look for tools that fully cover the standard, with both detection and preventative checkers.
Learn how to utilize OWASP risk scoring to help prioritize the findings and make sure your tools output this risk information with their findings. This will help you focus on what’s most important and is key to a successful OWASP implementation. With these tips you should be ready to start eliminating the most common and dangerous web application security risks today.