The Trouble with Free and Open Source Software
Insecure developer accounts, legacy software, and nonstandard naming schemes are major problems, Linux Foundation and Harvard study concludes.
February 18, 2020
A wide-ranging study by researchers at the Linux Foundation and the Laboratory for Innovation Science at Harvard has yielded vital new information on the most widely used free and open source software (FOSS) within enterprises — and potential security risks related to that use.
The researchers found that a lack of a standardized naming scheme for FOSS components has made it hard for organizations and other stakeholders to quickly and precisely identify questionable or vulnerable components.
They also discovered that accounts belonging to developers contributing most actively to some of the most widely deployed open source software need to be secured much better. A third finding was that legacy packages within the open source space are becoming riskier by the day, just like any other older hardware or software technology.
"FOSS components underpin nearly all other software out there — both open and proprietary — but we know so little about which ones might be the most widely used and most vulnerable," says Frank Nagle, professor at Harvard Business School and co-author of the report. "Given the estimated economic impact of FOSS, far too little attention is paid to systematic efforts to support and maintain this core infrastructure," he says.
For the study, the researchers from the Linux Foundation and Harvard analyzed enterprise software usage data provided by, among others, software composition analysis firms and application security companies such as Snyk and the Synopsys Cybersecurity Research Center. In trying to identify the most widely used open source software, the researchers considered all of the dependencies that might exist between a FOSS package or component and other enterprise applications and systems.
The goal was to identify and measure how widely used FOSS is within enterprise environments and to understand the security and other implications of using the software. FOSS components constitute between 80% and 90% of almost any application in use currently within enterprises. While many FOSS projects have received considerable security scrutiny, many others have not.
Vulnerabilities in widely used projects with smaller contributor bases, like OpenSSL, can often slip by unnoticed, the researchers said in a report released this week. The heavy and growing reliance on FOSS has prompted efforts by governments, researchers, and organizations to better understand the provenance and security of open source software via audits, bug bounty programs, hackathons and conferences. "The first step is to truly understand the FOSS components upon which organizations depend — whether it be through regular security scans and code audits or by adopting a software bill of materials for all of its digital products," Nagle says.
Top Projects & Top Risks
The joint research by the Linux Foundation and the Laboratory for Innovation Science at Harvard showed that the 10 most-used FOSS packages within enterprises are async, inherits, isarray, kindof, lodash, minimist, natives, qs, readable-stream, and string-decoder. The researchers also identified the top most-used non-JavaScript packages, which include com.fasterxml.jackson.core:jackson-core, com.fasterxml.jackson.core:Jackson-databind, com.google.guava:guava, and commons-codec.
After identifying the top projects, the researchers set about trying to find out whom the most active contributors to these projects were and identified company affiliations for about 75% of them. During the study, the researchers found that seven of the top most-used open source software projects were hosted on individual developer accounts with fewer protections than organizational accounts. "Changes to code under the control of these individual developer accounts are significantly easier to make, and to make without detection," the report warned.
According to the researchers, attacks on individual developer accounts are increasing, and there's a growing risk of account takeovers and of backdoors and other malicious code being installed on them that can later be used to access the code. "One option is for such individual accounts to implement two-factor authentication if their repository supports it," Nagle says.
Another risk in having widely used FOSS sitting on individual accounts is developers who might decide to delete their accounts or remove code over disputes and disagreements. "A broader and longer-term solution would be for such projects to move to organizational accounts, rather than individual accounts, to help enhance the accountability and future availability of the projects," Nagle notes.
The research showed the need for better naming conventions for FOSS components. Because FOSS can be freely modified and copied, it can exist in multiple versions, forks, and similarly named repositories, Nagle says. To ensure better security, it is important to have a common understanding of which instance of a FOSS component is being used and how well it is being supported and maintained.
Another discovery the researchers made was that older, legacy open source components present the same risks as older, non-supported versions of any software or hardware. As one example, Nagle pointed to version 0.70 of the frequently used PuTTY SSH software, which was released in July 2017. No updates for the software were released until version 0.71 was released nearly two years later, in March 2019. "The infrequency of updates and examination [of] such highly used software can lead to security issues existing in the code base for more than 20 years," he says.
Related Content:
Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "8 Things Users Do That Make Security Pros Miserable."
About the Author
You May Also Like
Transform Your Security Operations And Move Beyond Legacy SIEM
Nov 6, 2024Unleashing AI to Assess Cyber Security Risk
Nov 12, 2024Securing Tomorrow, Today: How to Navigate Zero Trust
Nov 13, 2024The State of Attack Surface Management (ASM), Featuring Forrester
Nov 15, 2024Applying the Principle of Least Privilege to the Cloud
Nov 18, 2024