application security testing

With around 85% of all cyber-attacks happening at the application layer, it’s clear that application security testing should be a serious priority for all organizations, big and small.

However, before we dive into effective application security testing, we should ask why application level attacks are so common?

Why Applications Are Hackers’ Attack Vector of Choice

Application level attacks are so popular with hackers as many organizations simply neglect application level security. This is due to the popular misconception that as long as you harden the network level of your system, by employing firewalls, antivirus protection, IDS/IPS solutions etc., there’s no need to worry about applications security.

Yet, as we can see from the above stat, this is unfortunately not true.

Application Security Testing Solutions and Stages

In order to drive down application security risk, there’s no single solution you can use.

Rather, you must use a blend of application security testing tools to ensure all code vulnerabilities are found and fixed. Furthermore, the solution you choose to secure your applications depends on the stage of the software development lifecycle (SDLC) you want to cover.

Tools to Cover the Development Stage of the SDLC

Static Application Security Testing tools (SAST) is your first stop along your application security testing journey.

Static Application Security Testing tools are all about identifying an application’s proprietary vulnerabilities. It does this by analyzing an application’s code for flaws which are indicative of security vulnerabilities.

As SAST analyzes an application’s code before compilation, these application security testing solutions are well suited for shifting left security. This means you can discover security vulnerabilities early in the SDLC, when they’re easier and cheaper to fix.

However, a drawback of SAST solutions is they only analyze applications in a static/non-running state. This means they can return a lot of false positives, as they identify vulnerabilities which wouldn’t be executed or exploited if the application was in operation.

Application Security Testing Tools for Pre-Release Stages

Unlike SAST testing tools, Dynamic Application Security Testing (DAST) solutions examine an application for security vulnerabilities while it’s running.

DAST solutions operate by simulating web attacks against an application. They then analyze the application’s reactions, thereby finding out if it’s vulnerable.

Although DAST solutions are great at finding run time issues and determining the probability of a vulnerability being exploited, they do have some negatives. In contrast to SAST, DAST is unable to locate the specific line of code where a vulnerability originates. Consequently, this (often time-consuming) task is left up to developers.

However, and perhaps most importantly, DAST application security testing tools need a complete and running application to operate. This means they’re only suitable for the later stages of the SDLC.

Then there’s Manual Penetration Testing (MPT). MPT basically allows you to dig deeper into vulnerable areas identified by DAST.

Both MPT and DAST probe an application, looking for potential weaknesses to exploit. But as MPT application security testing is performed by an actual human, it can detect business logic, design and compound flaws, as well as all standard vulnerability classes, which can only be detected via manual testing.

However, the effectiveness of MPT is dependent on the aptitude of the tester, and the time-frame and scope of testing. For example, if the tester is given a short window to test an entire application, they’re either going to have a to cut corners, or test effectively but only focus on a specific area.

Furthermore, just as with DAST tools, MPT can only be carried out once the application is up and running.

Download our free guide and see how we can help you secure your open source components

Tools for Post-Production 

Runtime Application Self-Protection (RASP) tools are the new kid on the application security testing block, and they’re causing a stir. This is because they protect applications when they’ve already been released.

RASP solutions allow applications to ‘self-protect’ by detecting and preventing real-time application attacks, all without any human intervention. Not only that, when an attack is prevented, the RASP application security testing solution can supply highly accurate data back to security personnel, helping them prevent future attacks. However, RASP solutions do have their limitations.

First of all, depending on how you configure your RASP solution, it can impact your application’s performance. Also, RASP application security testing tools can’t protect against all vulnerabilities, but rather the more generic forms of attack. More importantly however, RASP may protect applications from cyber-attacks, but it does not fix their underlying security issues. Therefore, it’s important to think of RASP tools as a shield, not a remedy, for application security vulnerabilities.

Security Tools to Use Continuously

A class of vulnerabilities that none of the above application security testing tools have covered is open source vulnerabilities. However, with open source making up 50-80% of modern applications, and over 4,000 vulnerabilities being reported every year, it’s essential for organizations to employ an effective open source security management solution.

Consequently, it’s important that your open source security solution can constantly monitor the many destinations where open source vulnerabilities are reported, and immediately alert your team when a vulnerability enters your SDLC, regardless of the stage. This could mean raising a flag when a vulnerable component enters one of your repositories or build, or when a vulnerability is detected for a component already in use, even if the application in which it’s contained is in post-production.

Additionally, some open source security solutions also allow users to define and automatically enforce their corporate open source policy throughout the SDLC. This means only components which adhere to an organization’s open source policy make their way into its products.

Ultimately, with a fully integrated and automated open source management solution, you can gain accuracy and control over your open source usage, without slowing down software development.

When it comes to Application Security Testing, You’ve Got to Start Somewhere

Ok, securing your applications can seem like a daunting task, but it doesn’t need to be.

An important thing to remember is that you don’t need to secure all your apps on day one. Instead, start with securing your most business-critical/attack-prone apps, then go from there.

Also, with the application security testing toolbox set out above, you can choose the right solution for each stage of your SDLC. This means you can find and fix a greater number of application security vulnerabilities, allowing your team to avoid last minute bug fixes which are not only costly, but risk delaying deployment.

If you’ve got any more application security testing tools in your arsenal, please share in the comments section below!