Security testing of applications and APIs, no matter which tool or method used, all comes down to dynamic or static evaluation. Interacting with the application as it runs, could mean manual penetration testing, using an automated DAST tool, or even an IAST tool.
Evaluating the written code could be manual code review, Software Composition Analysis (SCA) or SAST (static application security testing). As tools are repackaged and rebranded, testing tools continue to boil down to one or both of these options.
What is SAST?
SAST (Static Application Security Testing) is the automated analysis of written code (compiled or uncompiled) for security vulnerabilities.
SAST products parse your code into different pieces that it can further analyze, in order to find vulnerabilities that are many layers deep in regard to functions and subroutines.
SAST products are able to follow recursion many steps deeper than a human mind is capable;
And therefore they are able to find many more types of vulnerabilities than a human being (without using automated tools for assistance).
SAST products are often slow, full of false positives, and require a trained expert to use at their full potential. That said, they are also able to find many more types of vulnerabilities that could have been missed without their analysis.
Memory leaks, endless loops, falling into unknown states, unhandled errors and other exceptions, and so many more potential serious security vulnerabilities are easily found with SAST products.
One of the greatest strengths of SAST tools is that they are able to get complete code coverage, meaning they are able to analyze every single line of code within your application.
That said, studies have shown that a non-trivial percentage of the source code within modern applications are executed when our apps are in production or being used by end-users.
Which raises the question as to if complete code coverage is actually necessary to ensure that the applications you are creating are secure.
SAST tools are able to analyze binaries (byte code/compiled code) and (raw/uncompiled) source code.
What is DAST?
DAST (Dynamic Application Security Testing) is interaction with your running application with the purpose of finding and managing vulnerabilities it may have.
In order to find vulnerabilities using a DAST tool your application must be installed on a web server, a virtual machine, or a container, and it must be running during the analysis.
The DAST tool must proxy your web application’s communications, putting itself between the browser (front end) and server (backend).
DAST tools then analyze the requests and responses to learn about your application as it is used. Once it has seen all of the pages of your application (including the parts after authentication and authorization), the automation can begin.
DAST tools generally have a crawling feature to try to find any missed pages, and then they start to perform fuzzing and dynamic analysis.
What is Fuzzing?
Fuzzing is submitting malformed input to an application to verify that it fails gracefully. It is important to ensure that our applications never fall into an unknown state or crash. To do so use fuzzing tests by adding bad input into every possible field within the application.
Fuzzing also generally tests bound limits, to ensure that there are no overflow vulnerabilities within our applications, if our languages are not memory safe.
The bad input used for fuzzing is a combination of random, special characters, shell code, and anything else the fuzzer’s creators think may find problems.
After this the DAST tool performs more targeted, automated testing, often referred to as “active testing” or “attack”. It uses the information found during the crawling and fuzzing phases to create scripts that it can use to attack the application.
DAST Testing
DAST testing is partially an attempt to find business logic problems, but also to find implementation problems (security bugs/code problems).
A DAST tool can find several types of problems quickly and effectively, although it misses many types. Automated DAST tools are also not able to guarantee complete code coverage.
DAST Tools are also not able to promise that they will be able to find and evaluate every page or feature within your application, it is necessary to manually ensure that they have seen every single part of your application for complete coverage.
DAST tools are quick and effective wins, for security. They are able to find some things reliably, very quickly, which means that even unadvanced attackers would be able to also find those vulnerabilities.
It is important that if you easily find dangerous vulnerabilities using an automated DAST tool, that you fix them, to avoid falling prey to unadvanced malicious actors.
Top Tip
DAST tools are often used by Penetration Testers or Security Assessors, in conjunction with other security tooling.
DAST tools often contain features for performing manual security testing, which can then yield significantly more accurate results, when used by a trained professionals.
What is SCA?
Software Composition Analysis (SCA) is verification of the third-party libraries, frameworks and components used within your application; all of the code that you and your team did not write is considered by SCA tools.
Although SCA is often partially covered as part of SAST tools, it is not necessarily complete or exhaustive when compared to a standalone SCA tool.
The vulnerabilities that SCA tools find in third party components come from numerous places, including:
Common Vulnerability Enumeration
The CVE (Common Vulnerability Enumeration) database, exploit DB, independent security researchers, research that the vendor has performed themselves, and information released by the frameworks or third-party component creators.
SCA tools do not perform static or dynamic analysis of the code within the third-party components themselves, they report based upon the pre-created lists from the sources listed above.
SCA tools therefore do not evaluate the security of the components within your application while they run; instead they analyze your list of dependencies, cross reference them against their list of known-vulnerable dependencies, then report the matching dependencies are their findings.
This results in very fast reporting, and generally fairly accurate results when compared to SAST or DAST.
SCA is generally considered a very valuable tool for finding vulnerabilities in code and protecting your software supply chain.
Quality of Results
Automated tools are far from perfect; they will not only miss things, they will report issues that don’t exist.
Using multiple tools, having a skilled professional tune your tools and remove false positives, compiling your results from all tools
And then evaluating application risk based on your business is necessary in order to gauge your software threat landscape.
It is advantageous to combine all tool results after validation, as well as any manual testing results, in order to direct your defense efforts effectively.
You will never have time to action every result; thus prioritization is critical.
Comprehensive Security
As previously stated, just one of these tools alone are not enough to find everything wrong with your application, or often even to make it “safe enough” for the Internet.
Being able to protect your software supply chain and find vulnerabilities in both written and running code are fundamental for a complete application security program.
Conclusion
When it comes to application security there is no silver bullet; multi-layer approach is always required in order to ensure that the software you create is secure.
With our industry creating newer and more inventive tools all of the time, including tools that combine multiple aspects of security testing, we as an industry are moving forward towards helping software developers reliably create rugged, safe, and high quality software.
Anshu Bansal, a Silicon Valley entrepreneur and venture capitalist, currently co-founds CloudDefense.AI, a cybersecurity solution with a mission to secure your business by rapidly identifying and removing critical risks in Applications and Infrastructure as Code. With a background in Amazon, Microsoft, and VMWare, they contributed to various software and security roles.
