Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

02:30 PM
Manish Gupta
Manish Gupta
Connect Directly
E-Mail vvv

A New Approach to Application Security Testing

If the appsec industry were to develop a better AST solution from scratch, what would it look like?

As software, aka applications, microservices, and workloads, increasingly moves into the cloud, its protection has become paramount. Recent research highlights this need, pointing to application vulnerabilities as the leading source of security breaches in 2018. The "Verizon Data Breach Investigations Report," for example, confirms that a vast majority of breaches happen either due to spear-phishing or application vulnerability exploits. These are the two seminal challenges for cybersecurity in the coming decade.

Yet the ugly truth, according to a recent SANS Institute survey titled "Secure DevOps - Fact or Fiction?," is that only 10% of organizations report repairing critical vulnerabilities satisfactorily and in a timely manner. Clearly something has to change.

In order to understand what that change is, we first need to have a clear view of the current state of application security. Application security operates in the development (dev) and production (prod) phase of the software development life cycle (SDLC). In dev, the goal is to find and fix vulnerabilities before releasing insecure code. In prod, the goal is to protect the application from all of its vulnerabilities. Theoretically, software providers need only one or the other, but since neither is foolproof, most companies cover their bases with some form of both.

Gartner identifies three available code analysis techniques:

1. SAST: Static application security testing analyzes the application from the inside-out by inspecting its source code. SAST's advantages are that it leverages fundamental knowledge of vulnerabilities to inspect the source code and is therefore the most thorough of all AST techniques. It can be used for any code as long as the programming language is supported, and it's performed closest to dev, making it the least expensive way to find and fix vulnerabilities.

On the flip side, traditional SAST scan times are slow, requiring hours or even days to complete, which doesn't work well in increasingly automated continuous integration and continuous delivery (CI/CD) environments. False-positives are also an inherent part of the SAST process. Moreover, traditional SAST does not analyze an entire application, forcing organizations to buy a separate tool for software composition analysis (SCA). Even SCA merely identifies publicly known vulnerabilities; unknown vulnerabilities in open source, third-party APIs, or frameworks is out of scope for both SAST and SCA.

2. DAST: Dynamic application security testing probes the application from outside in, treating it as a black box and testing exposed interfaces for vulnerabilities. DAST generally results in low false-positives and can be performed even when the application's source code is not available (for instance, with third-party applications). It is particularly good at accurately identifying externally visible vulnerabilities. DAST can be performed for any application, regardless of programming language, as long as the test scripts are available, and it can find vulnerabilities in open source software, third-party APIs, and frameworks.   

That said, DAST requires test scripts to test everything, which is impossible from a practical standpoint and requires heavy reliance on experts to write tests, making it difficult to scale. More importantly, by definition it only analyzes exposed interfaces, which presumes an attacker only has external access – yet insider threats and complex "peel-the-onion" attacks are some of the most dangerous. DAST also provides insufficient information to the developer about why and where a vulnerability exists, requiring considerable time to identify the root cause. The efficacy of DAST is thus directly proportional to the quality and volume of QA, making it ill-suited for modern, fast-paced DevOps pipelines.

3. IAST: Interactive application security testing aims to improve on DAST by instrumenting the application to allow deeper analysis (beyond just exposed interfaces) and can be considered a superset of DAST. Its advantages and disadvantages are similar to those of DAST, with the added drawback that the application instrumentation means it needs to support the application programming language. In particular, it can only be performed on languages that have a virtual runtime environment, such as Java, C#, Python, and NodeJS. It cannot support languages such as C, C++, and Golang.

A New Approach
Clearly each approach has advantages and disadvantages. But if the appsec industry as a whole were to develop a better AST solution from scratch, what might it look like? First, its analysis would mirror the more comprehensive inside-out paradigm of SAST but be much, much faster. Like DAST, it would analyze the entire application, including dependencies, third-party APIs, and frameworks. After all, a hacker only needs one vulnerability in an entire application to wreak havoc.

The analysis also wouldn't be generic. Developers would be able to leverage their application knowledge to write new custom queries or edit existing ones. For instance, if a team has written a custom API to escape inputs, the tool needs to take this API into account. A better approach would understand the flow of an application so even when no clear vulnerability is identified (a false-negative), monitoring of runtime behavior compared to the inherent flow of the application can identify when an application has been successfully exploited.

As noted earlier, SAST in itself is incomplete, so it should be combined with the ability to take data from the production environment to address otherwise inherent reachability challenges. This would require a microagent that deeply instruments the application (like IAST) and is designed around the stringent performance and stability requirements of a production environment. Because this microagent is designed for production, it should easily run in QA where, if tested with QA/security test scripts, can function as an "enhanced" IAST. Yet, unlike IAST, the microagent should learn from SAST where it needs to instrument the application. So, for example, if the application is not vulnerable to SQL injection, why instrument the application and alert on SQL injection patterns?   

Given that only 10% of organizations today report satisfactory and timely repair of critical vulnerabilities, regardless of how good an AST tool chain is, there will be unfixed vulnerabilities deployed into the production environment. In other words, AST does not eliminate the need for a tool to protect applications in production.

Yet today's typical security approach is to deploy a tool or appliance that continuously alerts on threats, regardless of whether the application itself is vulnerable to that particular threat. Even if the alert is relevant, it demands considerable time spent investigating if, and where, the vulnerability exists. Worse, when a vulnerability is not relevant or has been fixed, the security tool will continue generating alerts regarding the same, now benign traffic.

In contrast, this better approach instruments the application based on SAST findings, ensuring the protection is high-performing and accurate. It will also tell the developer about the vulnerability and the specific location in code that needs to be fixed.

That's the point of continuous improvement: code analysis informs runtime and runtime traffic informs code analysis. And it should be the key goal of every application security program.

Related Content:



 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.


Manish Gupta is the CEO and co-founder of ShiftLeft Inc. He was previously the chief product and strategy officer at FireEye, helping grow the company from approximately $70 million to more than $700 million in revenue and expanding the product portfolio from two to more than ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
User Rank: Strategist
4/9/2019 | 4:10:52 PM
Combination of Approaches
As the lead App Sec Architect for a healthcare SaaS offering, we moved from SAST to a mixed model.  In our scenario, we injected IAST into our test suite, and then automated DAST (alongside selenium automation).  The net result was actionable intelligence with reporting in a manner that made security just another of the testing practices.  We found SAST of limited value, with a signal to noise ratio that required supplementing traditional solutions with filtering and mapping that compensated for it's shortcomings.  Eventually, SAST was retained to satisfy regulatory requirements, while the integrated IAST and DAST suite was the basis for decision making.
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-23
Vulnerability in OpenGrok (component: Web App). Versions that are affected are 1.6.7 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via HTTPS to compromise OpenGrok. Successful attacks of this vulnerability can result in takeover of OpenGrok. CVSS 3.1 ...
PUBLISHED: 2021-06-23
A vulnerability in SonicOS where the HTTP server response leaks partial memory by sending a crafted HTTP request, this can potentially lead to an internal sensitive data disclosure vulnerability.
PUBLISHED: 2021-06-23
A command execution vulnerability exists in the default legacy spellchecker plugin in Moodle 3.10. A specially crafted series of HTTP requests can lead to command execution. An attacker must have administrator privileges to exploit this vulnerabilities.
PUBLISHED: 2021-06-23
Heap based buffer overflow in tsMuxer 2.6.16 allows attackers to cause a Denial of Service (DoS) by running the application with a crafted file.
PUBLISHED: 2021-06-23
Heap based buffer overflow in tsMuxer 2.6.16 allows attackers to cause a Denial of Service (DoS) by running the application with a crafted file.