By The SafeStack Team • November 22, 2021

Secure development: Bringing security testing into your SDLC

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 of testing, security testing goes far beyond this one option.

Some organisations might even align their SDLC with a software testing lifecycle, or STLC, which is a framework to make sure the testing you perform meets your quality standards.

Diagram showing how the SDLC and STLC relate to each other

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.

There are some testing methodologies that come up a lot when we talk about secure software development, and we see those methodologies take the form of one of our favourite 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 of them has its own way (or method) of finding weaknesses.

Let’s look at the differences between them.

Testing methodologies: Static

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 there's often a high false positive rate and the outputs can take a bit of 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 to be expected when testing is done at the most granular level of your system, as it doesn’t have any context of the wider 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? Helpful at the implementation phase of your lifecycle, and is integrated in your IDE and pipeline tools.
  • Tips from SafeStack Academy. It takes some tuning and manual oversight, due to the possible high false positive rate and event fatigue it can cause.

Graphic describing what SAST is and when to use it

Testing methodologies: Dynamic

On the other end of the spectrum from 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 do any scanning of your internal source code — focusing 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? Looks 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 Academy. Takes teamwork and collaboration to identify what needs to be fixed, as the outputs won’t provide this level of internal system information.

Graphic describing what DAST is and when to use it

Testing methodologies: Interactive

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 that are 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 is going to 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 method of testing.

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 Academy. Takes time to identify the right tool to use for this method of testing, and requires a more mature testing environment and setup.

Graphic describing what IAST is and when to use it

Testing methodologies: Runtime

Last but not least is 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, though — because this testing is just being performed by an outsider to the organisation (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 it can take action on any behaviours it detects as being 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? Looks at how the system is used in runtime and prevents actions that are malicious.
  • When does it occur during your development lifecycle? Helpful during the maintenance phase, as it happens in real time as the system runs.
  • Tips from SafeStack Academy. It often takes the form of a security detection and prevention tool that can help you improve your security software testing practices.

Graphic describing what RASP is and when to use it

Testing methodologies: Composition

When it comes to vulnerability scanning, you need to be sure to check not just your own 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 kinds of tools. And when those vulnerabilities sometimes take more than four years to detect and be patched, your team will want any help they can get 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 through to the maintenance phase of your lifecycle, integrated as part of your IDE and pipeline tools.

Graphic describing what SCA is and when to use it

Learn more about security software testing

As you can tell from this post, there's no one perfect testing methodology — they each have their own 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 Academy’s Secure Development programme. We offer courses and content across a range of topics — including software testing — with new courses released every quarter.

SafeStack Academy Secure Development Free Trial CTA

We also have new seminars each month, including a few in our recorded seminar catalogue where we dive into detail on topics like SAST.

We love to hear from you

If you enjoyed reading this blog post or if something sparked an interest, please share it with us. Drop us a line at and let us know what you think.