For the last 15 years, researchers have produced an annual State of Application Security report. But in the last 18 pandemic driven months, they told SecurityWeek, “the world has turned on its head.” Both application development and use, and subsequent software compromises have grown dramatically.
“We decided to add monthly snapshots to provide more immediate relevance,” Setu Kulkarni, VP of corporate strategy at NTT Application Security told SecurityWeek, “while still being able to compile the data into our major annual report at the end of the year.
This month’s Appsec Stats Flash from NTT highlights three primary application statistics. The remediation of application vulnerabilities is declining (down from 54 percent at the beginning of the year to 48 percent now); the time it takes to fix critical vulnerabilities is growing (up from 197 days at the beginning of the year to 202 days now); and, consequently, the window of exposure (or opportunity) available to hackers is expanding. When these details are combined with no change to the type of vulnerabilities that continue to be prevalent, the result is that hackers know exactly where to focus their attacks, and they have more time to do so.
NTT does not separate issues into development and use, but rather examines the entire lifecycle of the application. It does this by scanning hundreds of thousands of applications daily. By comparing the results over time, it knows how long the vulnerability exists. When it no longer finds the vulnerability, it knows it has been fixed – but it doesn’t know whether the fix is from a developer patch or user remediation such as a new firewall rule. But the result is the same: application vulnerabilities are available online for increasing periods.
The cause, Kulkarni suggests, is a combination of factors. The pandemic and the consequent shift in working practices has increased the demand for new applications. The software industry has responded, with new applications or new versions of existing applications being released at a fast pace. But business pressures take precedence over secure development.
“Should we put out more features faster, or should we go for quality code ahead of features?” he asks. Because of business pressure, features get prioritized over quality and security during development; and the time to fix a quality or security issue becomes lengthy once the application reaches production. “The time to fix a critical security issue is almost 200 days,” continued Kulkarni. “And there is little or no prioritization in the way security issues are handled – so only around 50 percent ever get addressed. Organizations are struggling to keep pace with the business demand for more features and more applications at a more rapid pace. Alongside that, critical vulnerabilities found in apps take a long time to fix because there are not enough resources, and there’s poor prioritization. Only 50 percent ever get fixed. These issues combine to produce the very high window of exposure we see today.”
There is no single or simple solution to this problem. Developers need to improve their security by design, but have little incentive to do so while faced with the business pressure to increase the speed of development. At the same time, users are faced with what Kulkarni calls ‘the tsunami of the past’ – the hundreds of thousands of vulnerable apps already in use.
He believes the best hope lies in a two-pronged approach: legal enforcement from the lawmakers and old-fashioned market pressure from the users. The problem with existing data protection legislation is that it calls for ‘security by design’, but does not enforce it. Compliance enforcement is currently one sided, being levelled against the user company that falls foul of the vulnerabilities.
“Consider the recent presidential Executive Order,” says Kulkarni. “It includes a lot of prescription, but in my mind falls short by not including a penalty framework that software developers would be subject to. Secure by design only makes sense when the designers and developers are working on the software. That’s what we need to start focusing on – on making sure that there’s good product management oversight, there’s good threat modeling in place, there’s good static analysis and secure design practices implemented in the earliest stages of the software life cycle.” That requires some form of legal sanction to counterbalance the business pressures.
Even with new sanctions against insecure software development, this does not help with the ‘tsunami of the past’. “The other end of the spectrum,” he continued, “is the hundreds of millions of end users. I foresee a future scenario where there will be a groundswell of user opinion against a particular app and its developer when there are enough breaches. At the end of the day, if the end users stop voting for the software with their dollars, therein lies the biggest penalty for the software companies. So, software companies are walking a very thin line – it’s just a question of a critical mass of end users banding together and starting a viral movement against a particular application. That’s the biggest form of penalty and would be a day of reckoning for the software industry.”
History, however, provides little optimism. The security industry is massive, and the government has not been inclined to introduce sanctions that might lessen its competitiveness against other nations. Similarly, there are many app developers that have suffered repeated breaches, yet remain popular. For the most part, the end user seems to prefer the risk, provided it comes with low cost and extra features – both of which are provided by rapid and potentially insecure development.
Related: NTT Acquires WhiteHat Security