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
Newest First  |  Oldest First  |  Threaded View
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.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Exploiting Google Cloud Platform With Ease
Dark Reading Staff 8/6/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-13
Buffer overflow in a subsystem for some Intel(R) Server Boards, Server Systems and Compute Modules before version 1.59 may allow a privileged user to potentially enable denial of service via local access.
PUBLISHED: 2020-08-13
Uninitialized pointer in BIOS firmware for Intel(R) Server Board Families S2600CW, S2600KP, S2600TP, and S2600WT may allow a privileged user to potentially enable escalation of privilege via local access.
PUBLISHED: 2020-08-13
Improper initialization in BIOS firmware for Intel(R) Server Board Families S2600ST, S2600BP and S2600WF may allow a privileged user to potentially enable escalation of privilege via local access.
PUBLISHED: 2020-08-13
Unprotected Storage of Credentials vulnerability in McAfee Data Loss Prevention (DLP) for Mac prior to 11.5.2 allows local users to gain access to the RiskDB username and password via unprotected log files containing plain text credentials.
PUBLISHED: 2020-08-13
Out-of-bounds write in Kernel Mode Driver for some Intel(R) Graphics Drivers before version may allow an authenticated user to potentially enable denial of service via local access.