Defense in Depth: Why You Need DAST, SAST, SCA, and Pen Testing

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.??

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.??

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.??

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 doesnt 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.?

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.???

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.?