Amit Ashbel, Cyber Security Evangelist at Checkmarx, discusses the state of testing within application security and the software development life cycle (SDLC).

Testing is an integral part of application security (AppSec) but according to the recent SANS State of Application Security report recently commissioned by Checkmarx, how organisations test is very diverse. The report identifies how organisations test, who is responsible for testing, what organisations are finding and how they are remediating those bugs and vulnerabilities. In this article, Amit Ashbel, cyber security evangelist at Checkmarx, delves into the findings and discusses how moving testing to a Secure Software Development Life Cycle is the best defence against today’s cyber attacker.

The application risk

The number of applications is increasing exponentially and while there are benefits to both consumers and business, each application represents a security threat, especially in today’s connected home and business. In today’s world of hackers stealing corporate and personal information, securing applications should be at the core of application development. Thankfully, according to the new SANS report on Application Security, 86% of respondents test their applications. But in order to secure all applications, some companies need to update their thinking around how they are testing.

The software development lifecycle (SDLC)

Currently, there is little regulation when it comes to writing code and in today’s competitive landscape, vendors are under pressure to get applications to market quickly which means a focus on how quickly developers can code rather than how securely. The regular software development lifecycle (SDLC) has 5 main stages: design, development (coding), testing, deployment and maintenance.

In many cases, developers write code which is passed to another team to check for security vulnerabilities very close to release times and often using black box methods such as pen-testing. Indeed, the SANS research claims that most of the testing is performed by the security department.

Tough decisions

Checking late means coders are under tight time constraints to fix any bugs or vulnerabilities. Because of this time constraint, the vendor often has to choose whether to fix bugs that could affect the user experience or vulnerabilities that could result in a data breach. Worryingly, the SANS report suggests that some vendors operating a continuous monitoring test schedule may not be testing at initial launch phase, choosing instead to patch later which could be too late.

Positive news

Good news from the SANS report was that vendors were finding fewer vulnerabilities than expected. The majority of respondents (57%) said that they found between one and 25 vulnerabilities per month while 12% found between 26 and 50 vulnerabilities per month. Meanwhile, 54% of respondents said that less than 10% of the vulnerabilities they found were critical or needed immediate patching. I hope this is because developers themselves are more aware of security during the coding process. However, these numbers might be a bit optimistic considering organizations use a variety of vulnerability detection techniques and rarely have a full application security program to achieve wide detection and coverage levels. You never know what was not detected until it might be too late.

Patch and repair

According to the SANS report, the speed of remediating vulnerabilities is less positive with less than 30% of respondents achieving between 75% and 99% satisfaction levels with the speed it takes to repair vulnerabilities and only 11% felt 100% 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, but, I’m encouraged that 51% of respondents said that they work to resolve the root cause of the vulnerabilities through secure SDLC practices.

The move to the secure-SDLC

A secure-SDLC is more time consuming than a quick and dirty software patch, which 50% of the respondents admitted to, but it’s a better long-term solution. Rather than waiting until the development process is finished to test for vulnerabilities, as in the regular SDLC, automated application security testing is integrated into the development process and provides constant feedback, transforming an SDLC into a secure-SDLC (sSDLC). Every change to the code is automatically analysed so developers are notified immediately about any vulnerabilities. This means developers are being educated as they code and are less likely to make the same mistakes again. So vendors stand a much better chance of preventing vulnerabilities that hackers can capitalise on both now and in the future. A secure-SDLC process is a much more cost and time effective approach as a long-term strategy.

With the reputational damage associated with data breaches, especially with those containing customer data, investing to get the code right at 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 its maximum for the purposes of securing that code and protecting both businesses and consumers alike.

Edited for web by Jordan Platt