Supply chain security obligations for NIS2 regulated entities vs. developers of open source software

by Maarten Aertsen

NIS2 is a European directive that regulates sectors of high criticality (think: energy, water, …, digital infrastructure) with respect to the security of 'network and information systems' across the European Union. On June 27th, the European Commision published a 'draft implementing act' for public comment specifying in more detail the security measures for providers of essential services in the digital infrastructure and digital provider sectors.

I was quite interested to understand what these rules would mean upstream for those that develop Free and Open Source Software (FOSS) used by these providers, considering that NIS2 Art. 21.2 mandatory measures includes:

(d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;

The window for public comment closed on July 25th. What follows are excerpts of public feedback that was filed in relation to supply chain obligations as they directly and indirectly relate to FOSS. We start with our own feedback, then quote from comments by others that mention FOSS (alphabetically) and end with related comments on supply chain security measures without explicit mention of FOSS.

Our feedback, jointly with FSFE and OpenSSF

PDF, with footnotes

Our concern is that the term 'supplier' includes economic actors publishing Free and Open Source Software that are not a suitable counterparty for the type of requirements the draft imposes on NIS2 entities in their relation with direct suppliers.
The term ‘supplier’ is not defined in NIS2. It is used in relation to open source software (recital 52) and with respect to (unspecified) ‘software editors’ (recital 85), which leads us to believe that the interpretation of ‘supplier’ is extremely broad and potentially extends to any natural or legal person developing and publishing software.

With regards to practicability, the draft seems to focus on business to business relations, where for Free and Open Source Software, no such relation needs to exist. Often complex software products at the core of services of the Digital Infrastructure sector of NIS2 are published by independent individuals, not-for-profit actors and academic organisations where beyond the freedoms granted by Open Source licences, no relationship exists between developer ('direct supplier') and an entity in scope for NIS2 to impose obligations, contractual or otherwise, such as listed in Annex, Section 5, 10.1 and 10.2.
With regards to effectiveness, we question whether the currently included measures will contribute to a high(er) level of cybersecurity for those 'direct suppliers' that publish Free and Open Source Software without a motivation to be or become the type of commercial supplier the Annex is tailored to.

It is important to recognise the special nature of Open Source development and the Open Source ecosystem and its role in the software supply chain. Implementation needs to be proportionate and effective. Thus the dialogue to improve cybersecurity in Europe with the Free and Open Source Software community should continue.

Feedback filed by others directly relating to FOSS

Centr (the Council of European Top-level domain Registries) and CZ.nic (the .cz domain registry) wrote:

We would also like to point out a potential mismatch with expectations under supply chain management in Section 5 of the Annex, and upcoming legal requirements under the Cyber Resilience Act (CRA), that take into
account the special status of Free and Open Source Software (FOSS) development ecosystem. As FOSS is widely used and embedded within the foundational internet’s infrastructure, we welcome the attention given to the FOSS ecosystem within the regulatory discussions on CRA, and would like to see that complexity to be reflected in Section 5. We call for the recognition of the role of FOSS in the development of the internet's infrastructure and further alignment between Section 5 and the CRA.

denic (the .de domain registry) wrote:

we would like to stress that much of the core DNS Internet infrastructure relies on and benefits from free and open source software (FOSS). Any supply chain considerations in the Annex therefore should be aligned with the Cyber Resilience Act (CRA).

ECIS wrote:

the current draft risks creating unintended consequences for open source software (OSS) that could significantly hinder use of OSS in the EU. Open source software’s security strength lies in the collaborative innovation of projects that include numerous contributors. These projects and contributors investing their efforts into driving European innovation should not be considered “suppliers” or “service providers” under the implementing act. Requiring relevant entities to contract with open source projects or contributors would fundamentally undermine the open participation model of such communities. Unlike in case of proprietary software where relevant entities are dependent on a supplier, in case of open source, the relevant entity gets the code and the rights they need to ensure it meets NIS2 requirements. Given the conceptual difference, we suggest that the implementing act should align with other Cybersecurity regulations (notably the CRA) in ensuring that such open source software is out of scope of the supply chain requirements.

Eclipse Foundation wrote feedback that can best be read in full, including:

[..] the open source community, in Europe and globally has expressed to policy makers and the industry that “all the people writing and maintaining these [open source] projects, are not suppliers [...and... ] do not have a business relationship with all these organisations” leveraging open source components.

In various parts of the Annex on Technical and methodological requirements referred to in Article 2 of the Implementing Regulation, the listed obligations are not fit to the reality of software supply chains leveraging open source components.

eco ( "the largest Internet industry association in Europe") wrote:

Another concern raised by parts of the Internet Industry concerns the question in how far developers and providers of Open Source Software are covered as “outsourced developers” according to the draft Implementing Regulation, which may create adversarial impact on Open Source Software development and deployment.

Microsoft wrote:

Point 5.1.4. of the Annex should be revised to exclude open-source software suppliers from the definition of suppliers subject to contract requirements in this part of the Annex and to conform to the terms of the forthcoming Cyber Resilience Act. Point 5.1.4. of the Annex enumerates several mandatory contract terms between relevant entities and their suppliers to enhance supply chain security. But these terms do not define what constitutes a “supplier” and they appear to overlook the nature of open-source software and the framework under the CRA for addressing open-source software. As drafted, the Annex places obligations on regulated entities to amend their contracts with suppliers to include the provisions listed in point 5.1.4.
This approach to supply chain security is based on the assumption that service providers have individually negotiable contracts with all of their suppliers, including for open-source software. This assumption does not hold in the case of open-source software dependencies and should these be treated as suppliers within the meaning of the NIS2 Directive there are major potential consequences. Almost all regulated entities implement open-source software in their services that has been developed by third9 parties according to open-source software development principles, including by not-for-profit organizations, foundations, or individual developers. In many cases, no contractual relationship between the regulated entity and the open-source software developers exists (beyond adherence to a standard open-source copyright license). Consequently, regulated entities would be unable to meet the supply chain security requirements laid out in section 5 in relation to their open-source dependencies.
Absent a definition of ‘supplier’ in the NIS2 Directive, there is uncertainty regarding the status of open-source software developers. It is unclear whether an open-source developer is an entity that sells a product or service to the regulated entity, as it is defined in related Union legislation for electricity and gas (Art. 2 (12) Directive 2012/27/EU & Art. 2 (7) Directive 2003/55/EC, respectively), or whether open source software developers that make their software available for re-use to the general public could also be treated as suppliers whenever a regulated entity implements open source software in its services, even in the absence of a contract establishing a sale or service agreement. This legal uncertainty is exacerbated by the reference to ‘software editors’ as an example of suppliers in recital (85) NIS2 Directive.
Recommendation. We therefore recommend that the draft implementing regulation should clarify the supply chain security rules for regulated entities with regard to their open source software dependencies, either by including a definition of, supplier' that excludes open source software that is not provided on the basis of a sales or service agreement, or by outlining a supply chain security procedure that takes due account of the particularities of open source software development practices. These particularities have been established, after extensive deliberation with the open-source community, in the CRA, which is intended to “facilitate the compliance with supply chain security obligations of entities that fall within the scope of [the NIS2 Directive]” (Recital (126) CRA as approved by the European Parliament). The draft implementing regulation could therefore make reference to the CRA to clarify supply chain security rules regarding open-source software components.

Netnod wrote:

[Section 5, red.] assumes that all NIS2-entities have explicit relationships with their suppliers, which in turn imply the existence of contractual obligations and communications.
However, in a digital context it is common that services are procured at a wholesale level. This implies that (wholesale) service providers do not know precisely what their services are being used for. This includes but is not limited to DNS services, electronic communications services, compute and storage (“cloud”), (open source) software, and similar services, where services are composed in multiple (wholesale) levels or layers presented together as a coherent unit to the end-user.

RIPE NCC wrote:

We would also like to highlight concerns expressed by RIPE community members and other related stakeholders on the draft provisions on supply chain security requirements in Annex and the uncertainty expressed regarding Free and Open Source Software (FOSS). Since the term ‘supplier’ is not explicitly defined, and noting the reference to unspecified “software editors” in recital 85 of the NIS2 Directive, a broad interpretation could potentially encompass any natural or legal person developing and publishing software. It is important to underline that FOSS components can be incorporated in any software products and services even with no formal contractual relationship being established between the provider and relevant entities. It is therefore important to provide legal certainty with regard to FOSS components. Finally, clearly referencing the Cyber Resilience Act would ensure a higher level of coherence and consistency across the two regulatory regimes.

Feedback filed by others on supply chain security without reference to FOSS

Amazon wrote:

It is currently unclear what ‘direct suppliers and service providers’ means, [..]

digitales, etno, GSMA and Telefonica wrote (variations of the same paragraph, one of which is):

Many of the supply chain requirements are new and may differ from existing regulations, from ongoing work for other legislation (e.g. DORA),
or may be so burdensome for SMEs that ICT companies would have to exclude from their supply chain altogether in order to comply with the proposed implementing legislation.

GoDaddy wrote (in regards to supply chain security measures involving mandatory background checks):

The entity responsible for supervising an individual should be responsible for performing any reasonably required background checks, as far as permissible under applicable data protection law, such as the GDPR, and
employment law.

In conclusion

As we concluded our own submission, it is important to recognise the special nature of Open Source development and the Open Source ecosystem and its role in the software supply chain. Implementation needs to be proportionate and effective.

My impression is that the European Commission is listening to the concerns expressed. I hope that the short timelines leave room for improvements to the draft. The dialogue to improve cybersecurity in Europe with the Free and Open Source Software community should continue.