Skip to main content

The role of testing in securing applications

Adopting a DevOps culture is becoming increasingly discussed with a HP Enterprise report recently claiming that 99 per cent of operations professionals agreeing that it can improve application security but unfortunately the report also highlighted that only 20 per cent of respondents test during the development process. But testing is arguably the most important part of Application Security (AppSec) yet how organisations test various significantly from company to company. 

So how can we understand what's happening in the marketplace and what we need to do to create more secure applications? In this article, we look at the findings of the SANS State of Application Security report we recently commissioned and discuss the importance of moving testing to a Secure Software Development Life Cycle.

The technology-focused world of today

Due to the rise of mobile, and technological advances such as the Internet of Things (IoT), the number of applications being released and updated every day is increasing prolifically. While there are huge benefits to many of these applications - to both consumers and business, each application represents a security threat, especially given the connected nature of everything from appliances to applications today; bad code in a Smart TV could represent a threat to your laptop that you use for online banking simply because it's all connected on your home network. 

The same is true for businesses but on a far larger scale. In this, today's world of hackers stealing sensitive corporate and personal information, securing applications must be at the core of the development of all applications if we hope to have a chance of avoiding breaches. On a positive note, and in contrast to the HPE report, the SANS report on Application Security showed 86 per cent of respondents test their applications but in order to ensure that all applications are secure, some companies need to update their thinking around how they are testing. 

The Software Development Life Cycle (SDLC)

At the moment, there is very little in the way of regulation or industry standards when it comes to developing code. Meanwhile, in today's competitive landscape, vendors are under huge pressure to get applications and updated releases to market as quickly as possible which leads them to concentrate on how quickly developers can code rather than how securely. The regular process for the Software Development Life Cycle (SDLC) has 5 main stages: design, development (coding), testing, deployment and maintenance. 

Unfortunately, you can see that the testing stage is very late in this regular, widely-accepted process. In a lot of cases, code is written by the developers and then passed to another team, normally the IT or IT security team who then organises checking for security vulnerabilities very close to release times by using black box methods such as pen-testing. Indeed, SANS claim in their latest research, that most of the testing is performed by the security department with 62 per cent of respondents saying that internal teams were responsible for testing applications.

There's never enough time

Checking so late means that developers are then under very tight time constraints to re-code and fix any bugs or vulnerabilities because they are not as familiar with the code as they would have been when they first wrote it and because the process hasn't built in enough time for the developers to re-code effectively. 

Because there just isn't enough time, the vendor is often put in the tricky position of choosing whether to fix bugs that could affect the user experience or vulnerabilities that could potentially result in a data breach because there isn't time to do both. Unfortunately, the SANS report flags up that some vendors who are operating a continuous monitoring test schedule may not be testing at the initial launch phase but rather opting to patch bugs and vulnerabilities in later releases but of course, that could be too late.

What's being found during testing?

Despite the issues that remain with the testing process, some good news that came from the SANS report was that vendors were finding fewer vulnerabilities than they expected. The majority of respondents (57 per cent) said that they found between one and 25 vulnerabilities per month while 12 per cent found between 26 and 50 vulnerabilities per month. In more good news, 54 per cent of respondents said that less than 10 per cent of the vulnerabilities they found were critical and in need of immediate patching.

It is my hope that this is because developers themselves are becoming more aware of the need for security considerations during the coding process. But it's important to note that these numbers could be a bit optimistic considering the wide variety of vulnerability detection techniques organisations use and the fact that they rarely have a full application security program that achieves wide detection and coverage levels. With this in mind, some organisations simply never know what was not detected until it's potentially too late.

Time to repair

The speed at which vulnerabilities are being patched, according to the SANS report, was similar to last year with 26 per cent patched within 2-7 days and another 26 per cent patched within 8-30 days. But in terms of the speed of remediating these vulnerabilities, the news is less positive with less than 30 per cent of respondents achieving between 75 per cent and 99 per cent satisfaction levels with the speed it takes to repair their vulnerabilities and only 11 per cent felt 100 per cent satisfied. 

To me, this suggests that it would be better for the vendors to try to create code with less vulnerabilities in the first instance rather than patching later, and, I'm encouraged by the fact that 51 per cent of respondents said that they work to resolve the root cause of the vulnerabilities through secure SDLC practices. 

The benefits of moving to a Secure-SDLC

There is no doubt that a Secure-SDLC is more time consuming than a quick software patch which 50 per cent of the respondents admitted to but there's also no doubt that a Secure-SDLC is a better long-term solution. Instead of waiting until the development process is completed to test for bugs and vulnerabilities, organisations can deploy automated application security testing solutions whereby testing is integrated into the development process to provide constant feedback. 

This transforms an SDLC into a Secure-SDLC (sSDLC). During the testing process, each change to the code is automatically analysed so that developers are notified immediately about any vulnerabilities. In this way, developers are being educated while they code and as such are far less likely to make the same mistakes again. With more security-conscious developers at hand, vendors stand a much better chance of preventing vulnerabilities that hackers can capitalise on both now and in the future. As a long term strategy, a secure-SDLC process is a much more cost and time effective approach. 

Given the reputational damage associated with data breaches, especially those containing customer data, investing to get the code right from the start is the smart move. That raw source code is the one advantage every developer and vendor has over the hackers and this advantage should be leveraged to the maximum to protect both businesses and consumers alike. 

Amit Ashbel, cyber security evangelist at Checkmarx
Image Credit: IT Pro Portal