And the situation is made worse because many components have third-party sub-components. So, when developers import a particular component into their applications they automatically get its dependencies as well, which could have their own flaws.
Once a vulnerability makes its way into an application through a component dependency, chances are high that it will stay there for a very long time, possibly forever.
In an analysis done last year, Sonatype found that open-source component developers fixed flaws in their direct dependencies only in 41 percent of cases and even then, their mean time-to-repair was 390 days.
The good news is that the software industry does not have to reinvent the wheel and can borrow supply chain practices from other industries. But automation is key, because it is impossible for companies to manually review the components used by their developers and enforce to safely use policies given the level of third-party code consumption seen today.
There are specialized products that can be used to create bills of materials for software, that can restrict which specific versions of components developers in an organization are allowed to use and from which specific suppliers, as some are better than others at fixing flaws in their components.
A few years ago the amount of open-source code used in software development was low, especially in the financial services or government sectors where there were concerns about its provenance and licensing, Corman said. That is no longer the case and today ninety percent or more of any modern application, commercial or not, is composed of third-party code, the bulk of which is open-source, he said.
The behavior around the software supply chain needs to change in order to meet the velocity of third-party code consumption, said Derek Weeks, vice-president and DevOps advocate at Sonatype. "Relying on open-source allows developers to deliver software to market today faster than ever before, so we're not going to go back in time and start using less of it."
When choosing a component version developers often do not consider the security implications, but make a choice based on what they know has worked for them in the past. In addition to security fixes, new component versions might contain changes in functionality that could impact the applications they are being used in, so it is no wonder that software developers are reluctant to update them. But that way of thinking needs to change, especially at the organization level, according to Corman and Weeks. Being restrictive about which components can be used across all of an organization's software projects leads to less complexity too and saves money.
Corman, who is also co-founder of I Am the Cavalry, a group of security researchers who advocate for the secure development of software used in medical devices, automobiles, home electronics and public infrastructure, sees the current state of software hygiene as a public health issue.
Sign up for CIO Asia eNewsletters.