Individual accounts, missing naming standards, and legacy – Linux Foundation’s recipe for security disaster

Individual accounts, missing naming standards, and legacy – Linux Foundation’s recipe for security disaster

The Linux Foundation has, together with Harvard’s Lab for Innovation Science, released its second go at a FOSS census, attempting to identify the most used open source components and their potential vulnerabilities.

The preliminary report titled “Vulnerabilities at the core” is a product of the foundation’s Core Infrastructure Initiative, which was started in 2014 in the wake of an OpenSSL security bug, which had an impact on about half a million secure web servers. Members of the CII now provide funding and support for critical open source infrastructure projects in the hopes of preventing a rerun of the so-called Heartbleed vulnerability.

A first census to find the Debian Linux software packages most critical to the kernel’s operation and security was held in 2015. However, the project failed to look into what was most deployed in production applications, which is why the now available Census II was held.

According to private usage data contributed to the Linux Foundation by Software Composition Analysis and applications security companies like Snyk and Synopsys, the projects most used in production are FasterXML’s jackson-core and jackson-databind, guava, Apache’s commons-codec and commons-lang, commons-io, httpcomponents-client, httpcomponents-core, logback-core, and slf4j. The most used JavaScript packages are async, inherits, isarray, kind-of, lodash, minimist, natives, qs, readable-stream, and string_decoder.

Apart from identifying those critical packages, the CII formulated three key takeaways for the open source community, which should serve as a starting point for further investigations. The first is a “critical need for a standardized software component naming schema”. This seems to be a problem other organisations struggle with as well, which is why the CII states that “until one exists, strategies for software security, transparency, and more will have limited effect.”

Another challenge to the security of an open source project seems to be individual developer accounts. “Of the top ten most-used software packages in our analysis, the CII team found that seven were hosted under individual developer accounts.” 

Risks associated with this fact range from malicious developer account takeovers to the consequences of devs deciding to make their repos private or deleting them all together. Something along those lines only happened last autumn, when DevOps guru Seth Vargo took some Ruby Gems offline to show his disapproval of Chef’s business practices.

The third and final observation is that not only big enterprises struggle with old tech. Even though it might seem sensible to keep hands off anything established and working, this behaviour might lead to some serious problems. “The number of developers working to ensure updates—including feature improvements, as well as security and stability updates—decreases over time. Often those developers instead choose to dedicate their time and talents to newer packages. As a consequence, those legacy software packages become more likely to break with each passing day without the guarantee of support on-hand to provide fixes.” The impact multiplies, when enterprises fail to jump on newer versions or technology, simply because the immediate benefits are unclear and switching needs resources.

Coming up, the CII plans to launch a survey “to better understand the communities building and maintaining this critical information infrastructure”. It will “explore the intersection of time spent on FOSS development and employment”, which can be seen as an attempt to further dispel the notion of solitary devs maintaining critical packages without compensation (who are out there, don’t kid yourself). 

“By asking deeper questions about time allocation and employer policies toward open source, this endeavor aims to clarify the often blurry lines between direct and indirect support of FOSS projects in the private sector, as well as the sustainability of the FOSS ecosystem.” We’ll see how that goes.