Secure development: Bringing security testing into your SDLC

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 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 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. It takes some tuning and manual oversight, due to the possible high false positive rate and event fatigue it can cause.

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. Takes teamwork and collaboration to identify what needs to be fixed, as the outputs won’t provide this level of internal system information.

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

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 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 it can take action on any behaviors 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. It often takes the form of a security detection and prevention tool that can help you improve your security software testing practices.

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.

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’s Secure Development program. We offer courses and content across a range of 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.

Want to know more?

Are you ready to weave secure development into your work? Get started with SafeStack’s training for free.