To prevent cyberattacks, we need to focus on Application Security
Cyber attacks overwhelmingly occur at the application layer, yet the vast majority of IT security spending goes elsewhere. However, AppSec is not neglected because businesses are unwilling to address cybersecurity issues. In fact, the cybersecurity industry is poised to rake in a staggering $174 billion USD by 2024. In other words, businesses will spend more than the national GDP of Hungary on cybersecurity, but almost none where the attacks are happening.
Why?
One reason may be that software developers do not believe they can create completely secure code. For example, the Rice theorem demonstrates that using one program to find general vulnerabilities in another program is an undecidable problem. We also know that humans make mistakes and cannot reliably create flawless code. Perhaps these two factors have convinced security professionals to simply accept software as irrevocably vulnerable. Software cannot make other applications perfect, and humans can’t either, case closed.
Yet this kind of reasoning can lead developers to surrender ground to threat actors too easily. True, neither software nor humans can create flawless, large-scale applications. Likewise, we cannot make flawless cars, airplanes, computers, or cellphones. We create many things despite the fact that they will inevitably be flawed in some small way. To neglect AppSec on account of success not being 100% achievable is a textbook case of allowing perfect to be the enemy of good.
Fortunately, researchers like Fabian Yamaguchi and others were not willing to give up on AppSec, even if the problem has no perfect solution. Their work on the Code Property Graph (CPG) has vastly expanded the effectiveness of static application security testing (SAST).
Challenges of Traditional SAST
To understand how the CPG revolutionized SAST it helps to first examine the areas where traditional testing was lacking. Traditional SAST involved a two-pronged approach that could be considerably time-consuming. First, the dev would spend time searching for certain strings or parsing a primitive AST looking for specific vulnerabilities. Then, a QA analyst or security expert would spend time identifying the legitimate issues and separating them from false positives.
The limitations of traditional SAST led researchers to primarily focus on “insecure library functions, buffer overflows, integer overflows, or insufficient validation of input data”. In other words, traditional SAST required long timeframes and expert attention. Furthermore, any insecure interactions a program engaged in with open source or third-party code remained largely invisible to SAST testing.
Could DAST Remedy the Issues With SAST?
Aware of the challenges facing SAST, developers turned their attention to another type of software security testing. Dynamic application security testing (DAST) via simple fuzz testing, advanced taint tracking, and symbolic execution gave developers ways to test running applications. While this approach offered new opportunities to discover run-time vulnerabilities it could not replace SAST or resolve the issues facing static testing.
In fact, DAST can also demand a prohibitively long run time, as including additional execution paths increases the testing workload exponentially. Since DAST does not access the source code it is unable to highlight vulnerabilities or nuanced bugs buried deep within the codebase. DAST testing is also performed late in the software development lifecycle when fixing vulnerabilities is more costly.
By understanding the challenges and limitations facing both SAST and DAST it becomes easier to grasp why AppSec commands a negligible portion of cybersecurity budgets. However, innovations like the CPG should convince companies, organizations, and developers to take another look at investing more resources into AppSec.
How the CPG Revolutionizes SAST
The CPG is a data structure that vastly expands the capabilities of SAST. In fact, the CPG is the enabling component of ShiftLeft’s NG-SAST product for static analysis. To create a CPG, developers build a data structure using the features of three major code-related components:
- Abstract syntax trees
- Control flow graphs
- Program dependency graphs
This joint data structure creates a comprehensive view of code that can be queried using graph traversals. In other words, the CPG takes multiple aspects of the same code and uses innovative graph mining techniques to uncover vulnerabilities. Developers craft queries describing a potential vulnerability and then query the CPG to quickly search vast amounts of code for that particular flaw. This approach allows developers to find problems related to the code structure, control flow, and data dependencies all at once.
The value of using the CPG to test code was demonstrated by Fabian Yamaguchi and his colleagues in 2014. They ran CPG-assisted SAST tests on a well-known open-source project, the Linux kernel. Their work showed that almost all the vulnerabilities reported in 2012 could be described by graph traversals of its CPG. The researchers then demonstrated the effectiveness of the CPG by discovering 18 previously unknown vulnerabilities in the kernel. All the discovered vulnerabilities were accepted and remediated.
The power of the CPG is two-fold. It can quickly discover new vulnerabilities but also helps developers learn how to write more secure code by highlighting where mistakes were made. For example, the Linux kernel is worked on by over one thousand developers every year. It is a highly scrutinized, widely studied, decades-old piece of open-source code. Yet, Fabian and his colleagues were able to use a Linux Kernel CPG to find and remediate eighteen new vulnerabilities. This exercise showed them not only where the kernel was flawed, but how and why. As developers are exposed to the various coding errors that create vulnerabilities, they learn to avoid making similar mistakes on future projects.
Breaking the Language Barrier with CPGs
In traditional SAST the programming language of the source code must be supported by the testing tools. Yet the CPG is comprised of several abstract representations of the source code. This gives the CPG flexibility to be more language-neutral, similar to the way a compiler operates when performing optimizations. By working with an intermediate language instead of raw source code, CPGs can implement transformations without the hard language and platform limitations of traditional SAST tools.
Highly Configurable Testing
The heavy lifting of testing code with a CPG is performed by the data flow tracker. Since the tracker operates on an intermediate code representation, it can:
- Process configuration files
- Test across function boundaries
- Track the order of statements in a program
- Consider the context of the target of a function call and jump back as necessary
- Be adjusted to accommodate the desired testing timeframe through configurable heuristics
In short, the introduction of semantic CPGs with advanced data flow tracking has expanded the reach, accuracy, and effectiveness of SAST testing.
How CPGs and NG-SAST Can Help You
Application development is a fast-paced industry known for tight deadlines, long hours, and persistent pressure to reach the market quickly. Traditional SAST and DAST solutions take considerable time to run, often require expert analysis, and may miss major vulnerabilities despite the developer’s best efforts. In other words, the ROI for extensive code testing has historically been unjustifiable for many software companies. The time and resources needed to ensure code is flawless at release have been much greater than simply issuing patches and updates later.
However, NG-SAST, powered by innovations like the code property graph has made identifying security vulnerabilities easier, faster, and more comprehensive. The ShiftLeft NG-SAST tools can help developers analyze and remediate code up to 40x faster. In OWASP testing, NG-SAST tools performed nearly 300% better at identifying vulnerabilities. More importantly, developers using NG-SAST tools can quickly discover problems with the code they write and correct their mistakes on future projects.
The application layer is a primary vector for cyber attacks because many developers and analysts see it as permanently vulnerable. Yet every time developers take a step forward in securing code, threat actors are pushed further back from their goals. Code does not need to be perfect to significantly reduce cyber attacks, it simply needs to be better.
Contact ShiftLeft to learn how your organization can take advantage of NG-SAST to improve its AppSec today.
Top comments (0)