Traditional application security testing (AST) tools are out of step with modern development and AppSec practices. In the age of cloud-native architectures, continuous integration/continuous deployment (CI/CD) models, microservices, and containerized environments, and at a time when code changes happen daily — and even hourly — AST products originally built for monolithic applications and slower release cycles come up short.

Traditional tools such as static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA) can’t meet the challenges presented by new practices and technologies such as microservices, serverless computing, cloud-native infrastructure, infrastructure as code, and API-first development. The increasing complexity of final software packages makes things even more difficult, as do new risks from automated, AI-powered attacks and from organizations’ own increased use of machine learning for software development.

New development practices often involve assembling software from many small projects, libraries, frameworks, and APIs that traditional AppSec tools are ill equipped to inspect. And because modern CI/CD pipelines have short timelines and service-level agreements, the long scan times of those older tools are just a bad fit.

They also can make life difficult for security teams because the tools report many vague or inaccurate findings and false positives that require human-mediated triage. SAST tools, for instance, often don’t provide enough context to easily find vulnerabilities without a lot of trial and error. DAST tools can struggle to authenticate to and simulate real traffic to modern applications that use a variety of complex protocols. And many SCA vulnerability findings are not exploitable in production.

Here’s what your development and AppSec teams need to know about the state of AST — and four key steps you can take to modernize your software security strategy across the applications you develop or the commercial software you purchase.

[ See our Special Report: Software Supply Chain Security for Dummies | Download the Dummies Guide ]

The history of AppSec tools explains the gap

Jeff Williams, founder and CTO of Contrast Security, said the tools gap developed because traditional tools failed to evolve to match today’s threats, which include the rise of software supply chain security threats. 

“These traditional tools were introduced in the market in the early 2000s, and they haven’t evolved to keep up with modern web applications and APIs.”
—Jeff Williams

Boris Cipot, senior security engineer at Black Duck, said older AppSec tools generally tend to work better with monolithic architectures.

“Modern application architectures, with their web services, endpoints, and communication technologies, have a much broader attack surface. This means that the tools testing such architectures need to have a broader scope and be able to work with a concept of distributed software.”
—Boris Cipot

A recent CyCognito survey of 349 security professionals in the United States and the United Kingdom uncovered a high level of concern over such issues. Respondents ranked effectiveness of existing AST tools as their third-biggest concern, after web security threats and a lack of collaboration between their development and security teams. According to CyCognito’s report:

“Organizations struggle with the ineffectiveness of the tools they are using to protect their web applications. Legacy tools like vulnerability scanners lack automated discovery capabilities, so they require frequent reconfiguration to keep pace with the changes in application environments.”

Because of the labor-intensive nature of such reconfigurations, many organizations simply choose to leave their software untested, the report found. “When it comes to implementing new web application security capabilities,” the report said, “respondents generally prefer to purchase new tools instead of supplementing existing ones.”

Understanding the history is important — but even more important is upgrading your AppSec tooling and strategy. Here are four key steps for modernizing. 

1. Implement a whole-lifecycle approach to AppSec

Modern application architectures have a broad attack surface. That means, said Black Duck’s Cipot, that an effective AppSec strategy requires having controls at every stage of the lifecycle: development, build, testing, release, deployment, operations, and monitoring.

Traditional tools can do that to a degree. SAST, for instance, can help identify vulnerabilities in proprietary code. DAST tools simulate attacks on an application to identify vulnerabilities from the sort of external perspective that an attacker would have. SCA can identify vulnerabilities in open source code and dependencies. Runtime or interactive security testing technologies enable a real-time application threat detection and mitigation capability by helping analyze runtime behavior, detecting anomalies and blocking attacks.

But none of these components should function as an island, Cipot said. “Working with all the results from the development, testing, and monitoring side can be overwhelming, and that is what is sometimes the biggest problem,” he said.

“A big part of establishing [the right] culture is training and empowering employees to make sure that they not only have the tools, but also the knowledge on how to use them and the processes to work with other [stakeholders].”
—Boris Cipot

AppSec posture management (ASPM) tools, which provide a continuous assessment of an application’s security posture through its lifecycle, can be a useful addition to a portfolio, he said. “ASPM emphasizes maintaining an ongoing understanding of the app’s security status, identifying risks and managing the application’s security hygiene across environments,” Cipot said. ASPM tools help development teams maintain oversight of the risks and to consolidate, triage and prioritize findings.

2. Harness AI — but keep expectations in check

AI and ML technologies could potentially drive significant efficiency and accuracy improvements around AppSec. AI-enabled tools can potentially help users better understand complex data, look for patterns, and interact with it to remediate vulnerabilities.

Tom Stacey, senior AppSec auditor at Outpost24, said vendors are beginning to automate business logic testing — a trend he perceived as improving the capabilities of automated scanners. AI is being used to bolster manual testing by providing the context of specific payloads for fuzzing and helping developers build test labs to try ideas on.

“All of this is pushing application security forward pretty darn quickly. It’s exciting, and I suspect some revolutionary ideas to come out of these tools in the future.”
—Tom Stacey

Cipot said he expects AI to make a difference in threat detection, by looking for patterns and anomalies, for example, and even by modeling responses to threats fast and well. “AI and ML will also be heavily used in automation work where the right testing tools will be used for different stages of the application lifecycle based on the usage of the application itself,” he said. “Another category where AI and ML will bring a lot of help will be in triaging and prioritization of findings and reduction of false positives.”

And Cipot noted that AI-enabled runtime application self-protection (RASP) tools are becoming available that monitor running applications for anomalies and then block attacks they have detected. “Another interesting approach is with ML algorithms that pull vast threat information of known threats and use it to create appropriate proactive defense postures,” Cipot said.

Of course, while AI holds promise for AppSec teams, it’s also posing new problems. “Multiple studies have shown that AI-generated code has more vulnerabilities than human-written code,” Contrast Security’s Williams noted, “which makes sense because the dataset they trained on is full of vulnerabilities. Second, developers using AI are generating this vulnerable code at a dramatically faster rate than before.”

AI might learn to find some vulnerabilities that are relatively localized, entirely contained, for example, in a single source-code file. But keep your expectations in check, Williams cautioned, when it comes to using AI to help find vulnerabilities in modern apps/APIs that are composed of many different parts and have complex control and data flow pathways.

“Every vulnerability is a beautiful and unique snowflake. And that means that there’s no way for the training data to contain similar problems, which leaves the AI blind.”
—Jeff Williams

Matt Rose, former field CISO at ReversingLabs, said recently that AI had introduced a whole new supply chain for application security teams to consider.

“AI and its effect on the software supply chain is like the fox guarding the henhouse. As an industry, we are struggling to ensure the security of our own organizations’ software supply chains, but what about the AI platform’s software supply chain? AI is software too, and we all know the challenges associated with securing software.”
—Matt Rose

As security teams try to wrap their heads around AI security, data supply chain security issues will mirror what the software world has already started facing with software supply chain issues. But proving data provenance is going to be an entirely new challenge — requiring new research, new best practices, and new technology.

Dhaval Shah, senior director of product management at ReversingLabs, wrote recently that modern tooling that employs complex binary analysis as a final check on software packages before release protects against these hidden dangers.

“As machine learning drives the next generation of technology, the security risks associated with model sharing and serialization are becoming increasingly significant. [Stay] ahead of these evolving threats with advanced detection and mitigation solutions.”
—Dhaval Shah

3. Implement advanced software supply chain security capabilities

A nine-month analysis that OX Security conducted of over 100 million security alerts, 140,000 applications, and thousands of code repositories showed that one out of every five applications contains errors that make them vulnerable to runtime risks. Common examples include vulnerabilities that allow malicious code injection, API attacks, unauthorized access, privilege escalation, container escape, and fileless and in-memory malware.

To protect against these threats, organizations need to implement capabilities for monitoring and analyzing application behavior in real time and in the production environment, said Contrast Security’s Williams. The goal should be to try to detect threats and mitigate them as they occur. Unlike tools such as SAST and DAST that are primarily designed to detect root-cause vulnerabilities in code or during the testing phase, runtime AppSec tools are more of a safeguard against threats that might crop up when the application is actually running. Runtime security tools generate accurate data by recording security events directly from running apps and APIs, Williams noted.

“Runtime uses instrumentation to add security checks to the app/API, just like an APM tool adds performance checks. Then you just run your normal QA tests and security testing is done automatically in the background.”
—Jeff Williams

The approach ensures that AST is done as soon as QA tests are done, making it completely compatible with modern development pipelines and workflows. “You can even just put runtime security into production and get instantly notified of any vulnerabilities there. The other advantage is that this technique is dramatically more accurate than traditional tools, meaning builds only break if there are real vulnerabilities,” Williams said.

Saša Zdjelar, chief trust officer at ReversingLabs, said runtime AST is helpful, but modern software supply chain security threats demand new controls for the software you build or buy.

“[Modern] enterprise security programs suffer from a sprawl of uncoordinated tools and continually fail at achieving software supply chain security. This calls for a new era of SSCS management, one in which universal controls can prioritize the mitigation of these threats.”
—Saša Zdjelar

Zdjelar said tools such as software bills of materials (SBOMs) need an upgrade too, beyond a simple list of components:

“[What’s needed is] visibility into the risks and threats in the entire application or software binary, in context.”

4. Complement testing tools with human testing

Most modern DAST and SAST tools integrate extremely well into DevOps workflows and remain fundamental to AppSec, said Outpost24’s Stacey.

“Every time code is pushed to your GitHub instance, for example, a SAST scan can be triggered to check for errors in the new implementation. Once the new code ends up in preproduction and production servers, you can run your DAST scanner to look for low-hanging fruit that may have been introduced as a result of the new features.”
—Tom Stacey

However, it is a mistake to rely entirely on the findings from these tools for securing your apps. Business logic and authorization controls, for example, can be fully vetted only via human testing. And that too is the case with any vulnerabilities that differ even subtly from patterns that DAST scanners are built to detect. While more recent SAST and DAST tools have improved significantly, they still leave critical gaps. It’s only when organizations can reliably automate 100% of human testing that such AppSec tools will offer full coverage, Stacey said.

Modern threats require modern tooling

Complex binary analysis is one area of AppSec tooling modernization that the public-private working group the Enduring Security Framework (ESF) is promoting. It believes that complex binary analysis is a must-have backstop for AppSec’s current shift-left focus.

As important as it is to test early, doing it often and doing again at the end of the build is equally important for holistic visibility and management of AppSec risks. This will be a crucial way for DevSecOps teams to get beyond shift-left lip service and start achieving continuous AppSec security measures all the way to the right-hand side of that SDLC timeline.

ReversingLabs’ Zdjelar said that as you shift right with a final exam for any software in use in your organization, you gain context as people add first-party and third-party commercial and open source code.

“What I think is missing in the SDLC of these producers, as well as on the consumer side, is the very, very last check of whether you are shipping a safe product when everything is built.” 
—Saša Zdjelar

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by Jai Vijayan. Read the original post at: https://www.reversinglabs.com/blog/state-of-appsec-tools-level-up