Summary
To deliver maximum value, SAST, DAST and SCA — three key types of security testing — should integrate seamlessly into the software delivery lifecycle (SDLC). Effective integration requires making strategic choices about when and how to perform different types of tests, as well as how to respond when a SAST, DAST or SCA test identifies a security risk.
If there’s one thing to know about modern application security, it’s that teams should adopt a multi-pronged approach to protecting applications. They need to test and scan for risks in multiple ways, since no single method can uncover all application security problems. – especially in the complex, microservices-based apps that are at the core of modern cloud-native strategies.
If there’s a second thing to know about modern AppSec, it’s that security processes should integrate seamlessly throughout the software delivery lifecycle (SDLC). Integrated security helps teams operate efficiently, while reducing the risk of delaying software releases due to security issues that engineers didn’t catch early enough.
But how, exactly, do you integrate multiple types of security tests into the SDLC in an efficient, scalable way? That’s where many teams run into challenges. It’s one thing to talk about multi-pronged, integrated security, and another to put it into practice.
To help businesses work through this challenge, this article explains how to incorporate three key types of security tests – SAST, DAST, and SCA – into the SDLC. You’ll learn about practical approaches for ensuring that you can run multiple types of tests without slowing down your software delivery operations.
Types of Application Security Testing
Let’s begin by defining what SAST, DAST and SCA mean.
SAST definition
SAST, short for Static Application Security Testing, is a software testing technique that scans source code to uncover risks. For example, SAST scanners can detect components of an application that may be vulnerable to code injection attacks.
Typically, SAST tests occur relatively early in the SDLC. This is often referred to as “Shift Left.” You can begin SAST scanning as soon as you have newly written source code within your Continuous Integration/Continuous Delivery (CI/CD) pipeline.
Explore Static Application Security in detail in our Appsec Executive Ultimate SAST Guide .
DAST definition
DAST, short for Dynamic Application Security Testing, is a testing technique that detects conditions indicative of a security vulnerability within an application in its running state. To perform DAST tests, teams deploy an application into a testing environment, then deploy a DAST testing tool that automatically interacts with the app in the same way that attackers might.
The purpose of DAST is to detect vulnerabilities that are not evident by scanning source code or binaries. For instance, DAST scans might reveal problems with an application’s authentication and authorization framework that allow non-privileged users to perform administrative actions. DAST tools can do this by attempting to make requests that should be available only to privileged users, and then evaluating how the application responds.
Because DAST testing requires an application to be running, DAST scans typically take place toward the midpoint of the SDLC – after an application release candidate has been developed and compiled, but before it’s deployed into production. However, automatic DAST testing makes it easier to test more frequently, and so find issues earlier in the development process.
SCA definition
SCA, short for Software Composition Analysis, is a type of security testing that checks for vulnerable third-party components or dependencies within an application. For example, if developers borrow open source code from an external repository, and that code contains known vulnerabilities, an SCA tool could flag them. SCA tests can also assist with open source licensing compliance by alerting teams to open source licenses that apply to their code.
Because SCA tools look for security issues associated with third-party software, they’re a type of software supply chain security solution. They won’t uncover vulnerabilities within code that your developers wrote themselves, but they will help surface risks in code that your developers obtained from external sources.
Most SCA tools can scan source code, as well as configuration files and some types of binaries. Thus, it’s possible to run SCA scans at various stages of the SDLC. You can scan newly written source code early in the SDLC, and you can also scan configuration files and binaries that appear later in the SDLC, when a release candidate is being staged for production.
SAST, DAST, and SCA application security testing tools: Better together
Because SAST, DAST, and SCA focus on different types of risks, each has a unique role to play in application security, and most organizations should adopt all three types of testing.
If you performed only SAST testing, you might not detect risks that would be evident only by simulating malicious interactions with an application using DAST.
Likewise, without SCA, you might miss important risks within your software supply chain.
In addition, some application security tools can take the vulnerabilities from the different tools and correlate threat data to better prioritize risk. For example, if an SCA tool detects a vulnerable open source component within an app, and a DAST tool is able to simulate a successful attack that exploits that vulnerability in a running application, you’d know that the vulnerability is exploitable within your particular app and is therefore a high-severity risk, and that your team should prioritize fixing it. In contrast, if a DAST tool can’t actually exploit a known vulnerability in an open source component, replacing or updating the component would not be a top priority.
Integrating SAST, DAST, and SCA into Software Delivery Pipeline
But again, exactly how to run all three types of tests – and how to integrate them into the SDLC in a coherent and efficient way – can be tough. There’s no one-size-fits-all solution; different teams will opt for different approaches depending on factors like how often they update code and which types of risks are most important for them.
That said, the following guidelines can help to integrate SAST, DAST, and SCA effectively into the SDLC.
Define a testing order
As a first step, decide the order in which you want to run SAST, DAST and SCA tests. Running them all in parallel is one approach, and it speeds up overall testing time. However, you may choose to run the tests serially by, for instance, completing SAST scanning before starting SCA, and then finally running DAST tests. This is advantageous because it allows you to start running some tests earlier in the software development lifecycle. DAST tests typically can’t happen until you have a fully running application, but you can perform SAST and SCA scans on individual units of code, even if your entire app is not yet complete and running However, when running all tests together, in tools such as Checkmarx One, you can take advantage of enhanced correlation and prioritization between risks.
Set a testing schedule
You should also decide how often you want to scan. In general, most teams perform a set of SAST, DAST, and SCA scans for each application release candidate. But you may want to run some or all of your tests more than once – especially if the initial round of testing results in code changes, which could introduce new risks into your app, making it important to scan them again before deeming them secure.
Decide how to scan
Modern, cloud-native applications are often developed as microservices, which means the codebase is broken into multiple components – one for each microservice. From a security testing and integration standpoint, this means there are two basic ways to go about testing. One is to test individual microservices, and the other is to test your application as a whole.
There are pros and cons to each approach. Testing individual microservices is more effort (because you have to orchestrate tests for each microservice individually), but it may also be more effective in the long run because you can more easily home in on security problems by identifying the specific microservice they affect. Testing the app as a whole is simpler, but testing results are not as granular.
Keep in mind, too, that you’ll probably want to test the entire app, since in some cases the way the app responds to malicious requests may hinge on how multiple microservices interact when handling a request. As a result, if you only test individual microservices, you may overlook certain risks.
The bottom line here is that you should evaluate your application architecture and devise a testing strategy optimized for it.
Handle test results effectively
Running security tests is only one part of the application testing process. You must also ensure that you can react effectively when scans reveal potential risks.
To that end, be sure that your developers are prepared to work with security analysts to interpret test results and identify the most efficient way to remediate issues. Scanning tools that offer remediation guidance or identify exploitable paths may also be able to accelerate the risk prioritization and remediation process.
Learn more about Secure Software Development Lifecycle implementation in our ultimate SDLC guide.
Integrated security scanning with Checkmarx
As a holistic enterprise application security platform, Checkmarx One delivers all of the capabilities teams need to integrate SAST, DAST, SCA, and more into the SDLC. No matter how or where you choose to run tests, the Checkmarx approach means that you can run tests in whichever way makes the most sense for your teams.