Tracey Schelmetic
Design News
Many software companies today, in a hurry to bring new products to market, rely heavily on open-source Java software components. Often, this means downloading open-source code from public repositories, where open-source developers share their components for others to use. One of the largest open-source repositories, the Central Repository, is managed by Sonatype, and that company has a message for software developers: Your open-source components may not be secure.
Last year alone, large software and financial services companies downloaded nearly a quarter-million components. According to Sonatype, about 15,000 of those components, or 7.5%, had known vulnerabilities.
Essentially, the software companies using these repositories without proper control procedures are building security and other flaws right into the solutions they're turning around and selling to customers. Picture that customer purchasing industrial control software (ICS) or supervisory control and data acquisition (SCADA) solutions and the scenario becomes a lot scarier.
 |
| Designers that poorly vet the open-source code they retrieve from open-source repositories and put to use in their products could spell trouble for their companies like the Heartbleed bug did. |
It gets worse, according to Sonatype: Many of the software companies that have built insecurities right into their products wouldn't be able to tell which of their applications are affected by a known component flaw because of poor inventory practices.
Companies that host open-source repositories like the Central Repository do not quality check the components that are uploaded; they simply host them. It's up to open-source developers to ensure that what they're offering is free from flaws. Failing that, it's up to software developers using the components to ensure they're solid.
According to Liam O'Murchu, senior security response researcher at Symantec, using open-source software is not risk-free, and developers need to take this into consideration when using it.
"There are a wide variety of vulnerabilities, and the exposure to these vulnerabilities depends on how the software is used," O'Murchu told Design News. "A recent high-profile vulnerability in open-source software was the Heartbleed vulnerability in OpenSSL. Heartbleed allowed attackers to take full control of machines where the vulnerable software was deployed. Other vulnerabilities could allow attackers to steal information, take control, or crash machines where the open-source software is deployed."
One solution might be to skip using open-source components altogether, but for many developers, this simply isn't practical. Some open-source elements are quite ubiquitous due to their usefulness, specialization, and the difficultly involved in rewriting them from scratch.
Competition in the software industry often means that delays in products or version updates are simply unacceptable. The onus then falls on software developers using open-source content to ensure that what they're putting into branded products is clean and free of vulnerabilities and that they have created easy and effective ways to notify customers if problems are identified.
"Developers need to be aware of what open-source software they've implemented and monitor those projects for notifications of vulnerabilities," O'Murchu told us. "They also need to have a plan in place to react to vulnerabilities found in these projects and deploy patches or updates."
Action plans are critical for ICS and SCADA makers in avoiding a repeat of Heartbleed, which affected solutions from high-profile companies that included Siemens and Innominate and led to a number of dangerous cyber attacks aimed at control systems, according to the ICS-CERT agency, part of the US Department of Homeland Security. When high-profile targets such as banks quickly patched the vulnerability, hackers turned to less obvious but equally tempting marks, and industrial systems remained vulnerable for weeks afterward.
