Security

Why developers run away from security updates

Monday, April 16, 2018

Stunning revelations from Veracode's newest data that suggests nearly 3 out of every 4 developers do not test their open source application components for vulnerabilities before they launch their platform, plus they don't update code when security patches are released later.

Veracode, Inc. has released new data that shines a light on the discrepancy between component security and hygiene. According to the research conducted with Vanson Bourne, only 52 percent of developers using commercial or open source components in their applications update those components when a new security vulnerability is announced. This highlights organizations’ lack of security awareness and puts organizations at risk of a breach.

Software development processes like DevSecOps have helped improve the security of the code developers write. However, these same development processes value speed and efficiency to keep up with the demands of the application economy. As a result, developers rely on components that borrow features and functionality from existing projects and libraries. The research shows that 83 percent of respondents use either or both commercial and open source components, with an average of 73 components being used per application.

While components boost developers’ efficiency, and their use is considered a best practice, these components come with inherent security risks. Despite finding an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent of respondents reported testing for vulnerabilities in components at every release. This may be a result of only 71 percent of organizations reporting to having a formal application security (AppSec) program in place.

What’s more, only 53 percent of organizations keep an inventory of all components in their applications. According to The State of Software Security Report 2017 (SOSS), fewer than 28 percent of companies conduct regular composition analysis to understand which components are built into their applications.

“We know that developers care about creating great code, and that means creating secure code,” said Pete Chestna, director of developer engagement, CA Veracode. “In order to be successful, developers need to have clarity on the security policy and the tools to measure against it. When the goal is clear and we give developers access to those tools, they are able to integrate scanning earlier into the SDLC and make informed decisions that take security into consideration. Through this, we see a marked improvement in secure software development and the resulting outcomes.”

This report shows that development (44 percent) or security (31 percent) teams are most likely to be responsible for the maintenance of third-party commercial and open source components, which suggests a move towards responsibility for the development team. As awareness around open source risk continues to grow, providing developers with the solutions, education and visibility to mitigate risk becomes a critical component to the Modern Software Factory approach to development that helps to build better, more secure, apps faster.

We asked this question around ADM - because we are largely a group of developers.

Why do you think it's so hard to update code every time a new security patch is released in open source or by a 3rd party?

Ron Beaman says: "Because the 3rd party does not take enough care to maintain backward compatibility and there is not a compelling incentive for them to do as they aren't being compensated for their efforts. So as their needs evolve, their source code evolves and it doesn't matter to them if that breaks anything."

Michael Haynes says: "Could be a few of reasons. One, a company might not want to acknowledge they used open source software in their product, and updating would admit fault. Another, is more indicative for software in general. Updating means dragging out and dusting off build tools, and hoping what has already been built before can still be built even before inserting the patch. Also, in the case of Android, it means pushing and spending time applying the patch to specific pieces of hardware on already shipped devices, and might not be possible from a operating budget sense."

For me, I think it's just overall too difficult to keep up with the ongoing garage of security updates, unless it's a mission critical patch (which few are), I feel like they can wait. I usually stash them away until the next release of my software, where I can better pick and choose my battles.