Open Source Security vs Open Source Liability

When it comes to cyber security, OSS may often be both the cause and the cure for what ails our digital world.

Open Source Software (OSS) code is incorporated, to some degree, into the majority of modern software applications. The proportion of OSS code as opposed to proprietary code varies massively depending on the software in question and the incorporation of OSS code can both enhance the security of applications and undermine it, depending upon how it is deployed.

Threat actors seek vulnerabilities to exploit chinks in the armour of software used by organisations to host and manage their digital existence. Since open source licensing encourages collaboration and the improvement of already existing code, it naturally leads to the swift spotting and correction of bugs and errors, reducing vulnerabilities for threat actors to exploit. However, since OSS is freely available to all, anyone regardless of their intent can access, download, modify, and re-distribute OSS source code, and depending on the approval process, may even be able to merge their modifications to the main “official” branch of the OSS. The movements behind OSS vary in their methods and implementation of safeguards and quality control techniques so some are adept at spotting potential risks whereas others may leave them unaddressed.

The proliferation of OSS is a blessing and a curse since even skilled and experienced software developers find it hard to identify which are the riskier OSS options in terms of their development method and likely exposure to vulnerabilities. To make matters more challenging, businesses, particularly those developing applications for their own use rather than re-sale, often lack a comprehensive inventory of OSS deployed across their software, meaning that they may not know which vulnerabilities they are exposed to and will not become aware when known bugs are identified and patches created to address them. Just as privacy by design and default is a principle that sounds obvious in theory but proves challenging to implement in practice, so too is the incorporation of cyber security measures at the development stage of OSS and applications incorporating it.

The use of risk reduction techniques in coding practice, along with the deployment of secure (encrypted) communication channels to share and collaboratively address concerns about possible vulnerabilities, can help developers build stronger OSS. Just because code is widely used does not mean that it is secure - developers, both of OSS in its purest sense, but also those adapting and incorporating it into proprietary applications must implement a secure testing regime.  This is not only good governance but increasingly important legal risk mitigation as reliance on third-party testing is unlikely to reduce legal liability where an identifiable and fixable error leads to a vulnerability that facilitates a security breach.

EU efforts – the risk of unintended consequences looms large

Attempts to address the impact of OSS on cyber security have recently been made at EU level but while these legislative efforts are welcomed by many, there is also widespread concern that the position is decidedly mixed, with forthcoming legislation failing to reflect a real understanding of how OSS works, and its essential role in software applications of many types – including digital cyber security tools. Critics fear this lack of understanding will ultimately lead to the creation of an unintended chilling effect on the development of OSS.

NIS2

The NIS2 Directive is the EU-wide legislation on cyber security. It came into force in 2023 updating the previous 2016 regime, and provides legal measures aiming to boost the overall level of cyber security in the EU. Member States have until October 2024 to transpose NIS2’s requirements into national law with further deadlines following for Member States and affected organisations.

NIS2 creates two categories for entities in scope: important and essential. All in-scope entities will have to meet identical requirements but supervision and enforcement will be more robust in the case of essential entities. Increased responsibilities for in-scope organisations will be coupled with strict reporting obligations. Many more organisations fall into scope of NIS2 than were covered by the old regime and penalties for non-compliance can be up to €10 million or 2% of global revenue for serious failures. These penalties may be issued alongside GDPR penalties if a failing is also a data breach with liability arising under the privacy regime.

With big challenges for newly in-scope entities to address, Recital 52 of NIS2 recommends OSS tools as a cyber security enhancing force for good:

"Open-source cybersecurity tools and applications can contribute to a higher degree of openness and can have a positive impact on the efficiency of industrial innovation. Open standards facilitate interoperability between security tools, benefitting the security of industrial stakeholders. Open-source cybersecurity tools and applications can leverage the wider developer community, enabling diversification of suppliers. Open source can lead to a more transparent verification process of cybersecurity related tools and a community-driven process of discovering vulnerabilities. Member States should therefore be able to promote the use of open-source software and open standards by pursuing policies relating to the use of open data and open-source as part of security through transparency. Policies promoting the introduction and sustainable use of open-source cybersecurity tools are of particular importance for small and medium-sized enterprises facing significant costs for implementation, which could be minimised by reducing the need for specific applications or tools."

The Cyber Resilience Act

While NIS2 actively champions OSS tools, a potentially conflicting view can be identified in the draft EU Regulation on cyber security requirements for products with digital elements, known as the Cyber Resilience Act (CRA). The CRA seeks to increase the cyber resilience of digital products placed on the single market by imposing strict requirements on vendors which are enforced with fines even higher than those under NIS2 of up to €15 million or 2.5% of global revenue – whichever is greater.

Mindful of the need to protect the collaborative approach of OSS developers, the CRA contains language designed to protect OSS developers and collaborators from liability for undetected or unremediated errors, where responsibility should sit elsewhere. However, critics of the current draft of the CRA proposed by the EU Commission have pointed out a number of areas where a failure to recognise the nuances of how OSS development works in practice, could discourage risk averse participants from offering important development contributions, for fear of liability under the CRA.

OSS development may involve contributions from individuals acting in a personal capacity or in association with a foundation or academic group. If such individuals are also employed by companies, the current text of the CRA (Recital 10) will bring the contributions of such individuals and, therefore the project as a whole, within scope of the CRA as the project will not be considered to have adopted “a fully decentralised development model.” In a worst-case scenario, projects may ban contributions from individuals employed by  companies, and companies prohibit their employees from contributing to OSS projects.

The use of "non-commercial" as a qualifier has been highlighted by the Open Source Initiative (OSI), among other groups as lacking meaning in a software development context, creating a risk that many more groups and participants in OSS development could be subject to the CRA’s requirements under this definition than is intended. OSI recommends further work on the open source exception to the CRA requirements to “exclude all activities prior to commercial deployment of the software and to clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment”. The OSI argues that leaving the text as it stands could chill or even prevent availability of globally maintained OSS in the EU.

The Revised Product Liability Directive

In addition to the cyber security-specific legislation mentioned above, the issue of liability of software developers for damages ensuing from vulnerabilities exploited in their software (OSS or otherwise) is also the topic of ongoing debate in the context of the upcoming Revised Product Liability Directive (the RPLD). It is possible that the RPLD will significantly increase the compliance obligations and costs of most software developers (especially those in OSS), as well as exposing them to new vectors for claims.

Where does this leave OSS?

While the recognition of the importance of OSS tools in the fight against cybercrime in NIS2 may be reassuring for those actively engaged in the development of such tools, the current draft of the CRA could make the development of OSS projects more challenging – and certainly more tightly governed for all potential uses of OSS in digital products. Whether or not the CRA is amended to better reflect the realities of OSS development, it is clear that organisations incorporating OSS into digital products (the majority of them) can no longer afford to be complacent in their use of OSS. As a minimum, careful documentation of the origins and testing of all code used will be needed for entities placing digital products on the single market and much tighter development processes may be needed for all OSS projects to avoid corporate participants from inadvertently bringing otherwise decentralised projects within the scope of the CRA.