researchHQ’s Key Takeaways:
- Manual approaches to application vulnerability management are insufficient for fully visualising an application’s attack surface.
- Traditional approaches to application security testing often result in false-positives and -negatives.
- When vulnerabilities are identified, legacy approaches require them to be remediated manually, costing organisations a significant amount of time and money.
- An inside-out approach, focusing on securing applications in development and production, helps mitigate these issues by embedding and automating vulnerability identification and remediation.
Traditional approaches to application security (AppSec), such as legacy static application security testing (SAST) and dynamic application security testing (DAST), lack visibility across an application’s attack surface. As they analyze lines of code using brute force or look for code vulnerabilities based on a predetermined malware signature list, legacy SAST and DAST approaches miss false negatives while incurring high volumes of false positives. In addition, the lack of visibility into software routes means developers must expend significant time searching for and verifying that vulnerabilities were fixed. Simply put, modern software development demands a new approach to AppSec.
When Competing Forces Collide: Speed and Security
Development and security teams are frequently at odds. On one side, developers focus on code commits, release dates, and timelines. Their performance metrics are based upon getting a product out the door—on schedule and on budget. On the other hand, security teams are most concerned with preventing cybersecurity risks to the organization and ensuring they maintain compliance with applicable regulations.
Many organizations struggle to bridge the gap between these juxtaposed positions. 68% of organizations have a mandate from the CEO that nothing should slow down development. Aa a result, developers are under increasing pressure to shorten their release cycles and commit more code faster. Indeed, 52% of companies admit to cutting back on security measures to meet business deadlines.
The conflict between security and development teams creates significant security risks for an organization. If security impedes development, security testing may be performed in a haphazard manner. In some cases, developers may be under so much time pressure that they will skip application security testing altogether.
This poses serious risk. It starts with the fact that many applications contain serious vulnerabilities. Indeed, upwards of 35% of applications contain serious vulnerabilities based on recent Contrast Labs research. This has not gone unnoticed; cyber criminals have upped the ante—and the data proves this out. Over the past year, 43% of data breaches were tied to application vulnerabilities per the latest Verizon Data Breach Investigations Report.
A successful application security (AppSec) program is contingent on effective vulnerability management. But legacy AppSec approaches fail in this regard. Following is a quick look at some of the reasons this is the case.
Vulnerability Identification with Brute Force Using Legacy SAST and DAST
SAST and DAST are two very different approaches to application security testing. Legacy SAST takes a “white-box,” or signature-based, approach to testing, whereas DAST employs “black-box” testing that sends HTTP requests containing attacks and then checks responses to determine if the attack worked.
Challenges with SAST Testing
The challenge for SAST tools is that their constructed threat model is simply a guess at what vulnerabilities may exist within the respective application. The problem is static scanners focus on lines of code and attempt to piece together how the application runs and the data flows work. But it is impossible for them to trace the complex maze of program execution, state management, validation, encoding, and other programming idioms. The result is a list of vulnerabilities that are never exercised in runtime (or false positives).
When it comes to API security, the challenges are even greater. Static scanning is trained to look for standard “source” methods and to trace the program through. However, APIs use custom methods to read a JSON or XML document from the body of the HTTP request, parse it, and pass the data into the API. With every framework performing these tasks differently, it is impossible for a static tool to analyze the data flow—which results in false negatives. Open-source frameworks and libraries are just as problematic. Open source contains custom library functions that only custom rules can detect. As static scanning tools do not have visibility into the code, they are unaware of the risk.
Challenges with DAST Testing
DAST is a “black-box” testing model that sends HTTP requests containing attacks and checks responses to determine if the attack worked. While sometimes the responses are definitive, often the evidence is unclear—if there was a successful exploitation or if the application simply broke. API security is even more difficult, as there is no way for a DAST to know how to generate well-formed requests. Additionally, it is exceptionally difficult to provide the right data to automatically invoke an API correctly due to many applications using custom, nonstandard protocols, and data structures for their APIs. This translates into numerous false positives as well as false negatives.
False Positives and Negatives Waste Valuable Time
False positives and false negatives are very different, but they both result in wasted time for an organization, especially the development team. Each false positive that a static or dynamic scanning solution generates must be manually investigated and remediated by developers, delaying code commits and slowing release cycles.