the EU and US approachES TO regulation for dIGITAL products and THEIR IMPACT ON the OSS ecosystem 

Posted in
Placeholder

Overview

In the US, it was the President’s Cybersecurity Executive Order 14028 that set things in motion. There have been some industry specific regulations covering the private sector, notably by FDA and NHTSA for medical devices and automotive vehicles respectively. However, the general focus has been in the area of Federal Administration and public procurement. The Executive Order was a call to all Federal Government agencies to take necessary steps to address cybersecurity risk and in particular vulnerabilities in the software supply chain. President Biden’s Executive Order on Improving the Nation’s Cybersecurity (the “EO 14028”) is available here.

In contrast, the triumvirate of EU regulatory bodies (EU Parliament, EU Commission and EU Council) is proposing a wide-ranging, cross-industry, measure to sit alongside the existing legal framework for General Product Safety. This measure is called the Cybersecurity Resilience Act (‘CRA’) and is referred to as a ‘horizontal’ harmonization regulation. The last draft of the Regulation was published in December 2023.

It sets out to define and implement a regime of ‘conformity assessment’ and CE marking for conforming digital products and strict product liability attaching to a range of ‘economic operators’, with the twin objectives of consumer protection and a level playing field for business. Although the Regulation anticipates that the Member States Governments will build this into their own public procurement programs for digital products, this is not the main emphasis of the CRA.

Similarities between the Regulations

On looking at both measures, they seem to address (either directly and/or indirectly) at least the following three areas (highlighted here in form of a high level summary) with relevance to OSS.

  • Requirements for the sale and/or procurement of certain software products and software based services

The EO 14028 triggers various revisions and/or updates to existing regulations related to the requirements for procurement of software products and/or software based services by the Federal Government Agencies as well as requirements for the offering of such products or services by contractors and/or service providers to the Federal Government Agencies.

The CRA creates cybersecurity requirements for the placing on the market of any territory of the EU Member States (the “Market”) of certain products with digital elements. Software products qualify as such products with digital elements if they have a cybersecurity-related functionality and perform a function which carries a “significant risk of adverse effects in terms of its intensity and ability to disrupt, control or damage a large number of other products with digital elements through direct manipulation”.

  • Requirements enabling and improving cybersecurity related to software products

The EO 14028 is aiming to improve and strengthen the detection and protection from cyberattacks against the Federal Government’s digital infrastructure, “including computer systems, whether cloud-based, on-premises, or hybrid. The scope of protection includes systems that process data (IT) and those that run vital processes (OT).”

The CRA regulations are focusing on “setting boundary conditions for the development of secure products with digital elements by ensuring that hardware and software products are placed on the Market with fewer vulnerabilities and that manufactures take security seriously throughout a product’s life cycle.” Additionally, products with digital elements that are placed on the Market are required to bear the so called CE marking “to visibly, legibly and indelibly indicate their conformity with the CRA cybersecurity requirements.”

  • Software supply chain management

The EO 14028 orders the review, and creation of guidelines including appropriate amendments of the Federal Acquisition Regulations (“FAR”) to enhance the software supply chain security with relevance for the procurement of software products by the Federal Government Agencies. The concept and detailed definition of a Software Bill of Materials (“SBOM”) is a key component of software supply chain security. The obligation to provide to the procuring Federal Government Agencies an SBOM and additionally providing an attestation as to the absence of software vulnerabilities starts with the principal contractor but does not end there. The principal contractor will also have to ascertain the integrity of its suppliers and obtain respective attestations from them …. and so on down the entire supply chain.

One of the intentions of the CRA regulation is to ensure that cybersecurity requirements established in it are also taken into account “throughout the supply chains, and by doing so, the CRA  aims to make final products with digital elements and their components more secure”. Unlike the US model, the approach is bottom up. In other words anyone wanting to commercialize a product with a digital element (including software itself) will be required to observe the requirements of the CRA right from the kick off, i.e. during the design and development process.

Impact on the OSS Ecosystem 

Even though at least these three areas of intersection between the CRA and the EO14028 exist, the impact that each of the measures has or will have on the OSS ecosystem is not necessarily the same. 

The impact of the EO 14028 on the OSS ecosystem and the business world seems in the short term rather limited to a small circle of players and additionally only to a very specific field of business. The regulations, guidelines and requirements which are or will be created based on this Executive Order will likely not change in the short term the way OSS is being developed, offered and/or maintained. They will also not directly regulate OSS related activities performed by OSS developers, OSS maintainers, or OSS project owners, especially OSS Foundations. Instead, regulations will concern the business activities and the work of contractors and service providers (the small circle of players) when contracting with the Federal Government (the specific field of business). This is not to say that suppliers of general commercial software products and software components providing mundane ‘back office’ functionality such as in the case of the Log4j exploit will not be swept up within the scope of the regulation. If use of the software is widespread it may only be a matter of time.

The impact of the CRA on the OSS ecosystem is slightly different. Although the full force of the CRA cybersecurity requirements will fall on those conducting a commercial activity, the CRA regulations will have to be carefully analyzed and interpreted to determine to what extent they still might impose requirements directly on OSS developers, maintainers, or OSS foundations as well as companies who are running OSS projects without directly commercializing the software itself. Some of those activities might be outside the CRA Regulation altogether but others may be subject to what the CRA refers to as the ‘light touch’ approach. The good news, it seems, is that the most recent draft of the CRA Regulation from December 2023 has resolved some of the highly critical ambiguities in the prior version of the Regulation which would arguably have threatened the very existence of the OSS development model. The not so good news is that it is still far from clear where the lines will be drawn especially for permissively licensed OSS which finds its way into the stream of commerce.

This high-level review of the two approaches is just the tip of the iceberg and the insights should be verified and further elaborated by a deeper dive once the various instruments are further developed. Staying informed in this area will remain key for not only the US Government contractors and service providers but also for the OSS community and all companies and individuals engaged with OSS activities in the EU markets, so stay tuned!

Your mOSS team 

Leave a Reply

Your email address will not be published. Required fields are marked *