Posted by Patrick Carey on January 16, 2017
RSA Conference 2017 is just a few weeks away and all you need to do to get a sense of the mind-boggling array of security solutions on the market is to take a walk through one of the two massive expo halls. Even if your search is focused on application security solutions, the wide variety of approaches (SAST, DAST, IAST, RASP, pen, fuzz, etc.), and myriad vendors, is enough to freeze anybody in their tracks. If you were building an application security toolkit, what tools would you need?
You can’t afford to put your head in the sand and hope that the network security measures used by your customers or internal operations teams will shelter your applications from attack. The truth of the matter is that hackers have realized that application vulnerabilities are like an unlocked back door, allowing them to gain access to sensitive systems and data simply by exploiting flaws in application design or implementation. In fact, a recent study by SAP noted that applications are the target of over 80% of cyber attacks.
Enter application security tools. These solutions help development teams locate and fix vulnerabilities before applications go into production. Most of these solutions fall into one of two categories:
There are many variations on these themes. Different solutions apply various technologies and levels of automation or optimize for specific types of apps. But in general, these variations simply improve their ability to perform one of these two testing functions. There are also some newer approaches, such as runtime application security protection (RASP), which attempt to bake security defenses directly into the application itself, though these are not yet widely used.
Many teams make this mistake. They determine that they need some kind of AppSec tool and assume that, once they pick one they like, they’ve checked the AppSec box and can move on. Unfortunately, what they usually find is that their one-tool plan leaves a lot vulnerabilities undetected. This is especially true when it comes to open source components. Off-the-shelf static and dynamic testing tools have shown themselves to be ineffective at finding vulnerabilities in open source components, as only a handful of the thousands of open source vulnerabilities recorded in the National Vulnerability Database (NVD) were found by them.
AppSec cannot be a check-the-box item. Rather than look for the nearest exit, you need to take a step back and look at the types of applications your team builds and how they build them, and use that information to make an informed selection.
It’s a trick question. No single tool or approach will fully cover the range of vulnerabilities present in most applications. To do the job right you are going to need to assemble a multi-tool toolkit tailored to the needs of your applications and development processes.
To help you get started we’ve put together an Application Security Buyer’s Guide. In it you will find descriptions of the various AppSec testing approaches as well as strengths and limitations of each. Using information in the buyer’s guide with the insights you gain from considering the above questions, you’ll be able to determine which tools you need in your application security toolkit, and establish a framework for evaluating specific vendor offerings as you fill that toolbox.
Get the latest Software Integrity news, thought leadership, and more.