Take a look at the chart below. It’s the current number of software flaws in the US National Vulnerability Database (NVB) as of 09.00 GMT on 22nd November 2017. That’s important because the NVB is updated every hour. The total stands at 12,537. At the end of 2016, the total was 6,446 – slightly less than half of the current number of flaws with roughly six weeks left in the year.
These are the known software flaws that impact applications, platforms, operating systems, libraries and third-party components and create the gateways for malicious hackers to exploit. As is plain to see, the overall number of flaws is increasing on an absolute and a relative basis.
Focusing just on web applications shows the same trend. The latest view of how pervasive code flaws are in web applications comes from software analysis firm CAST which makes it clear why we continue to see an acceleration of successful attacks.
Which applications are the most vulnerable?
Out of 278 million lines of Java and .NET code CAST reviewed in 1380 applications, there were 1.3M vulnerabilities caused by errors and poor code practices. The worst offenders with the highest ratio of flaws to lines of code were financial institutions which are among the most attacked enterprises. Looking at which applications are the most vulnerable, .NET apps (surprisingly) had a higher average number of flaws than Java-based applications, which still had an unacceptably high rate of flaws – especially those under some form of continuous development.
These stats come at the same time when there is renewed discussion (debate is too strong a word) about where security teams should focus their efforts to protect applications: Only secure the code written by company/third-party developers or protect the entire application software stack? At the risk of a poor pun, this is not a binary decision.
Why should you protect the entire application stack?
The reality is, security teams can and should focus on the code they write. Reducing flaws should always be a developer’s goal and there are highly effective tools to help reach that objective.
However, the business logic layer accounts for only 10-20 percent of an app stack. Focusing protection only at the top of the stack, as some experts advise, leaves applications vulnerable to a host of attacks via flaws in the remaining 80-90 percent of the application. That’s where you find open source components, libraries, APIs, server operating systems, etc.
If you think these flaws can be ignored or won’t impact you, take a look at the vulnerabilities recently patched by Oracle, Microsoft, IBM and other OEMs. You’ll see high severity flaws in core products like the Java Virtual Machine or Windows Server being found and fixed, sometimes after years of going unexploited. Those flaws are not in the business logic layer of apps and neither are the flaws found in the third-party components and libraries like the Struts 2 framework.
What is the best way to secure the entire application stack?
Scanning and monitoring tools can help find vulnerabilities, but they can’t mitigate flaws. Traditional approaches to application security can only protect the business logic layer – and then only using heuristics to guess what is and is not an attack, often generating false positives and slowing app performance in the process.
Application security using a secure virtual container, however, offers highly accurate protection without requiring code changes or slowing an application with instruments or filters. And, your applications are actively protected against known and unknown flaws in the entire application stack – not just the code developed by your team.
That’s important because there is no 80/20 rule in application security. Your code is 100 percent protected or it’s not.
