The Impact of the European Product Liability Directive on Software

Engineering

Doriana Cob

arzan

1 a

, Richard Bubel

2 b

and Torsten Ullrich

1,3 c

Fraunhofer Austria Research GmbH, Klagenfurt am W

orthersee, Austria

Software Engineering, Technische Universit

at Darmstadt, Darmstadt, Germany

doriana.cobarzan@fraunhofer.at, bubel@cs.tu-darmstadt.de, torsten.ullrich@fraunhofer.at

Keywords:

Product Liability Directive, Software Quality, Software Supply Chain, Risk Management.

Abstract:

The European Commission’s revised Product Liability Directive was signed in October 2024 and will come

into force in 2026. The revision extends the concept of a product to include software and software-based

services, and signiﬁcantly strengthens the legal rights of customers in the event of damage caused by software.

This makes liability issues a key aspect of software development. The precise manner in which national

legislation is to be drafted and interpreted remains to be clariﬁed. However, the general direction has been

sufﬁciently outlined to enable the implementation of preventative measures, which are discussed brieﬂy here.

This article looks at the legal implications of the directive for software producers, focusing on third-party

components. It also discusses guidelines to ensure high software quality and improve the legal position of the

producer. The present work is concerned exclusively with the Product Liability Directive, notwithstanding

its embedding within a framework of regulations, including, for example, the AI Act and the General Data

Protection Regulation.

1 INTRODUCTION

The European Single Market is an economic area

comprising several national markets of the European

Union Member States, which are characterised by the

absence of internal borders. In addition to guarantee-

ing the four fundamental freedoms (free movement of

goods, persons, services, and capital), the European

Single Market aims to ensure growth, maintain and

improve competitiveness, and promote job creation.

The advantages for consumers include a greater va-

riety of goods and services, as well as lower prices.

Competition between companies also leads to im-

provements in the quality of goods and services. It fa-

cilitates the ability of citizens to ﬁnd employment and

to reside in EU Member States. As part of the Euro-

pean Single Market, national laws are harmonised to

create a more uniform legal framework. The Product

Liability Directive (85/374/EEC) has been an essen-

tial part of this harmonised framework since 1985 and

remains in force today, unaltered.

https://orcid.org/0009-0000-4243-8084

https://orcid.org/0009-0003-4847-4707

https://orcid.org/0000-0002-7866-9762

In view of the recent substantial progress, espe-

cially in the ﬁeld of information and communication

technology (ICT), a thorough review and modernisa-

tion of the Product Liability Directive was imperative.

On the 28th of September, 2022, the European

Commission published its proposal for a directive on

the liability of defective products, which revises the

existing Product Liability Directive that was adopted

nearly 40 years ago. Following a two-year period, the

directive was formally signed on the 23rd of Octo-

ber 2024 and subsequently published in the Ofﬁcial

Journal on the 18th of November 2024 (2024/2853).

The new directive will be implemented into national

law and will come into force 24 months after the di-

rective enters into force, i.e. in 2026. The precise

manner in which national legislation is to be drafted

and interpreted remains to be clariﬁed. However,

the general direction has been sufﬁciently outlined to

enable the implementation of preventative measures,

which will be discussed brieﬂy here. This work fo-

cuses exclusively on the Product Liability Directive.

While it is part of a broader European regulatory ini-

tiative, the focus remains on the Product Liability Di-

rective only.

626

Cobârzan, D., Bubel, R. and Ullrich, T.

The Impact of the European Product Liability Directive on Software Engineering.

DOI: 10.5220/0013363100003928

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 20th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2025), pages 626-634

ISBN: 978-989-758-742-9; ISSN: 2184-4895

2 SOFTWARE IS A PRODUCT

The European Union’s updated Product Liability

Directive (see https://eur-lex.europa.eu) expands the

deﬁnition of a product to reﬂect the evolving land-

scape of software-driven goods and digital ecosys-

tems. In detail, Article 4(1) deﬁnes that “ ‘product’

means all movables, even if integrated into, or inter-

connected with, another movable or an immovable;

it includes electricity, digital manufacturing ﬁles, raw

materials and software ”. In other words, the product

concept is explicitly extended to digital manufactur-

ing ﬁles (e.g. 3D printing ﬁles), raw materials (e.g. gas

and water) and any software, including stand-alone

software and AI systems (except free and open-source

software).

2.1 Liable Parties

The economic operators concerned, i.e. potentially li-

able parties, include “the manufacturer of a defective

product;” (Article 8(1)a) and “the manufacturer of a

defective component, where that component was inte-

grated into, or inter-connected with” (Article 8(1)b).

By deﬁnition, a manufacturer is “any natural or legal

person who:

(a) develops, manufactures or produces a product;

(b) has a product designed or manufactured, or who,

by putting their name, trademark or other distin-

guishing features on that product, presents them-

selves as its manufacturer; or

their own use;” (Article 4(10)).

In the case of a manufacturer established outside the

EU, the liable parties are the importer of the product/-

component, the authorised representative of the man-

ufacturer (in terms of product safety law) and the ful-

ﬁlment service provider (storage, packaging and ship-

ping service provider). If none of the above can be

identiﬁed, the liable parties are the distributor and the

online platform provider.

The directive deﬁnes software as a product, re-

gardless of how it is delivered or used. It can be em-

bedded in a device, used via a network or cloud, or de-

livered through a software-as-a-service model. Strict

liability also applies to related services. The directive

says software producers or developers, including AI

system providers, are the manufacturer. They could

also be held liable for updates, improvements or ma-

chine learning algorithms. Digital technologies such

as AI allow manufacturers and developers to exercise

control over products even after they have been placed

on the market or put into service.

2.2 Defect

According to the Product Liability Directive a “prod-

uct shall be considered defective where it does not

provide the safety that a person is entitled to expect

or that is required under Union or national law” (Ar-

ticle 7(1))). The directive presents a non-exhaustive

list of factors that may be relevant in the assessment

of defectiveness:

• “the presentation and the characteristics of the

product, including its labelling, design, technical

features, composition and packaging and the in-

structions for its assembly, installation, use and

maintenance;” (Article 7(2)a),

• “reasonably foreseeable use of the product;” (Ar-

ticle 7(2)b),

• “the reasonably foreseeable effect on the product

of other products that can be expected to be used

together with the product, including by means of

inter-connection;” (Article 7(2)d),

• “relevant product safety requirements, including

safety-relevant cybersecurity requirements;” (Ar-

ticle 7(2)f),

• “in the case of a product whose very purpose is to

prevent damage, any failure of the product to fulﬁl

that purpose” (Article 7(2)i).

A noteworthy distinction between the previous direc-

tive and the current one is the timing for determining

defectiveness. In the future, the determination of de-

fectiveness will not only consider the time of placing

the product on the market, but also the period during

which the product remains under the control of the

manufacturer after being placed on the market. This

period may be affected by factors such as the pres-

ence or absence of software updates and upgrades or

a signiﬁcant modiﬁcation (Article 7(2)e).

2.3 Damage

With respect to potential damages, and in recognition

of the increasing importance and value of intangible

assets, the destruction or corruption of data, such as

digital ﬁles deleted from a hard drive, will also be cov-

ered, including the cost of recovering or restoring that

data.

The possibility of setting ﬁnancial limits on the li-

ability, e.g., via end-user licence agreements, etc., was

removed from the revised Product Liability Directive.

Furthermore, the limitation period within which an in-

jured person may claim compensation for personal in-

jury under the directive has been extended from 10 to

25 years if, according to medical ﬁndings, the symp-

toms of the personal injury appear late.

The Impact of the European Product Liability Directive on Software Engineering

627

The burden of proof for the injured party remains

unchanged; however, new rules of presumption will

be introduced. It will henceforth be sufﬁcient for the

claimant to demonstrate the likelihood of a product

defect in order to successfully pursue claims for dam-

ages based on strict liability. The duty to disclose

evidence represents a signiﬁcant development in the

judicial enforcement of claims. Once a claimant has

established their claim for damages, the defendant is

obliged to disclose relevant evidence. In the event of

the defendant failing to do so, rules of presumption

will apply to the claimant’s beneﬁt.

2.4 Supply Chain

The intricate nature of modern supply chains, partic-

ularly those that cross national borders, renders them

as complex systems. It is anticipated that companies

will be required to oversee the management of diverse

and geographically distributed supply chains, which

may include multiple tiers of contractors and subcon-

tractors in addition to the normal operations of the

company. The term “supply chain liability” denotes

the legal obligation of a corporation to compensate

for damages incurred by its business partners, which

may include suppliers, subcontractors and even cus-

tomers. The legal theory of corporate supply chain

liability postulates that a company can be held liable

for damage-causing events in its supply chain if it fails

to prevent such damage in contravention of a legal or

moral obligation to do so.

Figure 1: A focal company or product is characterised by

a supply chain network structure comprising suppliers and

customers in tiers.

These concepts are now being explicitly applied to

software with one important exception; free and open-

source: “This Directive does not apply to free and

open-source software that is developed or supplied

outside the course of a commercial activity” (Article

2(2)). In terms of product liability, it does not matter

whether the company is “at fault” or not; it is liable

regardless of its own culpability. This highlights the

interdependence of one’s own software or software-

based services on third-party libraries. There is a po-

tential risk that the chain of liability (along with the

question of compensation and regress along the sup-

ply chain) may be disrupted at the European borders

Figure 2: The fundamental premise of a software library is

the efﬁcient utilisation of resources through the reuse of ex-

isting components. Once a solution has been implemented,

it need not be re-solved if it has been solved correctly and

comprehensively in the ﬁrst place. However, the act of reuse

inherently introduces a dependency, which may have impli-

cations for the future. image source: (Parlog, 2019).

or by open-source exceptions.

The aim of supply chain risk management is to re-

duce the vulnerability of the supply chain as a whole.

This can be achieved by taking a coordinated, holistic

approach, which ideally involves all stakeholders in

the supply chain working together to identify, analyse

and address potential failure points or modes within

or affecting the supply chain (Wieland and Wallen-

burg, 2015). It would be remiss not to consider all the

risks that could affect the supply chain. These could

include, for example, quality, safety, resilience and

product integrity.

3 SOFTWARE DEPENDENCY

The interdependencies of a company and/or a prod-

uct are represented in a network as a double pyramid.

On one side is the network of suppliers, comprising

tier #1, tier #2, and so forth. On the other side is the

customer network, also arranged in tiers. The com-

pany or product under consideration is situated in the

middle (see Figure 1). It is imperative that these de-

pendencies are considered in the context of software

development with regard to liability issues.

The simpliﬁed representation of hypothetical Java

applications in Figure 2 demonstrates that this net-

work can rapidly expand to become complex and

challenging to navigate. In particular, the use of tools

for automatic package management (Pashchenko

et al., 2020) may result in dependency confusion (Ne-

upane et al., 2023) or in a lack of awareness regard-

ing the depth and extent of the network (Islam et al.,

2023).

In the fast-moving ﬁeld of software development,

there is a growing trend towards building applica-

tions by integrating external libraries, frameworks,

tools and other software components. This approach

ENASE 2025 - 20th International Conference on Evaluation of Novel Approaches to Software Engineering

628

has the potential to signiﬁcantly accelerate develop-

ment and drive innovation. By allowing developers

to leverage prebuilt functionality, it enables them to

concentrate on creating application-speciﬁc features

instead of reinventing foundational components. It is

important to note that while third-party components

can offer signiﬁcant beneﬁts, they may also present

certain risks.

It would be advisable for organizations to take

ownership of the code they integrate, even if they did

not author it. Modern practices such as containeriza-

tion (Watada et al., 2019) and Infrastructure-as-Code

(IaC) (Bentaleb et al., 2022) have made it increas-

ingly common for developers to package applications

in containers and deploy them with IaC solutions like

Kubernetes and Terraform. While these technologies

offer the potential for scalable, automated deploy-

ments, they also introduce challenges such as vul-

nerabilities, version conﬂicts, and integration failures.

These issues further intensify the need for meticulous

dependency management to ensure the security, relia-

bility, and stability of software.

3.1 Dependency Tracking

In the context of security, the concept of risk and the

associated risk management techniques have become

integral to the ﬁeld of software engineering. A va-

riety of dependency management strategies may be

employed, many of which consider the entirety of the

software supply chain. Among these, zero-trust soft-

ware supply chains stand out as a potentially valuable

approach, emphasising practices designed to mitigate

the risks of compromised dependencies (do Amaral

and Gondim, 2021). This strategy is predicated on

the assumption that no component, whether direct or

transitive, is inherently secure and that veriﬁcation is

required at every stage of the software life cycle.

Google’s Supply Chain Levels for Software Arti-

facts (Enck and Williams, 2022) is a security frame-

work designed to safeguard the software supply chain

by ensuring the integrity and trustworthiness of soft-

ware artifacts. It provides a structured set of guide-

lines and best practices that developers can adopt in

order to mitigate risks such as tampering, unautho-

rised modiﬁcations, and compromised dependencies.

A noteworthy standard in this domain is the Soft-

ware Component Veriﬁcation Standard (Open World-

wide Application Security Project, 2020), which es-

tablishes a benchmark for evaluating and verifying

the security of software components. Collectively,

these two frameworks offer complementary strate-

gies for managing risks associated with the mod-

ern software supply chain, addressing the integrity

of artifacts and the veriﬁcation of component secu-

rity (Tran et al., 2024). A software component is

regarded as dependent on another if it is invoked or

integrated with it, thereby forming essential connec-

tions that enable functionality. It is of paramount

importance to implement effective dependency man-

agement strategies in order to guarantee the security,

compliance and integrity of all dependencies. Notable

incidents, such as the SolarWinds breach (Mart

ınez

and Dur

an, 2021) and the Log4Shell exploit (Ever-

son et al., 2022), illustrate the substantial risks asso-

ciated with unmanaged dependencies. In order to mit-

igate these risks, organisations are increasingly adopt-

ing tools such as Dependency-Track

, Mend

, and

Sonatype Nexus Lifecycle

. The integration into the

CI/CD pipeline (Mooduto et al., 2023) facilitate real-

time tracking, vulnerability management, and compli-

ance monitoring across the software life cycle.

The utilisation of Software Bills of Materials

(SBOM) represents an emerging practice within the

domain of modern dependency management strate-

gies. This trend can be attributed to the necessity for

enhanced transparency and security within the soft-

ware supply chain. SBOM provide comprehensive

inventories of all software dependencies, including

both direct and transitive components, thus offering

a clear view of the software’s structure (Zahan et al.,

2023). This enables teams to monitor the utilisa-

tion of every library, framework, and tool employed,

along with the precise versions integrated into the ap-

plication (Bi et al., 2024). Despite the advantages

they offer, the implementation of SBOM is not with-

out its difﬁculties: the scalability of SBOM in large

and complex projects, and the necessity for expertise

in their creation and maintenance, remain signiﬁcant

challenges (Xia et al., 2023).

Software Component Analysis (SCA) offers an

additional efﬁcient method for monitoring dependen-

cies, assisting organisations in identifying and con-

trolling both open-source and proprietary components

within their software. Tools such as Dependency-

Track (see above) integrate both SCA and SBOM to

provide a uniﬁed solution, thereby enabling organi-

sations to proactively manage dependencies, mitigate

security risks and ensure long-term maintainability.

3.2 Dependant Notiﬁcation

Software dependencies can be represented in a net-

work as a double pyramid. Tracking software depen-

dencies is one side of the double pyramid; the other

see https://dependencytrack.org

see https://www.mend.io

see https://www.sonatype.com

The Impact of the European Product Liability Directive on Software Engineering

629

side is “being tracked” by customers, or dependant

notiﬁcation. If a product has a defect, it should be re-

called and repaired or replaced. In software engineer-

ing, this process is called a software update (Vaniea

and Rashidi, 2016), (Rossel, 2017). The Product Li-

ability Directive provides some defences to liability,

but these defences do not apply in certain cases, for

example, where the defect in the product is caused

by a lack of software updates or upgrades necessary

to maintain the safety of the product (Article 11(2)b,

11(2)c). To be on the safe side in this context, your

software should have mechanisms to (1) track soft-

ware in circulation, (2) reliably notify customers of

updates and implement them, and (3) be able to with-

draw insecure software from circulation.

1. For tracking the software and customer con-

tacts, customer relationship management tools are

available (Payne and Frow, 2016).

2. The notiﬁcation of updates can be realised via

regular automatic update checks. The software

used by the customer checks whether an update

has been provided in the meantime and actively

prompts the customer to install it.

3. Deactivation can also be implemented via up-

date mechanisms, but also via licence mod-

els (Ballhausen, 2019) and licence servers (Fer-

rante, 2006), in which the licence validity check

also checks the software version and deactivates

old/unsecure versions.

4 THIRD PARTY COMPONENT

In order to take account of the implications of the re-

vised Product Liability Directive, a number of avail-

able options may be considered.

4.1 Elimination of Dependence

The term “dead code” is used to describe sections of a

program that have been written but never executed, or

sections of code that have been executed but have no

impact on the program’s output or functionality (Ro-

mano et al., 2020). Its presence results in an increase

in the size of the codebase, which in turn makes the

program more challenging to read, maintain, or de-

bug (Malavolta et al., 2023).

There are a number of ways in which dead code

can arise. This may include unreachable code, errors,

obsolete features, legacy code, and so forth. Although

it does not directly affect the execution of the pro-

gram, it may have a signiﬁcant drawback: the pres-

ence of dead code may result in inadvertent interac-

tions with other components of the codebase, which

could potentially pose a security risk if not prop-

erly isolated. It is therefore recommended that non-

essential libraries be eliminated in order to minimize

the total number of dependencies.

4.2 Contractual Regulation

The directive “does not apply to free and open-source

software that is developed or supplied outside the

course of a commercial activity” (Article 2(2)). This

means that by integrating them into your own soft-

ware product, there may be a liability risk if it is not

also distributed as non-commercial, free and open-

source software. One way to avoid this risk is to use

software commercially. If, for example, a software li-

brary is offered both non-commercially and commer-

cially, the exception does not apply to the commer-

cial version. However, the legal circumstances and

the then applicable regulations must be taken into ac-

count (see Section 2.1 on importers).

4.3 Complete Integration

Another option is to take ownership. In the context

of third-party software libraries, taking ownership in-

volves deeply integrating third-party libraries within

one’s own system (Greiler et al., 2015). This requires

a comprehensive understanding of the library’s func-

tionality and structure. Consequently, it also neces-

sitates maintaining the library’s up-to-date status, en-

suring its reliability, and developing a plan to address

failures or replace it if necessary, in order to align

its usage with the overall stability and goals of the

project. In other words, the external library is treated

in a manner consistent with that of one’s own code,

and thus maintained accordingly (see Section 5).

4.4 Risk Minimisation

In the event that the third-party component is indis-

pensable for functional reasons and removal is not a

viable option, if contractual regulation is not a pos-

sibility, or if taking code ownership does not appear

to be a reasonable course of action (for example, due

to the size of the library), risk minimisation may be

considered as an alternative option.

In the ﬁeld of cybersecurity, software isolation

plays a crucial role in safeguarding computer sys-

tems from potential security threats and mitigating

the risk of damage. It entails limiting the access

and interaction between distinct software components

to prevent unauthorised actions or malicious activi-

ties. There are two principal approaches to achiev-

ENASE 2025 - 20th International Conference on Evaluation of Novel Approaches to Software Engineering

630

ing software isolation: hardware-based isolation and

software-based isolation (Pricop et al., 2020).

Hardware-based isolation employs the underlying

hardware to separate software components. It utilises

the capabilities of modern processors, including vir-

tualisation and memory protection. Software-based

isolation employs software techniques to separate two

or more disparate software components. For example,

operating systems employ a process isolation mecha-

nism that prevents direct access to another process’s

memory or ﬁles. Furthermore, the user rights man-

agement system enables the restriction of access to

the absolute minimum required for a process to func-

tion. Containerisation represents a lightweight form

of virtualisation, whereby software components are

isolated within containers. Both hardware-based and

software-based isolation approaches have their re-

spective advantages and limitations. Hardware-based

isolation offers robust isolation guarantees and is fre-

quently more secure. Nevertheless, it may necessitate

particular hardware infrastructure and may prove to

be less adaptable. Conversely, software-based isola-

tion offers greater ﬂexibility and can be implemented

on a more diverse range of systems.

The prerequisite for the isolation of a software

component into its own process and/or environment is

the limited integration of that component into the soft-

ware system (Richards and Ford, 2020). In the event

that the degree of integration of a third-party compo-

nent is minimal, it can be isolated through the imple-

mentation of software architectures, such as microser-

vices. Consequently, each microservice is capable to

operate in isolation. In contrast, components that are

deeply integrated into the software system present a

signiﬁcant challenge to the implementation of effec-

tive isolation techniques (Shu et al., 2016).

5 FIRST PARTY COMPONENT

This section is concerned with code-level techniques

that help to guarantee that software meets the relevant

quality criteria, such as correctness or reliability.

The following sections are ordered according to

the formal and mathematical training and experience

required for application – from lightweight to heavy-

weight methods. Lightweight tools (see Section 5.1)

are designed to identify generic and simpler property

violations but may report a higher number of false

warnings. Additional tools (see Sections 5.2ff.) allow

one to determine whether violations exist or to verify

more complex properties that a user may specify.

Nevertheless, the demarcation lines between dif-

ferent tools are not entirely distinct, but rather overlap

in both directions. We want to highlight that methods

and tools categorized to be of higher weight do not

replace those that are more lightweight; rather, they

are to be regarded as complementary. To illustrate,

formal veriﬁcation does not supersede the testing of

software. Furthermore, testing can identify errors in

hardware, operating system functions, or compilers.

All of the lightweight tools and many of the other

tools support automation by integration into build sys-

tems; i.e., they can be used as components of contin-

uous integration workﬂows. Consequently, software

teams are able to identify and respond to issues within

the context of their usual operational procedures.

5.1 Lightweight Methods

To guarantee that software meets the required qual-

ity standards, a number of methodologies can be em-

ployed, including code reviews, unit testing, and inte-

gration testing. In addition, lightweight static analysis

techniques may be utilised, which are primarily con-

cerned with the identiﬁcation of code smells through

the use of syntactic pattern matching and potentially

simple control-ﬂow and data-based analysis.

Code reviews are conducted by other team mem-

bers with the objective of evaluating the effectiveness

of code modiﬁcations in achieving the desired func-

tionality or addressing identiﬁed issues. To enable re-

viewers to concentrate on potential enhancements or

issues within the program logic, it is advisable that

code reviews do not primarily focus on code style au-

dits (code formatters can automatically ensure adher-

ence to code style guidelines and formatting rules).

The level of effort and formality associated with code

reviews can vary considerably, spanning the spectrum

from more traditional, structured approaches char-

acterised by strict adherence to checklists and de-

tailed scrutiny, as exempliﬁed by the methodology

proposed by (Beller et al., 2014), to more stream-

lined, lightweight techniques employed in numerous

open-source software development projects. Code re-

views are facilitated by hosting sites such as GitLab

and GitHub, which provide views of the code changes

and enable reviewers to place their comments and

suggestions directly adjacent to the relevant changes.

Code reviews have been demonstrated to be an effec-

tive method for reducing the number of bugs encoun-

tered after a release. However, potential issues must

be taken into account (McIntosh et al., 2014; dos San-

tos and Nunes, 2018).

Once unit and integration tests have been written,

their regular execution can be automated. Provided

that sufﬁcient code coverage has been achieved, they

offer conﬁdence that the software works as intended

The Impact of the European Product Liability Directive on Software Engineering

631

for major use cases. Furthermore, a rigorous process

of running automated tests automatically after code

changes can also detect regressions. Numerous test-

ing frameworks are available tailored to speciﬁc pro-

gramming languages and deployment platform; such

as JUnit

, GoogleTest

, and Cucumber

Lightweight analysis tools (“linters”) analyse

source code for a range of issues, including, but not

limited to, correctness, security, and concurrency is-

sues. Subsequently, the tools generate a report that

can be accessed and the identiﬁed issues can then be

addressed. The majority of these tools can be con-

ﬁgured such that reported issues are relevant bene-

ﬁcial warnings, while reducing the number of false

positives. Such tools can be integrated into a contin-

uous integration framework and executed automati-

cally following, for example, each commit sequence.

The option of deﬁning a baseline (enabling the anal-

ysis of only new code or code changes) permits the

gradual introduction of these tools into a legacy code-

base, thus avoiding the necessity of addressing thou-

sands of warnings. Popular tools in this category are

SpotBugs

, SonarQube

, PMD

, and many more.

5.2 Mediumweight Methods

Employing extended static analysis tools that are

based on more sophisticated analysis techniques, such

as symbolic execution or abstract interpretation, is a

notable advancement. These tools offer more precise

and comprehensive coverage of properties. Moreover,

they are capable of checking for more complex prop-

erties, which may necessitate greater computational

power and time. Some of the tools may require sup-

plementary user annotations at code level, which con-

sequently necessitates software engineers to under-

stand the approach of the underlying analysis. How-

ever, this increases the accuracy of the tools and re-

duces the occurrence of false warnings.

The Checker Framework

offers pluggable type

checking for Java and provides predeﬁned type-based

analyses to prevent errors associated with null point-

ers, resource leaks, lock checking (to avoid speciﬁc

concurrency errors), and other issues. The software

developer must provide additional type annotations,

like @NonNull, for ﬁelds that cannot be null.

see https://junit.org

see https://github.com/google/googletest

see https://cucumber.io/tools/cucumber-open

see https://spotbugs.github.io

see https://www.sonarsource.com

see https://pmd.github.io

see https://checkerframework.org

FBInfer

is a static analyser developed and

utilised by Facebook. The tool is based on separa-

tion logic and bi-abduction to identify intricate issues

within the source code, necessitating the examina-

tion of call chains. The following issues are among

those that the tool can detect: livenesses, resource

consumptions, buffer overruns, and memory safety is-

sues. It offers support for C, C++, Objective-C, and

Java. In contrast to the Checker Framework, it does

not require the user to provide annotations.

Other analysis tools are capable of identi-

fying complex errors. One such a tool is

ENTROPOSCOPE (D

orre and Klebanov, 2016),

which is designed to analyse pseudo-random gener-

ators for entropy loss. It has been used to iden-

tify potential security vulnerabilities in GnuPG and

Libgcrypt (CVE-2016-6313) as well as in NSS/Fire-

fox (CVE-2017-5462).

5.3 Heavyweight Methods

For software modules that require a high degree

of conﬁdence in their correctness, logic-based ap-

proaches such as model checking and deductive ver-

iﬁcation are to be considered. Model checking is

applicable across the majority of software activities,

from design phase to implementation. In particular,

it can be applied when designing protocols (e.g., key

exchange protocols) to verify speciﬁc properties.

CPAChecker

is a software model checker

that automatically analysis programs and identiﬁes

generic issues and user speciﬁed property viola-

tions (Baier et al., 2024). The properties to be ver-

iﬁed can be provided in the form of hand-crafted

speciﬁcation-automaton ﬁles. CPAChecker is also ca-

pable of checking for functional (data-related) errors

by examining runs that may violate program asser-

tions. It generates witnesses (test cases) that trigger

such violations, facilitating the comprehension of the

underlying issue. The witnesses can be used as sup-

plementary regression test cases.

The preceding tools do not typically guarantee

correctness; however, they are useful for identifying

bugs. In particular, the latter provides a high degree

of assurance regarding the quality of the software.

We conclude with an examination of a tool cate-

gory that provides mathematical proof of a program’s

adherence to its speciﬁcation. One should be aware

that such guarantees are relative to often implicit as-

sumptions like the absence of hardware or compiler

errors. A comprehensive examination of these limita-

tions can be found in (Livshits et al., 2015).

see https://fbinfer.com

see https://cpachecker.sosy-lab.org

ENASE 2025 - 20th International Conference on Evaluation of Novel Approaches to Software Engineering

632

The speciﬁcation of program units (e.g., methods)

can be achieved with contracts, as outlined by (Meyer,

1992). Method contracts state prerequisites that must

be fulﬁlled by the caller at invocation time. If these re-

quirements are satisﬁed, the method ensures that upon

completion the resulting state satisﬁes the properties

speciﬁed by the contract’s postcondition.

Such speciﬁcations permit to express complex

functional properties that can be proven correct us-

ing deductive veriﬁcation systems such as Frama-C

GNATProve

, KeY

, or VerCors

Although these techniques have their origins in

academia, they have been successfully applied in in-

dustry and used in real-world case studies. To il-

lustrate, Dafny (Leino, 2013), a programming lan-

guage designed for the veriﬁcation of software, is

used by Amazon to validate components within their

web services. Another tool, KeY (Ahrendt et al.,

2016), has been used to verify several methods of

the Java Standard Library, including the sorting algo-

rithm for reference types, TimSort. The analysis car-

ried out by KeY revealed the presence of a persistent

bug in the underlying algorithm. A proposed solu-

tion was implemented and subsequently veriﬁed to be

correct (de Gouw et al., 2019). Similarly, case stud-

ies have identiﬁed errors in the Java standard library.

Furthermore, the sequential version of the ips

o sort-

ing algorithm has been implemented in Java and ver-

iﬁed to be correct (Beckert et al., 2024). It offers one

of the fastest provably correct sequential algorithms.

Finally, proof assistants like Coq

,Lean

, or Is-

abelle

, are highly expressive but require signiﬁcant

expertise in formal methods.

6 CONCLUSION

The modernisation of the Product Liability Directive

serves to enhance the accountability of commercial

software providers. We examined its implications in

the context of the software producer and surveyed

approaches to (i) dependency tracking to ensure that

the software producer is in a position to react to de-

fects in used third-party components; and (ii) soft-

ware quality assurance tools to identify a wide vari-

ety of software defects before release. Therefore, in

order to maximise readiness, the period prior to the

see https://frama-c.com

see https://www.adacore.com/sparkpro

see https://www.key-project.org

see https://vercors.ewi.utwente.nl

see https://coq.inria.fr

see https://lean-lang.org

see https://isabelle.in.tum.de

implementation of the Directive should be used for

proactive preparation, allowing software producers to

adapt their processes and effectively mitigate poten-

tial risks.

ACKNOWLEDGEMENTS

The work in this paper has received funding from the

Austrian Research Promotion Agency (FFG) under

Grant Agreement no. FO999899544; project “PRE-

dictions for Science, Engineering N’ Technology –

PRESENT”.

Furthermore, the work was supported by the DFG

project “Forschungssoftware KeY” (BU 2924/3-1,

HA 2617/9-1) and the ATHENE project “Model-

centric Deductive Veriﬁcation of Smart Contracts”.

REFERENCES

Ahrendt, W., Beckert, B., Bubel, R., H

ahnle, R., Schmitt,

P. H., and Ulbrich, M., editors (2016). Deductive Soft-

ware Veriﬁcation - The KeY Book – From Theory to

Practice. Springer.

Baier, D., Beyer, D., Chien, P., Jakobs, M., Jankola, M.,

Kettl, M., Lee, N., Lemberger, T., Rosenfeld, M. L.,

Wachowitz, H., and Wendler, P. (2024). Software

Veriﬁcation with CPAchecker 3.0: Tutorial and User

Guide. Formal Methods FM (LNCS), 14934:543–570.

Ballhausen, M. (2019). Free and Open Source Software

Licenses Explained. Computer, 52:82–86.

Beckert, B., Sanders, P., Ulbrich, M., Wiesler, J., and Witt,

S. (2024). Formally Verifying an Efﬁcient Sorter.

International Conference on Tools and Algorithms

for the Construction and Analysis of Systems TACAS

(LNCS), 14570:268–287.

Beller, M., Bacchelli, A., Zaidman, A., and J

urgens, E.

(2014). Modern code reviews in open-source projects:

which problems do they ﬁx? Working Conference on

Mining Software Repositories, 11:202–211.

Bentaleb, O., Belloum, A. S. Z., Sebaa, A., and El-

Maouhab, A. (2022). Containerization technologies:

taxonomies, applications and challenges. Journal of

Supercomputing, 78:1144–1181.

Bi, T., Xia, B., Xing, Z., Lu, Q., and Zhu, L. (2024). On

the Way to SBOMs: Investigating Design Issues and

Solutions in Practice. ACM Transactions on Software

Engineering and Methodology, 33:149:1–25.

de Gouw, S., de Boer, F. S., Bubel, R., H

ahnle, R., Rot,

J., and Steinh

ofel, D. (2019). Verifying OpenJDK’s

Sort Method for Generic Collections. Journal of Au-

tomated Reasoning, 62:93–126.

do Amaral, T. M. S. and Gondim, J. J. C. (2021). Integrating

Zero Trust in the cyber supply chain security. Work-

shop on Communication Networks and Power Systems

(WCNPS), 5:1–6.

The Impact of the European Product Liability Directive on Software Engineering

633

orre, F. and Klebanov, V. (2016). Practical Detection of

Entropy Loss in Pseudo-Random Number Generators.

ACM SIGSAC Conference on Computer and Commu-

nications Security, 23:678–689.

dos Santos, E. W. and Nunes, I. (2018). Investigating the

effectiveness of peer code review in distributed soft-

ware development based on objective and subjective

data. Journal of Software Engineering Research and

Development, 6:14.

Enck, W. and Williams, L. (2022). Top Five Challenges in

Software Supply Chain Security: Observations From

30 Industry and Government Organizations. IEEE Se-

curity & Privacy, 20:96–100.

Everson, D., Cheng, L., and Zhang, Z. (2022). Log4shell:

Redeﬁning the Web Attack Surface. Workshop on

Measurements, Attacks, and Defenses for the Web

(MADWeb), 4:23010:1–8.

Ferrante, D. (2006). Software Licensing Models: What’s

Out There? IT Professional, 8:24–29.

Greiler, M., Herzig, K., and Czerwonka, J. (2015). Code

Ownership and Software Quality: A Replication

Study. IEEE/ACM Working Conference on Mining

Software Repositories, 12:2–12.

Islam, S., Gaikovina Kula, R., Treude, C., Chinthanet, B.,

Ishio, T., and Matsumoto, K. (2023). An Empirical

Study of Package Management Issues via Stack Over-

ﬂow. IEICE Transactions on Information and Sys-

tems, E106-D:138–147.

Leino, K. R. M. (2013). Developing Veriﬁed Programs with

Dafny. International Conference on Software Engi-

neering, ICSE, 35:1488–1490.

Livshits, B., Sridharan, M., Smaragdakis, Y., Lhot

ak, O.,

Amaral, J. N., Chang, B. E., Guyer, S. Z., Khedker,

U. P., Møller, A., and Vardoulakis, D. (2015). In de-

fense of soundiness: a manifesto. Communications of

the ACM, 58:44–46.

Malavolta, I., Nirghin, K., Scoccia, G. L., Romano, S.,

Lombardi, S., Scanniello, G., and Lago, P. (2023).

JavaScript Dead Code Identiﬁcation, Elimination, and

Empirical Assessment. IEEE Transactions on Soft-

ware Engineering, 49:3692–3714.

Mart

ınez, J. and Dur

an, J. M. (2021). Software supply chain

attacks, a threat to global cybersecurity: SolarWinds’

case study. International Journal of Safety and Secu-

rity Engineering, 11:537–545.

McIntosh, S., Kamei, Y., Adams, B., and Hassan, A. E.

(2014). The impact of code review coverage and code

review participation on software quality: a case study

of the qt, VTK, and ITK projects. Working Conference

on Mining Software Repositories, 11:192–201.

Meyer, B. (1992). Applying “Design by Contract”. IEEE

Computer, 25:40–51.

Mooduto, A., Rijanto, E., and Pamuji, G. C. (2023). Op-

timization of Software Development Automation via

CICD, Dependency Track, and AWS CodePipeline

Integration. International Conference on Informatics

Engineering, Science & Technology, 1:1–7.

Neupane, S., Holmes, G., Wyss, E., Davidson, D., and

Carli, L. D. (2023). Beyond Typosquatting: An In-

depth Look at Package Confusion. USENIX Security

Symposium, 32:3439–3456.

Open Worldwide Application Security Project (2020). Soft-

ware Component Veriﬁcation Standard. OWASP

Foundation, 1st edition.

Parlog, N. (2019). The Java Module System. Manning Pub-

lications, 1st edition.

Pashchenko, I., Vu, D.-L., and Massacci, F. (2020). A

Qualitative Study of Dependency Management and Its

Security Implications. ACM SIGSAC Conference on

Computer and Communications Security, 27:1513–

1531.

Payne, A. and Frow, P. (2016). The Marketing Book. Taylor

& Francis Group, 7th edition.

Pricop, E., Fattahi, J., Dutta, N., and Ibrahim, M. (2020).

Recent Developments on Industrial Control Systems

Resilience. Springer Cham, 1st edition.

Richards, M. and Ford, N. (2020). Fundamentals of

Software Architecture – An Engineering Approach.

O’Reilly Media, Inc, 1st edition.

Romano, S., Vendome, C., Scanniello, G., and Poshyvanyk,

D. (2020). A Multi-Study Investigation into Dead

Code. IEEE Transactions on Software Engineering,

46:71–99.

Rossel, S. (2017). Continuous Integration, Delivery, and

Deployment: Reliable and faster software releases

with automating builds, tests, and deployment. Packt

Publishing Ltd., 1st edition.

Shu, R., Wang, P., Gorski III, S. A., Andow, B., Nadkarni,

A., Deshotels, L., Gionta, J., Enck, W., and Gu, X.

(2016). A Study of Security Isolation Techniques.

ACM Computing Surveys, 49:50:1–37.

Tran, N. K., Pallewatta, S., and Babar, M. A. (2024).

An Empirically Grounded Reference Architecture for

Software Supply Chain Metadata Management. Inter-

national Conference on Evaluation and Assessment in

Software Engineering, 28:38–47.

Vaniea, K. and Rashidi, Y. (2016). Tales of Software Up-

dates: The process of updating software. Conference

on Human Factors in Computing Systems, 35:3215–

3226.

Watada, J., Roy, A., Kadikar, R., Pham, H., and Xu, B.

(2019). Emerging Trends, Techniques and Open Is-

sues of Containerization: A Review. IEEE Access,

7:152443–152472.

Wieland, A. and Wallenburg, C. M. (2015). Dealing with

supply chain risks: Linking risk management prac-

tices and strategies to performance. International

Journal of Physical Distribution & Logistics Manage-

ment, 42:887–905.

Xia, B., Bi, T., Xing, Z., Lu, Q., and Zhu, L. (2023). An

Empirical Study on Software Bill of Materials: Where

We Stand and the Road Ahead. IEEE/ACM Inter-

national Conference on Software Engineering (ICSE),

45:2630–2642.

Zahan, N., Lin, E., Tamanna, M., Enck, W., and Williams,

L. (2023). Software Bills of Materials Are Required.

Are We There Yet? IEEE Security & Privacy, 21:82–

88.

ENASE 2025 - 20th International Conference on Evaluation of Novel Approaches to Software Engineering

634