How to bring security testing into your software development lifecycle
In our recent post about secure design, we wrote about the secure development lifecycle (SDLC) and the different components that make it up.
Security testing is one of those components. Our COO Erica and Principal Developer Advocate Christian run through some common security testing methodologies below — join us to learn what they are and how they can be most helpful.
Beyond penetration testing
While penetration testing is one of the more well-known types, security testing goes far beyond this one option. Some organizations might even align their SDLC with a software testing lifecycle, or STLC, a framework to make sure the testing you perform meets your quality standards.
Whichever framework you use, including security testing, is a great way to get your whole development team thinking about and contributing to security. There are multiple types of security testing you can consider, and each type has different methodologies or ways you can perform them. Don’t worry — if this all feels like a lot, you can check out our Security Fundamentals for Software Testing course, which goes into much more detail on this topic.
Some testing methodologies come up a lot when we talk about secure software development, and we see those methodologies take the form of one of our favorite things in tech: acronyms!
Some you may come across include the following.
Static application security testing, or SAST
Dynamic application security testing, or DAST
Interactive application security testing, or IAST
Runtime application security protection, or RASP
Software composition analysis, or SCA
We tend to group these methodologies under vulnerability testing, as each has its way (or method) of finding weaknesses. Let’s look at the differences between them.
What is Static application security testing, or SAST?
Static application security testing, or SAST, does what it says on the tin: it uses static analysis to find vulnerabilities in our source code. It's also known as white box testing, which means you test your system from the inside rather than trying to test from an external or outside perspective. This also means you don’t have to have a running system to perform this type of testing.
The great thing about SAST is you can use it at much earlier stages of your development lifecycle, and it often takes the form of a plugin or add-on in your Integrated Development Environment (IDE) or development pipeline.
The downside of SAST is that there's often a high false positive rate, and the outputs can take some time to work through. These plugins and add-ons tend to be very sensitive, and trigger events that *might* be vulnerabilities — which requires the development team to do some investigation. This is expected when testing is done at the most granular level of your system, as it doesn’t have any context of the broader system architecture. Here's a summary of SAST.
What does it do? Looks at your system from the inside, at the source code level.
When does it occur during your development lifecycle? It is helpful at the implementation phase of your lifecycle and is integrated in your IDE and pipeline tools.
Tips from SafeStack. It takes some tuning and manual oversight due to the possible high false positive rate and event fatigue it can cause.
What is Dynamic application security testing, or DAST?
On the other end of the spectrum static is dynamic.DAST is a type of black box testing, where you test a running system from the outside. This means that the iteration you're working on needs to be deployed, integrated, and running in order to perform this testing.
On the upside, DAST tells you about weaknesses that can be found by outsiders — which are often the security weaknesses you need to be most aware of.
Without DAST, these findings would often come up as part of any testing that external parties might perform — like a bug bounty researcher, external security consultant, or a not-so-friendly attacker.DAST is not without its downsides, though. Outputs from DAST are often focused on the issue itself. Since DAST doesn't scan your internal source code — concentrate instead on what's visible from the outside — interpreting events may require help from a security-focused person on your team so you can understand what needs to change in the code to prevent this issue. Here's a summary of DAST.
What does it do? Look at your system from the outside, at the running system.
When does it occur during your development lifecycle? Helpful at the testing and integration phase of your lifecycle, when the component you have developed is now a part of the system.
Tips from SafeStack. It takes teamwork and collaboration to identify what needs to be fixed, as the outputs won’t provide this level of internal system information.
What is Interactive application security testing, or IAST?
The interactive method is a little bit of column A (SAST) and a little bit of column B (DAST).
While it tests from inside the system, the tests it runs mimic that of a human tester and interact with the system. This means it can find more valuable weaknesses in your system, and tell you where in your source code you need to fix it.
This testing often relies on agents or sensors deployed to your testing environment, which means it can continuously detect weaknesses. It can be a bit more complex to set up, and not every tool will suit every technology stack. Finding and implementing the right tool to perform IAST can take some time, and this is still a new and evolving testing method. Here's a summary of IAST.
What does it do? Looks at your system from the inside by interacting with it.
When does it occur during your development lifecycle? Helpful at the testing and integration phase of your lifecycle as part of other software or functional testing.
Tips from SafeStack. Takes time to identify the right tool for this testing method, and requires a more mature testing environment and setup.
What is Runtime application security protection, or RASP?
Last but not least is the runtime application self-protection or RASP. While IAST is pretty new itself, RASP is the even newer kid on the block. RASP is arguably less of a testing method and more of a security detection and prevention tool, as it monitors the system in real time. It's still worth mentioning as a method. However — because this testing is just being performed by an outsider to the organization (an attacker) and is being detected by a different tool (a tool with RASP features).
The outputs from RASP can help you strengthen your security software testing practices by pointing out gaps that weren’t already picked up as part of your SAST, DAST, or IAST.
The benefit of RASP is that it can take action on any behaviors it detects as malicious. The action it can take varies depending on how you configure it and could include stopping the user-initiated action or terminating the user’s session. While this can be a nifty and helpful tool, it can be complex to set up and manage and should by no means be the only tool you have for vulnerability detection. Here's a summary of RASP.
What does it do? It looks at how the system is used in runtime and prevents malicious actions.
When does it occur during your development lifecycle? It is helpful during the maintenance phase, as it happens in real-time as the system runs.
Tips from SafeStack. It often takes the form of a security detection and prevention tool that can help you improve your security software testing practices.
What is Software composition analysis, or SCA?
When it comes to vulnerability scanning, you need to check not just your software but also the software you rely on from others.
Many of the systems we build nowadays are made up of open source software. Sometimes the chain of dependencies can extend quite far, where even your open source software depends on other open source software. It's like software development inception.
This is where software composition analysis (SCA) comes into play. SCA testing scans for vulnerabilities in the open-source software your system relies on. As part of its 2020 Octoverse report, GitHub found that using automation (like their SCA tool, Dependabot) helps teams patch vulnerabilities in their open-source dependencies 1.4 times faster than teams that don’t use these tools. And when those vulnerabilities sometimes take more than four years to detect and be patched, your team will want any help to close those gaps. Here's a summary of SCA.
What does it do? Identifies vulnerabilities in open-source software that your system depends on or uses.
When does it occur during your development lifecycle? Helpful from the implementation phase to the maintenance phase of your lifecycle, integrated as part of your IDE and pipeline tools.
Learn more about security software testing.
As you can tell from this post, there's no one perfect testing methodology — they each have their benefits and limitations. A good security testing function will incorporate different methods throughout the testing or development lifecycle.
If you and your team want to learn more about these testing methodologies, check out SafeStack's Secure Development program. We offer courses and content across various topics — including software testing — with new courses released every quarter. We also have new seminars each month, including a few in our recorded seminar catalogue where we dive into detail on topics like SAST.