Many commercial software companies and enterprise in-house developers are churning out applications that are insecure by design due to the rapid and often uncontrolled use of open-source components.
Even worse, these software makers wouldn’t be able to tell which of their applications are affected by a known component flaw even if they wanted to because of poor inventory practices.
Last year, large software and financial services companies downloaded 240,757 components on average from one of the largest public repositories of open-source Java components. Over 15,000 of those components, or 7.5 percent, had known vulnerabilities, according to Sonatype, the company that manages the repository.
Sonatype runs the hosting infrastructure for the repository, which is known as the Central Repository, but does not police what goes in and out. That falls with the community of open source developers who contribute components to it, every one being in charge of their own creations. The Central Repository is the default repository for Apache Maven, SBT and other Java software building tools.
A separate analysis of the top 100 components downloaded in 2014 by 29 large financial services and technology companies revealed that those companies used an average of 27 different versions of each component. This means that most of them were using outdated, less functional and potentially vulnerable component versions in their applications, Sonatype said Tuesday in a report about the state of the software supply chain.
In one case, developers working for a financial services firm had downloaded, over the course of the year, 51 of the 58 versions available for the Spring application framework.
This is indicative of the poor software inventory practices in most companies that develop applications for their own use or for others. The problem is not new, but Sonatype’s findings suggest that it’s getting worse as the level and velocity of open-source component consumption increases.
Overall, the Central Repository was used by over 100,000 organizations and served 17.2 billion download requests in 2014, a third more than last year. The repository hosts 217,000 components that combined have over 830,000 versions.
There’s a supply chain discipline to how companies from the various manufacturing industries source their components and track where they use them, that the software development industry has not yet embraced, said Joshua Corman, Sonatype’s CTO. Software development companies have had the luxury of not having to worry about that for a long time, but their increased dependence on third-party code combined with increased focus from attackers has generated significant risk for the software and infrastructure we’re all depending on, he said.
Sonatype has determined that over 6 percent of the download requests from the Central Repository in 2014 were for component versions that included known vulnerabilities and the company’s review of over 1,500 applications showed that by the time they were developed and released each of them had an average of 24 severe or critical flaws inherited from their components.
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’s impossible for companies to manually review the components used by their developers and enforce to safe 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’s 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 don’t 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’re being used in, so it’s 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.
“It is stunning to me that when you grab an application about a quarter of the components in it are vulnerable,” he said. “And that doesn’t even take into consideration the unknown, or zero-day, vulnerabilities.”
And that’s scary when we consider that the software being put into Internet-of-Things devices is no different than the one being put into commercial applications.
“I have encountered vulnerable open-source software in the remotely connected parts of automobiles that was exploitable and could put people’s lives in danger,” Corman said. “It’s one thing when your website is compromised, or you have to get a new credit card, and another when entirely avoidable vulnerabilities are making their way into embedded systems in vehicles or medical devices.”