Web Application Security – Enterprises Are Losing the War
Download this white paper as a PDF
Enterprises tend to develop and secure their own applications in-house using agile methodologies
The survey clearly shows that the majority of large organizations develop their web applications in-house. This represents a major focus shift. In the past, enterprises were often unable to create their business applications on their own due to the diversity and complexity of development environments and IT systems in general. They hired external companies to do it for them. But web development is easy and web technologies meet many needs, which means that enterprises now have their own web developers and manage the development process efficiently. Software may be eating the world, but in a way, all companies are now software companies.
In a way, all companies are now software companies
However, at the same time the majority of large businesses still also work with third parties, which is understandable. Some web applications or even parts of web applications can easily be developed by external contractors – this is one of the great advantages of web technologies. Applications use common standards so they are integrated much easier than ever before.
88% of companies develop web applications in-house and therefore must secure them
At your company, how are web applications created and managed?
Major enterprises are no longer using mostly old-school development practices such as the waterfall methodology. Agile methodologies are used by almost every major organization now. However, waterfall is still used in approximately 40 percent of cases, depending on the project type.
What development methodologies does your company use for web applications?
Large organizations still don’t scan early enough and rely too much on security personnel
The shift to building applications mostly in-house and using modern development methodologies often introduces a major strain on large businesses. This causes many businesses to have less time for considering the security approach. Many still perceive security as either added-value or a separate issue altogether, not an integral part of the development cycle. Coupled with the increasing cybersecurity skill gap, this is the primary reason why the web security war is not even close to being over.
Typically, when does your company scan web applications for security vulnerabilities?
While approximately half the enterprises are successful with their shift-left efforts and include web application security scans with every code build or during unit testing, there is a staggering number of enterprises that actually scan the deployed applications, which is very late for a security scan.
While some of those approaches overlap and most security-conscious organizations perform security testing at several stages of the development process, some focus too much on the later stages. Most such late security scans are actually performed by security teams, not by the developers themselves.
Who runs the security scans during code development?
The fact that almost two-thirds of survey respondents have pipelines that include automated security scans is encouraging. However, the fact that the security team is burdened with running security scans just as frequently is not encouraging at all. With the shift left, organizations should free security personnel from the need of running basic security scans. It’s just a huge waste of such valuable resources. Freeing up security personnel through automation allows them to focus on activities that have higher value.
Nearly 64% of enterprises still burden specialized security personnel with simple web application security testing
Enterprises are either not able or not willing to secure all their web applications
If securing applications was easy, companies would certainly make sure that every single application is fully secure. Unfortunately, this is not so – for several reasons. While nearly 80 percent of enterprises perform some kind of security testing for all their web applications, the remaining 20 percent are not able or not willing to do so, taking a calculated risk and potentially leaving security holes wide open. And these security holes may bring dire consequences – several recent breaches have happened via low-value applications that might not have been secured well enough but have let the intruders proceed into critical systems.
Does your company run security scans consistently for all web applications?
While often the decision to skip scanning some web applications is voluntary, in many cases it’s not a matter of choice. Nearly 70 percent of companies don’t scan some applications simply because they don’t feel it’s worth it. However, at the same time, more than 60 percent report a lack of resources, which goes in line with the failed shift left and the reliance on security personnel.
However, the most worrying reasons for not scanning web applications are the limitations of tools. More than a third of companies report that tools are incapable of scanning all web applications. This is caused by the reliance on static application security testing (SAST) technologies, which are heavily dependent on programming languages and environments. This is also caused by the outdated perception that dynamic application security testing (DAST) tools are not meant to be used in the SDLC. This is not true – DAST tools work very well in the SDLC and, unlike SAST and SAST/IAST tools, they can scan every web application, no matter the technology.
Another worrying reason is that more than a third of companies believe that it takes too long to perform security scans. This, again, is due to the reliance on SAST and SAST/IAST tools that either need to deeply analyze the source code or embed agents into code, which affects application performance. Another reason might also be that many DAST tools are developed using ineffective technologies and perform security scans very slowly.
36% of major businesses use security testing tools that are inadequate for the job
Why does your company only scan a portion of its web applications?
Major businesses cannot cope with the influx of new security issues
The most worrying finding of the survey is the fact that half of the respondents believe that they are losing the war. They are seeing new security vulnerabilities appear faster than they can be fixed, which means that the backlog of issues grows and is not likely to ever be emptied.
At your company, are security vulnerabilities discovered faster than they can be fixed?
The primary reason for this is the fact that businesses still treat security as a silo. As long as security teams are separated from development teams, developers will never be able to truly learn how to write secure code. Businesses must not only shift their testing efforts left. They must also shift their prevention efforts left.
Businesses must not only shift their testing efforts left, they must also shift their prevention efforts left
The best way to combat the flow of new issues is to bake security into the entire business ecosystem. If, for example, every security team is tasked with assessing security at the planning and development stage, the number of new issues would be significantly lower.
The solution here is not to fix issues faster – the solution is to not have these issues at all. And it’s not difficult. For example, almost every programming language now includes constructs that completely prevent SQL injection vulnerabilities – all it takes is for the developer to use such constructs at all times. And high-quality DAST tools provide detailed reports that educate developers on such solutions.
And can issues be fixed faster? It seems that businesses don’t need too much time to fix issues and therefore the reasons for the growing backlog must be those stated above.
How long does it take to resolve a typical web application security issue?
The majority of enterprises are able to fix web application security issues within less than two business days. This, of course, does not include the waiting time that is associated with the development methodology. In an agile organization, a discovered issue is submitted to the backlog and then assigned to a sprint by the project manager. Therefore, the real time from issue discovery to resolution may exceed several weeks but the time needed for a developer to figure out how to fix the issue, test the fix, and close the issue, seems not to be excessive.
The amount of time and effort needed to handle issues is a strong argument for trying to avoid issues in the first place. If most security vulnerabilities are eliminated before they become issues, all of these delays are completely eliminated. And they can be eliminated if your AST tool lets you automate scans for all early builds (which is easy to achieve with a modern DAST solution).
If vulnerabilities are automatically discovered during the initial build, before new source code is added to the main repository – all issue-related delays are completely eliminated. If there is no issue, there is no need to prioritize it and manage its resolution process. Also, developers do not need to understand and correct mistakes made by others because the original developer cannot commit their code if it includes the mistake in the first place. This saves a lot of time.
