Free and Open Source Software (FOSS) has become a prominent aspect of the new age global economy. It has been analysed that FOSS makes up about 80-90% of any particular piece of today’s software. It is to be noted that software is an increasingly-critical resource in almost all businesses, both public and private. But, there are many issues with FOSS, according to the Linux Foundation.
The Linux Foundation established the Core Infrastructure Initiative (CII) in 2014 as a part of which its members gave funding and support for FOSS projects, which are important to worldwide data and information infrastructure. In 2015, CII finished the Census Project (“Census I”) to find out which software packages in the Debian Linux distribution had been the most important to the kernel’s overall security.
While the Census I project emphasised on analysing the Linux kernel distribution packages, it did not go deep into which software was utilised in production applications. That’s where Census II comes in.
In the middle of 2018, the Linux Foundation collaborated with the Laboratory for Innovation Science at Harvard University (LISH) with the objective of doing a second census to discover and analyse the extent to which open-source software is used within applications by private and public companies. This Census II thus gives a whole view of FOSS deployment by analysing usage data provided by the partner Software Composition Analysis (SCA) companies.
The Census II analysis and report from Linux Foundation published recently sheds light on the processes towards comprehending and solving structural and security complexities in the present-day supply chain in areas where open-source is present.
Analysing The Long Term Security And Health Of Free Open-Source Software
Linux Foundation's Census II identifies the most commonly utilised free and open-source software (FOSS) parts in production apps and analyses them for potential vulnerabilities, which can inform actions to sustain the long-term security and health of FOSS.
According to Linux Foundation, there is too little data on actual FOSS deployment. Although there is public data on package downloads, software changes, and known security vulnerabilities, the record on where and how FOSS packages are being utilised is unclear.
Members of the Census II team and the Steering Committee spent months in the time leading up to the project’s acquisition of data attempting to anticipate and prepare for expected obstacles and challenges to the data’s use and analysis. The challenges created by the lack of a standardised naming schema for software components (that had troubled Linux Foundation’s Census I effort) still persisted. The naming conventions for software components across all the data contributed to the Census II effort were unique, individualised, and inconsistent.
Despite the considerable effort that went into creating the framework to produce these initial results for Census II, the challenge of applying it to other data sets with even more varied formats and naming standards still remains.
Lack Of Standardised Software Naming
The struggles with this lack of standardised software component naming schema are not unique to the CII Census projects. The National Institute for Standards and Technology (NIST) has grappled with this issue for decades in the context of software vulnerability management.
The bottom line—revealed by the Census II project, the NTIA process, NIST’s vulnerability management struggles, and other similar projects—is that there is a critical need for a standardised software component naming schema.
Security Of Individual Developer Accounts
The next challenge and lesson learned that arose after the data had been analysed was the criticality of the security of individual developer accounts. Out of the top ten most-used software packages in analysis, the CII team found that seven were hosted under individual developer accounts. The results of such high dependence reliance upon individual programmer accounts must not be ignored. For many causes pertaining to legal, bureaucratic, and security, individual developer accounts have a few security safeguards with them than organisational accounts in a majority of instances.
While these individual accounts can use measures like multi-factor authentication (MFA), they may not always do so, and individual computing environments are probably more vulnerable to attack, finds the Linux Foundation. This means that code changes under such individual developer accounts are way easier to make, and also without much detection. And as a result, developer account takeovers have begun occurring with increasing frequency. “Backdooring” is one popular method used to infiltrate accounts: hackers insert malicious code into seemingly innocuous packages that create a “backdoor” for hackers to enter once the host package is installed.
Your reaction
Discussion
What's your take on this story?
No comments yet — be the first to share your view.