The Losing Battle: Code vs Flaws
The Losing Battle: Code vs Flaws
Developers are writing better quality code, but it still comes with a high number of security flaws. How can this be addressed? We take a look at one possible approach.
Join the DZone community and get the full member experience.Join For Free
Sensu is an open source monitoring event pipeline. Try it today.
Better Quality Code but With Security Flaws
“If debugging is the process of removing software bugs, then programming must be the process of putting them in.” – Edsger Dijkstra, winner of the 1972 Turing Award
There’s no news in the fact that modern software architecture is a mash-up of original and open source code pulled from libraries and repositories with a liberal amount of third-party code that comes in an OS or a JVM, for example. Mixed in with the good is the bad: Known and unknown vulnerabilities that one day could be the source of a newspaper headline with your name in it.
There is some actual news this week, though. Sonatype has published a report on the state of the software supply chain that shows the quality of software components is improving and number of known Java security flaws being passed around in open source downloads is holding steady – at slightly more than six percent.
The bad news is – and you knew there would be some – that six-plus percentage on a base of 31 BILLION downloads is about 2 billion downloads with a known defect. That’s a lot of bad code going into good apps. The report shows new vulnerabilities are uploaded into the 7,000 open source repositories in the study an average of once per day, with 70 percent of those sporting a Common Vulnerability Scoring System (CVSS) level of five (5) or higher.
Another finding from the report: Fixing code is expensive. That’s not new, but the calculator Sonatype has built offers a view into just how expensive it is. If a company with 2000 applications wants to fix just 10 percent of apps with vulnerable code, that would require $7.4 million on average. That’s money which would otherwise go to higher value activities and investments.
And then there is the issue of older components that are the software equivalent of “What happens in Vegas, stays in Vegas.” More than 10 percent of 1,000 repositories evaluated included components that had not been updated in five or more years. Good luck fixing a security flaw in code built with one of those components.
All of this reinforces the dynamic Gartner recently highlighted at the 2016 Risk & Security Management Summit. The number of vulnerabilities inherent in application code is so large that improving security by “just writing better code” is a fool’s errand. It is a worthy aspiration, but an unattainable goal.
Couple that with various statistics about the find-to-fix ratio of code flaws being at least 5:1 (and as high as 10:1), and you can quickly see that trying to plug all software security holes is a losing proposition.
Part of the solution – especially for older, out-of-date software and components – are emerging technologies like Runtime Application Self-Protection (RASP) via virtualization that offer protection for known and unknown security risks thanks to the way the RASP solution is structured. Using virtual patching and legacy Java protections, the need to “fix” code can be reserved for the highest priority risks on mission critical applications – the rest are protected by the RASP solution.
Once unthinkable, Gartner analyst Ramon Krikken noted at the 2016 Gartner Summit that larger organizations are increasingly using virtual patching for lower risk apps or flaws. “It makes good business sense” to virtually patch some applications rather than trying to rewrite the code on all flawed apps.
James E. Lee is Executive Vice President of US-based Waratek Inc. Contact James to learn more about RASP and application security trends at firstname.lastname@example.org
The image used in this report is courtesy of Sonatype.
Published at DZone with permission of James Lee . See the original article here.
Opinions expressed by DZone contributors are their own.