Identifying Europe's Critical Open Source Software - FOSSEPS
Written by Nikos Vaggalis   
Wednesday, 13 April 2022

FOSSEPS stands for Free and Open Source Solutions for European Public Services and is an initative by the EU Commission to identify the most critical open source software used by European Public Services.

Open Source Software powers everything, from modern servers, to IoT, to the desktops at work and is at the heart of the European Union systems too. It is so important that the European Commission's Open Source Programme Office has decided to offer bug bounties on popular open source software as described in "European Union Will Pay For Finding Bugs In Open Source Software".

The issue with the bug bounty was which apps were going to be labeled as critical or important in order to allocate resources to them. This is the same problem faced by the Open Source Security Foundation in its effort to make open source software sustainable and for which the Criticality Score Project was set up. This has already led to critical OSS projects being identified, most recently with the publication of "Census II of Free and Open Source Software - Application Libraries", as we reported last month.

The FOSSEPS initiative has a similar aim, that of identifying the most critical software used in the EU's public sector, but the approach in this case is to conduct a survey.

In this project "Critical software" is software that is significantly important for European Public services (EPS) and whose continued usage and existence is at risk. The importance of a software item can be due to it being widely used inside an organization or because
it supports key processes for this organization. From a usage perspective, the software may not be well supported via internal support contracts or via inadequate/poor responses from the software community that maintains it. From a sustainability perspective, the software’s continued existence may be threatened due to the poor health of the software project community and their inability to maintain it.

The outcomes of harvesting the survey are going to be to: 

  • Build a European open source Applications Catalogue (with data drawn from national catalogues) and release it on the web for public search and use.
  • Create an inventory of Europe’s most critical open source software used by European Public Services.
  • Create a framework for European Cooperation on Open Source: Encourage and establish a framework e.g. via a European Public Services Open Source User Group (EPS-OS-UG), for sharing of knowledge, experiences and initiatives on open source at a European level. 

 

The survey comprises nine questions in three sections. The first relates to pre-built, off-the-shelf open source software applications. The second relates to open source dependencies, such as software libraries and frameworks an organization uses to develop applications.The third section asks questions about open source in your organization, though many questions are interspersed in the other two sections.

Respondents also have to upload two spreadsheet files. In the first they list the most crucial open source applications or infrastructure elements for their organizations and estimate their criticality using to the following template: 

 

  • Name of the FOSS project [Mandatory]
  • URL of the FOSS project
  • Category of the FOSS project [Mandatory]
  • Total number of instances of this type of software (both FOSS and proprietary)
  • Maximum degree of importance of this FOSS project for your org [Mandatory]
  • Explanation of the degree of importance
  • The governance of the project is
  • Your assessment of the health of this project [Mandatory]
  • Explanation of your assessment
  • Type of support contract your organization has for this FOSS project [Mandatory]
  • Details on your support contract
  • Your contribution to this FOSS project
  • Details on your contribution to this FOSS project 

 

The second spreadsheet is for listing the most important FOSS framework/libraries used in respondents software development. It repeats most of the above questions and also asks for the number of applications each dependency is used in.

The survey also includes questions that help the committee to understand an organization's use of and support for open source applications within the business and infrastructure areas as well as the usage and support of open source dependencies (that means libraries and frameworks) from a software development point of view: 

  • Is your organization aware of, or been affected by any of these incidents/vulnerabilities?
  • Heartbleed (2014)
  • LeftPad removal of NPM (2016)
  • Event-stream hijacking (2018)
  • Log4shell (2021)
  • Scuttling of colors. js/faker (2021)
  • Does your organization have an explicit policy regarding open source software?
  • Does your open source policy include rules about support for open source used within your organization?
  • Does your open source policy include rules about contributing to open source projects used within your organization?
  • Does your organization have a dedicated contact person or structure (sometimes also called an "Open Source Program Office") for matters related to open source software?
  • Does your organization develop (or get developed) open source software applications? If so, please indicate the approximate number of such bespoke applications currently in use?
  • Is your organization aware of recursive software dependencies in the software development tools/frameworks that you use?
  • Does your organization take any specific action to tackle security problems that may affect the tree of recursive open source dependencies used by your applications? 

And, of course, it also ask about which public organization respondents are answering for.

This initiative marks the latest trend of institutional awareness on OSS. EU's awareness commenced with the Free and Open Source Software Audit (FOSSA) project in 2019, thanks to Julia Reda MEP of the EU Pirate Party, who started the project thinking that enough is enough after severe vulnerabilities were discovered in key infrastructure components like OpenSSL. This prompted her to involve the EU Commission in contributing to the security of the Internet. Check EU Bug Bounty - Software Security as a Civil Right for more.

This was followed in 2022 with The European Commission's Open Source Programme Office who has decided to offer bug bounties on popular open source software. Check European Union Will Pay For Finding Bugs In Open Source Software for more. And last but not least and fairly recently, the Alpha Omega Project of the Linux Foundation together with the OpenSSF founded by megacorps like Microsoft and Google. From "New Initiative For Taking Open Source Software Security Seriously":

The fact that Microsoft and Google are shoveling money into the Alpha-Omega Project, with an initial investment of 5 million dollars, is further evidence of its importance. The narrative is that given the scarcity of the resources to allocate, bug bounties like the European Union's one and the Linux Foundation's SOS Rewards are welcome, but not enough, as they're small in scale. The Linux Foundation found that a larger more holistic attempt should be utilized. For that reason they kickstarted the Alpha Omega initiative.

Of course, other related activities like securing the software supply chain, as in Sigstore, are already running in parallel. From Does Sigstore Really Secure The Supply Chain?

To build useful software we don't reinvent the wheel but we build on work already done coming bundled in the form of libraries.
The problem is that even a mediocre open source projects can have loads of such dependencies which themselves depend on others, forming a length chain. Not a problem per se unless malicious code has been inplanted anywhere in this chain. After all, it takes just one npm install <module> command to get infected.

The overall conclusion is that OSS, once an absurd minority movement, nowadays runs everywhere, underpinning the functionality of modern society. As such it needs all the attention it can get. The Heartbleed bug happened because the OpenSSL Software Foundation, which is responsible for the maintenance of the OpenSSL library, the cornerstone of safe transactions on the Internet used by millions of websites and organizations, was receiving just $2000 of donation money per year and had only ONE full-time employee working on the library. Nowadays this would be deemed unacceptable. OSS developers have to make a living too, as Patrice-Emmanuel Schmitz, legal expert of Joinup says:

Like bread and beer, free software development is not for free: developers need some incentives, let’s say just the money they need for purchasing their bread and beer or for ensuring their family a decent way of life.

 

More Information 

Help us identify critical open source used within European Public Services

Related Articles

European Union Will Pay For Finding Bugs In Open Source Software

Census II Lists Critical Application Libraries

New Initiative For Taking Open Source Software Security Seriously

Taking Open Source Criticality Seriously

Does Sigstore Really Secure The Supply Chain?

EU Bug Bounty - Software Security as a Civil Right

Last Updated ( Wednesday, 13 April 2022 )