The trouble with application security

Print Friendly, PDF & Email

In the wake of recent high-profile software supply chain breaches, there’s naturally a lot more focus on application security. However, as cybersecurity professionals know, concern doesn’t always equate to action. A survey of 480 IT security decision-makers published by Forrester Research finds only just over a quarter (28%) of respondents are making application security improvements a top tactical priority over the next 12 months.

Arguably, that lack of major focus can be attributed to who is accountable for application security. Many security teams have a tendency to reserve the budgets they control to secure infrastructure. The assumption is developers will take the necessary measures to secure applications. Unfortunately, that’s often not the case. A survey of 634 enterprise IT and security practitioners conducted by the Ponemom Institute on behalf of WhiteSource, a provider of tools for securing open-source software, finds nearly three-quarters of organizations (75%) report their applications portfolio has become more vulnerable to attacks over the past year.

More troubling still, another survey of nearly 200 security, application, and DevOps professionals conducted by Salt Security, a provider of tools for securing application programming interfaces (APIs), finds more than half of organizations running APIs in production (54%) have at best only a basic strategy for API security, with 27% having no strategy at all.

Finally, to add insult to injury it’s not uncommon for developers to push code with known vulnerabilities into production environments. A survey of 378 cybersecurity and application development professionals conducted by Enterprise Strategy Group (ESG) on behalf of Synopsys, a provider of tools for scanning application code for vulnerabilities, finds that nearly half (48%) of respondents admit they consciously push code with known vulnerabilities into production to meet an applications deadline.

A big part of the reason this situation persists is that the processes developers rely on to secure applications are largely manual. Three-quarters of respondents (75%) to a survey conducted by Security Compass, a provider of cybersecurity automation tools, said manual security and compliance processes slow down code releases in a way that ultimately delays time to market and overall competitiveness. When push comes to shove, one of the first things that gets tabled is application security.

In theory, the rise of best DevSecOps practices that shift responsibility for application security further left should reduce, or outright eliminate, the vulnerabilities that now routinely make it into production applications. Unfortunately, it’s still early days as far as DevSecOps is concerned so the impact this shift might have is at best limited, especially when you consider the level of security knowledge the average developer possesses.

Cybersecurity professionals know in their bones that developers are the root cause of most of the issues they face on a daily basis. It’s not that developers necessarily set out to build and deploy vulnerable applications. Rather, they simply don’t know what to look for. By the time the application is scanned, usually a few days before it’s supposed to be deployed, it’s too late to do much more than make a note of the security flaws that need to be addressed. Breaking that cycle will require cybersecurity teams to meaningfully engage developers much earlier in the application development lifecycle.

Developers, after all, are not likely to reach out first simply because they don’t really know what to do. Cybersecurity professionals will be waiting a long time for a call from a developer. That means it’s up to cybersecurity professionals to engage developers in a constructive way that makes them feel more educated rather than punished.

Organizations today are more dependent on software than ever. Regardless of security concerns, businesses are just going to keep building and deploying more applications to drive a multitude of digital business processes. The onus is now on cybersecurity teams to insert themselves into the front end of the processes employed to build those applications rather than waiting at the backend for an inevitable issue to arise. In fact, it’s arguable that cybersecurity professionals that don’t engage developers are just as big a part of the problem as the developers themselves.

Scroll to top