The state of application security testing: The shift is on to secure code
Application security testing isn't what it used to be. As the software delivery lifecycle has shrunk, testing has had to evolve to find ways to produce high-assurance, high-value results without creating a drag on the development process. Businesses expect testing tools to fit into the development cycle earlier. And, in contrast to past practices, testing is more often than not driven by developers, not security specialists.
The initial phase of application security was serving the security team, and making them feel comfortable that the application going into production was secure, said Chris Wysopal, CTO of Veracode. But for the last few years it's been all about the development team, making sure testing is done early and, more importantly, getting results early so they can fix security problems as part of their normal workflow.
"DevOps and the trend toward rapid, iterative development processes has caused a real need for speed. The only way you can accomplish that is through integration into the developer's workflow and shifting left."
With the software development ground shifting, it's time for application security teams to get a move on—from app sec after the fact to secure code throughout the software development lifecycle. Here's what you need to know about the state of application security testing, including platforms and app sec tooling.
The shift is on
Application security testing grew up around a proliferation of point solutions. Now organizations want a more holistic approach. "They want the broadest set of capabilities across an application environment," said Scott Johnson, general manager at Micro Focus's Fortify application security division.
Testing technologies such as dynamic application security testing (DAST) that were traditionally deployed near the end of the development lifecycle have moved left in the process.
"You might still want to do that, but as microservices and APIs are introduced, it makes sense to do some of that dynamic analysis closer to the beginning of your DevOps process."
DAST tests applications in their dynamic, running state during testing or operational phases. It simulates attacks against an application and analyzes the app's reaction to them in order to discover vulnerabilities.
DAST tools used to be in the exclusive domain of security types, but now they're being shared with development teams, said Garrett Gross, technical advisor for application security at Rapid7.
"Today, we're doing things with DAST such as integrating with build automation tools like Jenkins, Bamboo, and Azure DevOps and giving application testing functionality to the development team."
It's smart to bring developers into the fold, rather than making them just a digester of information, Gross said. "We try to integrate with their existing tooling and workflow to augment it in a positive way rather than interrupt it."
When containers met testing
Containers—which allow code and all its dependencies to be neatly packaged so it can run across computing environments—have also had an impact on the state of application testing.
Containers and orchestration systems expose new vulnerabilities, but when implemented correctly, they can provide a significant amount of security enhancements compared to legacy technologies, said Jack Mannino, CEO of nVisium.
"Testing requires analyzing the code, containers, cloud architecture, and orchestration systems to expose weaknesses at different layers of the stack."
As long as containers continue growing in popularity, the attacks will grow as well, said Dan McInerney, a senior researcher with Coalfire.
"Containers provide similar attack vectors as regular servers—unsecured services running on open ports, access control issues, and privilege escalations, to name a few. Testing containers for vulnerabilities is similar to testing a standalone server."
Rani Osnat, vice president for strategy at Aqua Security, explained that the concepts behind container security are similar to those used in traditional application security testing technologies like DAST and IAST (interactive application security testing) in development and RASP (runtime application self-protection) in runtime, but the mechanisms are very different.
For example, containers are governed by immutability. That means when you run them, their contents are not supposed to be changed in any way. You make changes at the source of the container—the container image—and that changed image replaces all of the old versions of the image in circulation.
While all applications are increasingly dependent on open source code, containers are especially so.
"Immutability gives us a very good ability to understand what's normal and what's not normal, because changes during runtime are not supposed to happen. People will take an open-source container image from a public registry, like Docker Hub, and use it as the basis of their application. That can open the door to many vulnerabilities that exist in open-source components."
Think secure code vs. app sec
With many enterprises deploying their own mobile apps, testers also have to hone their tools to analyze the source code and APIs in those apps for possible vulnerabilities.
"APIs, microservices: That's the new way folks are structuring applications, so you need to consider that in your security testing. It's rare to find an application today that doesn't have an API, and it's even more rare to find a mobile app not based on an API."
One of biggest changes affecting the state of application security testing lies in the applications themselves, Wysopal said. That's because services such as AWS Lambda can run code in response to events and automatically manage the resources needed by that code.
"The traditional application is getting obsolete. Maybe we should start talking about code security instead of application security."
All together now
You can have a line of code that may be vulnerable in one context and not in another, Wysopal said. You need to look at the environment the code is written in so when we scan that code we can decide that in this context the code is a vulnerability, but in this other context, it's not, he added. "In order to avoid false positives, we have to understand that. That's the world that application security is living in now."