When it comes to application security (AppSec), most experts recommend using Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST) as “complementary” approaches for robust AppSec. However, these experts rarely specify how to run them in a complementary fashion.
At Veracode, we use SAST, DAST, SCA, and pen testing as the four pillars of our defense in-depth strategy to deliver a “secure-by-design” AppSec methodology across the entire software development life cycle.
Manual penetration testing
Most organizations start their AppSec journey by running manual penetration tests (MPT). Penetration testing is necessary to catch vulnerability classes, such as authorization issues and business logic flaws, that cannot be found through automated assessments alone. Expertly trained pen testers can review an entire environment, rather than just the application, and can follow or break the workflows in a way that is difficult for automation to replicate. Additionally, pen testing is required to comply with regulations such as PCI DSS, HIPAA, GLBA, FISMA, and NERC CIP.
However, pen testing is only one assessment type and can bottleneck development velocity because it is a manual process.
How does Dynamic Analysis work?
Dynamic application security testing (DAST) is an AppSec assessment that scans all applications and interconnected structures in a running environment without looking deeply into source code. The results of “outside-in” dynamic scanning help prioritize the remediation of exploitable vulnerabilities and immediately reduce AppSec risk as they are fixed. However, it can be challenging to pinpoint the exact line of code to work on using only DAST. This assessment on its own is limited by the configuration of your scanner and what you choose to test. If you don’t properly configure your scans, you may miss vulnerabilities and have a false sense of security.
Additionally, since the application is scanned towards the end of the SDLC, there’s more pressure on development teams to remediate the difficult-to-find vulnerabilities quickly. This is usually where friction between development and security increases, often resulting in unmitigated risk.
How does Static Analysis work?
Static application security testing (SAST) is an AppSec assessment that tests applications from the inside-out, by scanning applications, but not running them. It usually targets source code, byte code, and binary code, and “sits” in an earlier stage of the SDLC so developers can look for security issues before the application is complete. SAST also provides real-time security feedback during coding, making it a more proactive method for fixing flaws quickly. This “inside-out approach” can help reduce security technical debt for the lowest cost.
On the flip side, fixing all the flaws found after a SAST scan may be an inefficient use of resources that may not reduce your risk in a meaningful way. And since the scan doesn't execute in a running environment, it can be hard to determine which flaws are immediately exploitable, or to understand how the exploit might happen without appropriate training.
Software Composition Analysis
Getting features to market faster than the competition almost always requires development teams to use at least one open-source library in their codebase. Third-party code is a necessity in modern software development and so is securing it. According to Veracode’s State of Software Security: Open-Source Edition, 97.4 percent of the 85,000 apps scanned had an unfixed security flaw in an external library. The good news is that nearly 75 percent of the known flaws can be fixed with a version update. Veracode Software Composition Analysis (SCA) and other similar solutions automatically scan your libraries and their dependencies to find vulnerabilities and help you fix them.
Defense in depth
If you conduct only SCA you’re not protecting your entire codebase. If you conduct just SAST, you may introduce resource-related inefficiencies into the SDLC during remediation. If you conduct only MPT or DAST, you’re finding flaws at a later, more expensive stage and putting increased pressure on development teams to find the flaw in the source code and remediate it quickly.
To ensure that you get the most value out of your AppSec program, you should use DAST findings to configure SAST policies, and to inform SAST activities. A quick defense against something like an input/output validation problem found during a Veracode Dynamic Analysis scan is to implement a WAF rule that prevents unauthorized data from leaving the application. Once the vulnerability has been secured at that level, use Veracode Static Analysis to go deep into the source code to find and patch the flaw. Once the first-party code has been secured, integrate Veracode SCA into your development workflows to secure your third-party code. This ensures that you are not just relying on one control to prevent an attack.
On top of this, it is critical to continue running MPT assessments to secure the flaws that automation can’t find. You want to look at the hierarchies of the architecture to be sure that you are doing everything you can to secure each level. This complementary approach makes it easier to find exploitable flaws, remediate them quickly, and even learn secure coding to prevent them in future. According to the 11th edition of the State of Software Security report, organizations that scan with both SAST and DAST are likely to remediate 50 percent of their flaws 24.5 days quicker than if they only scanned with one technology. It’s not hard to understand why: by seeing how an attack may be exploited at runtime, developers get an education in how to think like an attacker and may even be more motivated to fix other findings.
In today’s expanding threat landscape, DAST, SAST, SCA, and MPT provide a means for DevSecOps teams to secure their code and strengthen their AppSec programs before it’s too late. To learn more about the strengths and weaknesses of the different types of application security technologies, check out our Guide to AppSec Solutions.