Integrating Security into the Product-Line-Engineering Framework: A

Security-Engineering Extension

Christian Biermann

1,2

, Richard May

and Thomas Leich

Harz University of Applied Sciences, Wernigerode, Germany

Msg Systems ag, München, Germany

Keywords:

Product-Line Engineering, Security Engineering, Security, Business Processes, Framework.

Abstract:

Modern software systems are becoming increasingly conﬁgurable, often relying on Product-Line Engineering

(PLE) to efﬁciently develop variant-rich systems while ensuring reusability. However, security considerations

in existing PLE research are typically insufﬁcient as security is often (partly) neglected or not integrated

into the overall development process. To address this gap, we developed an additional layer of the PLE

framework: security engineering — positioned between domain engineering and application engineering. Our

results are based on a systematic review of 49 secure PLE frameworks and workﬂows, synthesizing their

insights and our expertise in compliance with the ISO/IEC 27000 series. By following six processes and 12

activities, our iterative approach ensures that security is systematically embedded in the PLE process. We

particularly highlight the importance of reusable security artifacts, secure business-process modeling, and

standard compliance, aiming to facilitate the transfer of theoretical solutions into secure business practice.

1 INTRODUCTION

Modern software systems are becoming increasingly

conﬁgurable, i.e., they are based on a variety of

features which can be disabled, enabled, or com-

bined (Abal et al., 2018). In this context, they often

build on concepts and techniques related to Product-

Line Engineering (PLE) as an established approach

for developing and maintaining conﬁgurable software

systems. In particular, PLE supports the creation of

product families with similar but adapted functionali-

ties, optimizing development efﬁciency (i.e., reusabil-

ity, maintenance) and reducing development time and

costs (Pohl et al., 2005; Apel et al., 2013). This ap-

proach has already shown its beneﬁts in various do-

mains, for example, manufacturing (Iglesias et al.,

2017), healthcare (Gomes et al., 2012), or Enterprise-

Resource-Planning (ERP) (May et al., 2023a).

In recent years, conﬁgurable systems have be-

come increasingly complex, involving a wide diver-

sity of data, features, business processes, as well

as associated interactions, conﬁgurations, and depen-

dencies (Mellado et al., 2014; May et al., 2023a).

However, due to this complexity, the potential to fall

victim to a cyberattack is constantly increasing (Abal

et al., 2018). More speciﬁcally, the more complex

(i.e., conﬁgurable) the systems are, the greater the risk

of unexpected vulnerabilities and their exploitation by

cyberattacks due to potential misconﬁgurations, unin-

tended features interactions, or unknown dependen-

cies. Therefore, increasing variability leads to major

challenges related to IT security (Mesa et al., 2018;

Kenner et al., 2021).

This is why current research already considers

parts of secure PLE, such as feature veriﬁcation,

or broader PLE workﬂows, such as requirements-

engineering frameworks (cf. Section 6). However,

recent studies (Kenner et al., 2021; May et al., 2022,

2023b, 2024a) have already identiﬁed a lack of (holis-

tic) security considerations in PLE, i.e., security is

typically only referred to as a non-functional require-

ment or quality objective rather than a cross-cutting

concern equally important as other functional require-

ments. This treatment usually leads to an under-

representation of security in the PLE processes and

activities. Although some frameworks already con-

sider security on a somewhat equal level with other

functional requirements and associated features, they

usually only focus on a few parts of the PLE pro-

cess, such as security veriﬁcation with CyberSPL

by Varela-Vaca et al. (2019). In addition, current so-

lutions often do not comply with security standards,

such as ISO/IEC 27000 (2022), impairing the transfer

of theoretical approaches into business practice. This

Biermann, C., May, R. and Leich, T.

Integrating Security into the Product-Line-Engineering Framework: A Security-Engineering Extension.

DOI: 10.5220/0013489500003964

In Proceedings of the 20th International Conference on Software Technologies (ICSOFT 2025), pages 75-86

ISBN: 978-989-758-757-3; ISSN: 2184-2833

ﬁnding does not only refer to certain domains, instead

it represents a critical cross-domain gap (e.g., in man-

ufacturing).

To address this gap, we developed an extension

of the PLE framework (Pohl et al., 2005) by ana-

lyzing and synthesizing 49 existing frameworks and

workﬂows (Nickerson et al., 2013) supporting secure

PLE. In particular, we ensured that the entire exten-

sion complies with the requirements of the ISO/IEC

27000 (2022) series. As a result, we propose an

additional PLE layer between domain engineering

and application engineering, called security engineer-

ing. We argue that the extension is currently domain-

independent, but may be easily adaptable to certain

domains by considering domain-speciﬁc standards

and regulations in the problem space (cf. Section 4).

Overall, we contribute the following:

• An overview of current research regarding secu-

rity in the context of PLE frameworks.

• An additional, standard-compliant layer of PLE,

called security engineering, comprising six pro-

cesses and 12 activities.

• An open-access repository including the extrac-

tion sheet to allow study replications.

With our work, we aim to create a broader under-

standing of how security concerns can be holistically

considered in PLE. Moreover, we believe that security

engineering can support both researchers and prac-

titioners regarding the transfer of theoretical knowl-

edge into business practice, ensuring compliance with

security standards. However, note that the PLE frame-

work including our extension is not yet validated, al-

though it is based on peer-reviewed information in

most parts.

In the remainder of this paper, we organize the

content as follows: First, Section 2 provides an

overview of the relevant background. After that, in

Section 3, we detail our methodology and present a

summary of our development steps. Section 4 intro-

duces the our extension of the PLE framework. In

Section 5, we discuss further implications and address

potential threats to the internal and external validity.

Then, in Section 6, we review related work, and ﬁ-

nally, Section 7 concludes the paper.

2 BACKGROUND

Next, essential background information on PLE and

security management are provided.

https://doi.org/10.5281/zenodo.14748327

2.1 Product-Line Engineering

PLE is an established methodology for developing

software-product families that share common char-

acteristics and features, built on a shared core archi-

tecture and conﬁgured for speciﬁc needs (Pohl et al.,

2005; Thüm et al., 2014). Its primary goals are to op-

timize software development by improving efﬁciency

and reusability, reducing costs, and accelerating de-

velopment (van der Linden et al., 2007). A key as-

pect of PLE is managing software variability to tailor

products to speciﬁc requirements. Feature models are

used to represent and conﬁgure both static and dy-

namic variability, enabling systematic reuse of soft-

ware artifacts and automated product derivation (Ba-

tory, 2004; Apel et al., 2013). However, PLE intro-

duces complexity, requiring specialized strategies to

verify system correctness. Feature-based, product-

based, and family-based analyses address variability

challenges in different domains (Thüm et al., 2014).

Security requirements, often cross-cutting functional

variability, require holistic strategies that integrate se-

curity into both domain and application engineering

to ensure the quality, reliability, and security of de-

rived products (Horcas et al., 2019; May et al., 2025).

2.2 Security Management

Security management is a business-critical compo-

nent of software systems, requiring a holistic ap-

proach to protect their assets. At its core lies the

CIA triad, encompassing the security goals of con-

ﬁdentiality, integrity, and availability (Samonas and

Coss, 2014). These principles form the foundation

of widely recognized standards such as the ISO/IEC

27000 (2022) guiding organizations in achieving ro-

bust security in practice. IT security focuses on pro-

tecting software systems and their associated assets

from threats, for example, including breaches, unau-

thorized access, or data manipulation (NIST SP 800-

30r1, 2012; ISO/IEC 27000, 2022). Threats are typ-

ically identiﬁed by monitoring systems and vulner-

ability databases (NIST SP 800-150, 2016), while

risks are related to their potential impact and like-

lihood (ISO/IEC 27000, 2022). Vulnerabilities, i.e.,

weaknesses exploitable by attacks or system failures,

are key to understanding risks. Effective risk man-

agement integrates security activities across all phases

of the software-development lifecycle to meet secu-

rity requirements and ensure an acceptable level of

risk (NIST SP 800-30r1, 2012).

ICSOFT 2025 - 20th International Conference on Software Technologies

Definition of

Identification of characteristics

Abstract selectionTitle/

502

Snowballing selection

Empirical-to-conceptual

Conceptual-to-empirical

ISO/IEC 27000 series

Own experiences and

Full-text selection

authors

Discussions among

reordering characteristics

Adding, renaming, and

iterations

Revision of characteristics

meta-characteristics

Specification of

meta-characteristics

Synthesis of

characteristics

Evaluation of

ending condition

fulfillment

Final

extension

ACM IEEE Xplore Scopus

Characteristics extraction

fulfilled ending

conditions

Figure 1: Method overview; numbers indicate amount of papers or characteristics (dark circled), i.e., processes and activities.

3 METHOD

In the following section, we describe the method of

our study (i.e., design and conduct).

3.1 Design

The framework extension builds on the methodology

proposed by Nickerson et al. (2013), which offers

guidelines for developing frameworks, making it par-

ticularly well-suited to our context. The method in-

volved three main steps:

Meta-Characteristics. First, meta-characteristics

were deﬁned to capture engineering processes and ac-

tivities concerning IT security and PLE. We focus

exclusively on security engineering as a third per-

spective, complementing domain and application en-

gineering. Security engineering builds on domain

engineering results and provides requirements and

features for application engineering, ensuring equal

consideration of functional and secure development.

We distinguish three perspectives: the problem space

(i.e., domain-speciﬁc abstractions such as require-

ments), the solution space (i.e., realization of these

abstractions), and the mapping (i.e., conﬁguration op-

tions to adapt abstractions to speciﬁc contexts) (Berg

et al., 2005).

Ending Conditions. Second, ending conditions (E

)

ensure the methodological process maintains high

quality (Nickerson et al., 2013). Eight conditions

were considered: four objective criteria ensure unique

characteristics (E

), original context is preserved

), no merging in the last iteration (E

), and no ad-

ditions in the last iteration (E

). Four subjective crite-

ria ensure robustness (E

), completeness (E

), adapt-

ability (E

), and explainability (E

Characteristics Development. Third, characteris-

tics were developed iteratively using an empirical-to-

conceptual approach (Nickerson et al., 2013), sup-

ported by a systematic literature review (Kitchenham

et al., 2015). We focused on secure PLE frameworks

and workﬂows rather than speciﬁc engineering pro-

cesses. The following search string was formulated:

("secur*") AND ("framework" OR "taxonomy"

OR "engineering" OR "pattern" OR "process"

OR "approach" OR "architecture") AND

("product line")

Inclusion/exclusion criteria limited research to

peer-reviewed work (2005–2024) with at least four

pages, excluding studies not focused on secure PLE

frameworks or workﬂows. On November 1, 2024, the

second author conducted an automated search across

ACM GUIDE TO COMPUTING LITERATURE (21 ar-

ticles), IEEE XPLORE (100 articles), and SCOPUS

(381 articles), yielding 502 results. After title/abstract

screening, 47 papers remained. Two iterations of for-

ward and backward snowballing added nine more pa-

pers. After full-text review, 49 papers were included

(cf. Figure 1 and Table 1).

The selected works were analyzed using the de-

ﬁned meta-characteristics, and processes and activi-

ties were abstracted and synthesized. The ﬁrst and

second authors discussed these results, evaluating

them against the ending conditions. All conditions

except E

, E

, and E

were met. This iter-

ation produced the ﬁrst extension version, including

14 characteristics (six processes, eight activities).

Subsequent iterations used a conceptual-to-

empirical approach (Nickerson et al., 2013), rely-

ing on the authors’ expertise and the ISO/IEC 27000

(2022) standards. Four activities related to secu-

rity testing were iteratively added, reordered, and re-

named. Each iteration included discussions using an

open-card sorting method and evaluations of ending

Integrating Security into the Product-Line-Engineering Framework: A Security-Engineering Extension

condition fulﬁllment. After three iterations, the ﬁnal

extension consisted of six processes and 12 activities

(cf. Figure 1 and Figure 2).

4 SECURITY ENGINEERING

To address security concerns throughout the PLE de-

velopment, we present our framework extension: se-

curity engineering (cf. Figure 2). The six identiﬁed

processes and 12 activities, classiﬁed into the three

key perspectives of problem space, mapping, and so-

lution space are described in detail below.

4.1 Problem Space

The problem space focuses on understanding (i.e., an-

alyzing) and deﬁning the security landscape as well

as the architecture. This perspective is crucial since it

sets the foundation for all subsequent security efforts.

Security Analysis. The security analysis is the ﬁrst

step in addressing security concerns in product lines.

It involves a detailed examination of the domain to

identify legal requirements, stakeholder expectations,

potential risks, and threats.

One of the activities in this process is the anal-

ysis of domain legal regulations. This involves un-

derstanding the legal and regulatory frameworks that

apply to more general domains, such as the ISO/IEC

27000 (2022) series for information security, or spe-

ciﬁc domains, such as the Health Insurance Portabil-

ity and Accountability Act (Fernandez et al., 2015)

in healthcare. Here, it is highly important to identify

relevant guidelines and restrictions to align the over-

all security concept with them, ensuring compliance

with legal obligations.

Another activity in security analysis is the domain

requirements identiﬁcation, which is similar to the

procedure in the traditional domain engineering (Pohl

et al., 2005; Reinhartz-Berger et al., 2013), however,

focusing on security. This step includes capturing

the speciﬁc security needs of stakeholders involved

in the development process of a speciﬁc system, such

as requirements linked to assets and features of cyber-

physical systems (Varela-Vaca et al., 2021).

Closely connected to the domain requirements,

domain threats and risks must be systematically iden-

tiﬁed and analyzed. This activity involves conduct-

ing preventive risk assessments and threat model-

ing to understand the vulnerabilities present within

the domain and prioritize their mitigation. Here,

established frameworks, such as STRIDE, DREAD,

SQUARE (Achour et al., 2015b), or Magerit (Mel-

lado et al., 2010), provide robust guidelines. Other,

less complex approaches may also be feasible, includ-

ing UML modeling, activity models (Fernandez et al.,

2015), or trade-off analyses (Sánchez et al., 2014).

Due to the increasing integration of third-party

services, such as cloud services, they also play a sig-

niﬁcant role in security analysis. Many software sys-

tems rely on external services for functionality, intro-

ducing potential security vulnerabilities (May et al.,

2023a). Evaluating these services for compliance,

trustworthiness, and risks is essential to ensure that

they do not become a weakness in the system’s secu-

rity. For instance, the integration of third-party com-

ponents, such as data processors of Internet-of-Things

devices, requires a careful assessment of their security

features and compliance with domain-speciﬁc stan-

dards (Tomashchuk et al., 2021).

Security Design. Building on the ﬁndings of the se-

curity analysis, the security design process focuses on

creating detailed speciﬁcations and strategies to ad-

dress the identiﬁed security challenges and demands.

This process ensures that security is embedded into

the system from the outset and not added as an af-

terthought in the context of an optional quality at-

tribute or non-functional requirement. Note that this

process includes comprehensive testing (i.e., veriﬁca-

tion, validation) of all activities.

One of the primary activities in security design is

the adoption of security standards, heavily building

on the results of the security analysis concerning legal

regulations. By leveraging established frameworks

such as ISO/IEC 27001 (Mellado et al., 2010), the

NIST cyber security framework (Wilson and Young,

2020), or the OWASP guidelines (Varela-Vaca et al.,

2020), it can ensured that their security design aligns

with industry best practices. These standards provide

a foundation for deﬁning security objectives (i.e., con-

ﬁdentiality, integrity, availability) and evaluating their

implementation (Fægri and Hallsteinsen, 2006).

Security Requirements are another critical activ-

ity of this process. Derived from the domain analy-

sis, these requirements specify what the system must

achieve to protect itself against identiﬁed threats and

risks. Examples include ensuring the goals of in-

formation security, i.e., conﬁdentiality, integrity, and

availability (Fægri and Hallsteinsen, 2006). These

goals typically lead to associated requirements to be

fulﬁlled, for example, through encryption (Fernandez

et al., 2015), access controls (Fernandez et al., 2016),

or redundancy mechanisms (Fægri and Hallsteinsen,

2006). Security requirements can be represented and

prioritized in different ways, ranging from decision or

feature models (Mellado et al., 2010) over goal-based

models (Kim et al., 2008) and reusable patterns (Fer-

nandez et al., 2016) to artifact annotations and con-

ICSOFT 2025 - 20th International Conference on Software Technologies

Table 1: Overview of the security-engineering process (italic) and activity fulﬁllment.

Security analysis Security design Security testing

Reference

Domain legal

regulations

Domain

requirements

Domain threats and

risks

Third-party services

Security standards

Security

requirements

Data protection

Business processes

Security policy

modeling & design

Security realization

Compliance

Conﬁgurations &

dependencies

Incident

management

Source code

Documentation

Iqbal et al. (2024)

May et al. (2023a)

Varela-Vaca et al. (2023)

Tomashchuk et al. (2021)

Varela-Vaca et al. (2021)

Williams et al. (2020)

Navas et al. (2020)

Young et al. (2020)

Adejokun and Siok (2020)

Varela-Vaca et al. (2020)

ter Beek et al. (2020)

Wilson and Young (2020)

Horcas et al. (2019)

Varela-Vaca et al. (2019)

Horcas et al. (2018)

Ya’u et al. (2018)

Sprovieri et al. (2017)

Alam et al. (2017)

Fernandez et al. (2016)

Sion et al. (2016)

Varela-Vaca and Gasca (2015)

Myllärniemi et al. (2015)

Achour et al. (2015b)

Achour et al. (2015a)

Fernandez et al. (2015)

Sánchez et al. (2014)

Mellado et al. (2014)

Hammani et al. (2014)

Horcas et al. (2013)

Villela et al. (2012)

Tan et al. (2012)

Murwantara (2012)

Guana and Correal (2012)

Yu et al. (2012)

Zhang et al. (2011)

Ines et al. (2011)

Trujillo et al. (2011)

Rodríguez et al. (2011)

Mellado et al. (2010)

Mellado et al. (2009)

Mellado et al. (2008c)

Mellado et al. (2008d)

Mellado et al. (2008b)

Mellado et al. (2008a)

Etxeberria and Sagardui (2008)

Kim et al. (2008)

Hundt et al. (2007)

Mellado et al. (2007)

Fægri and Hallsteinsen (2006)

ISO/IEC 27000 (2022)

Fulﬁlled Not fulﬁlled

Integrating Security into the Product-Line-Engineering Framework: A Security-Engineering Extension

Security

realization

Security analysis

Security design

Business

processes

Security

requirements

Security

standards

Data

protection

Domain legal

regulations

Domain

requirements

Domain

threats & risks

Third party

services

Security policy

modeling &

design

Security testing

Compliance

Incident

management

Source

code

Configurations

& dependencies

Problem space Mapping

Solution space

testing

Documentation

Figure 2: Overview of iterative security-engineering extension structured according to problem space, mapping, and solution

space; including 18 characteristics, i.e., six processes (italic) and 12 activities.

straints (Villela et al., 2012).

Additionally, Data protection strategies are de-

ﬁned during the security design process, mainly refer-

ring to the speciﬁcation of mechanisms related to data

privacy, for example, using protocols including cer-

tain certiﬁcates (Mellado et al., 2008d) or enforcing

encryption and authentication mechanisms (Varela-

Vaca et al., 2019). Here, several relationships arise

regarding the compliance with legal regulations, such

as the GDPR (Tomashchuk et al., 2021).

Furthermore, security has to be considered regard-

ing a system’s business processes, such as control-

ling analyses (May et al., 2023a) or supply chain re-

plenishment (Wilson and Young, 2020). This activ-

ity involves modeling workﬂows in Uniﬁed Modeling

Language (UML) or as Business Process Model and

Notation (BPMN), incorporating security steps with-

out disrupting operational efﬁciency. Here, security

measures should be designed so that they also miti-

gate risks. For example, Segregation of Duty (SoD),

i.e., the separation of permissions in processes such as

sales, ensures that a single role cannot simultaneously

create orders, modify customer data, and approve in-

voices (Kobelsky, 2014). However, permissions and

workﬂows must be designed in a way that maintains

process efﬁciency. Paradigms such as role-based ac-

cess control can help align security with efﬁciency.

4.2 Mapping

The mapping perspective serves as a bridge between

the problem space and the solution space, involving

abstracting the outcomes of the security analysis and

design processes into actionable policies and models

that guide the implementation of security measures.

Security Policy Modeling and Design. The funda-

mental process of the mapping is security policy mod-

eling and design. It involves creating abstract models

that deﬁne the system’s security rules, goals, and con-

straints, including it’s business processes. These are

represented in different systematic ways. A more tra-

ditional way is related to security rules based on nat-

ural language (Varela-Vaca et al., 2019). Others refer

to more logical representations, such as conﬁguration

rules (Guana and Correal, 2012), graph-related repre-

sentations, such as feature models (Rodríguez et al.,

2011) or attack trees to deﬁne constraints (ter Beek

et al., 2020). As a further result of this phase, con-

crete reusable artifacts (Mellado et al., 2010) or ar-

chitectural patterns (Fernandez et al., 2016) can be

developed, serving as a reference for further core as-

sets related to security. Note that comprehensive test-

ing (i.e., veriﬁcation, validation) of created policies is

key to ensure their reliability.

4.3 Solution Space

The solution space focuses on implementing, verify-

ing, and validation the security requirements and as-

sociated features deﬁned in the previous processes. It

includes two primary processes: security realization

and security testing.

Security Realization. This process involves translat-

ing security policies and designs into practical imple-

mentations, including mapping security requirements

to functional requirements related to the domain engi-

neering (Etxeberria and Sagardui, 2008). In this way,

a consolidation of existing features with the security

requirements and their implementations is achieved.

So, the process includes a variety of features to be

implemented, for example, setting up ﬁrewalls, en-

cryption protocols, access control lists, and other se-

curity mechanisms to align with the system’s (secu-

rity) design (Mellado et al., 2010). Additionally, busi-

ness processes modeled in UML or as BPMN models

should be transferred into XML format due to the shift

of involved stakeholders. Furthermore, it might be

useful to classify all implemented features according

to their level of exploitation impact, making it easier

to select a suitable risk acceptance according to stake-

holder requirements (Etxeberria and Sagardui, 2008).

One of the key tasks is also to ensure feature reusabil-

ity while considering only valid and consistent con-

ﬁgurations to avoid security misconﬁgurations (Myl-

ICSOFT 2025 - 20th International Conference on Software Technologies

lärniemi et al., 2015).

Security Testing. Security testing veriﬁes and val-

idates the effectiveness and resilience of the imple-

mented security design. This process involves testing

legal compliance, conﬁgurations and dependencies,

incident management capabilities, and source code.

The compliance activity includes verifying that

the system adheres to legal, regulatory, and domain-

speciﬁc security requirements (Mellado et al., 2007).

Thus, compliance testing validates that all imple-

mented security features are in line with the legal and

regulatory obligations identiﬁed during the security

analysis phase. For instance, testing might involve

assessing whether data encryption, logging mecha-

nisms, or access control policies (Fægri and Hallstein-

sen, 2006) meet the standards outlined by legal regu-

lations. In addition, it ensures that security practices

evolve in response to updates in legal frameworks or

domain standards (May et al., 2023a).

Testing conﬁgurations and dependencies is related

to the veriﬁcation of proper system conﬁgurations and

dependencies to ensure that there are no security mis-

conﬁgurations or overlooked vulnerabilities. This ac-

tivity includes testing environments, tools, and third-

party integrations (e.g., cross-conﬁgurations) to ver-

ify that they align with the security design (Varela-

Vaca et al., 2021). For example, access control lists,

encryption protocols, and dependency management

systems are iteratively tested to identify weak conﬁg-

urations or exploitable points (Mellado et al., 2010).

Additionally, dependencies such as third-party APIs

or external libraries are evaluated to ensure that they

do not introduce security risks (Horcas et al., 2018;

Varela-Vaca et al., 2021).

Incident management testing focuses on the

reusability and traceability of the system’s underly-

ing functions supporting the detection of and recovery

from security incidents effectively. For instance, test-

ing in the context includes verifying and validating

system’s logging and alerting functions as essential

pillars in the overall vulnerability detection process,

as well as the response mechanisms in place (Ines

et al., 2011; Williams et al., 2020). Note, that we

only focus on one part of the incident management

process in this context. Typically, incident manage-

ment relates more to a process after the actual de-

velopment of a system, i.e. deployment and opera-

tion (ISO/IEC 27000, 2022). Nevertheless, we argue

that testing reusability and traceability may increase

its reliability sustainably.

Testing source code is a crucial activity to identify

potential weaknesses, in particular, as developers’ er-

rors are a common problem. Typically, such program-

ming errors are not deliberately reported, as respon-

sible developers feel a certain amount of guilt in this

context (Dietrich et al., 2018; May et al., 2025). How-

ever, this makes it even more important to implement

testing strategies oriented towards features, products,

and system families. For example, testing might in-

volve code review processes to identify reused com-

ponents and verify that their functions meet the orga-

nization’s security reference guidelines (Varela-Vaca

et al., 2020). Another aspect is related to clown-and-

own and planting, in particular regarding practices

of copying or reusing code or patterns from external

sources, such as Stack Overﬂow, GitHub, or large-

language models. Here, developers may inadver-

tently introduce vulnerabilities by copying insecure

code snippets or patterns, including improperly im-

plemented cryptographic functions, insecure default

conﬁgurations, or undocumented dependencies (May

et al., 2025).

4.4 Documentation

In parallel to each process and its activities, a com-

prehensive documentation has to be made, at best

based on one centralized repositories for different pur-

poses (Varela-Vaca et al., 2021; May et al., 2023a).

Note that our examples may be case-dependent and

do not include all possible repositories.

In the problem space, security analysis ﬁndings

are stored, such as domain-speciﬁc requirements,

compliance regulations, threat models, and risk as-

sessments (Williams et al., 2020; Tomashchuk et al.,

2021). This documentation serves as a reference for

understanding the security landscape and forms the

basis for security design, whose information is also

stored, for example, including security requirements

and architectures (Guana and Correal, 2012; Myl-

lärniemi et al., 2015).

During the mapping phase, the documentation

evolves to include security policies, models (e.g.,

variability models, BPMN models), and abstract de-

signs (Horcas et al., 2013; May et al., 2023a). At best,

the documentation in this phase consolidates all ﬁnd-

ings, models, and designs into a single reference that

guides developers, testers, and other stakeholders, fa-

cilitating consistency and efﬁciency across PLE.

In the solution space, the documentation focuses

on implementation and testing artifacts. They include

detailed records of conﬁgurations, dependencies, test

cases, test results, and incident management proto-

cols (Wilson and Young, 2020; Varela-Vaca et al.,

2021). For example, reusable test scripts, validated

conﬁgurations, and incident response plans are stored

to streamline implementation and support audits. This

documentation also contains feedback from testing

Integrating Security into the Product-Line-Engineering Framework: A Security-Engineering Extension

and monitoring, which drives continuous and iterative

improvement (Mellado et al., 2008a; Varela-Vaca and

Gasca, 2015).

5 DISCUSSION

In the following, we describe a selection of major im-

plications based on our results as well as challenges

that still remain, leading to further research directions.

Consideration of Business Processes. The limited

attention to business processes within existing se-

curity frameworks and workﬂows highlights a gap.

Modern systems increasingly rely on process mod-

eling, such as BPMN, to deﬁne workﬂows involving

tasks, interfaces, and roles (May et al., 2023a). How-

ever, the integration of security considerations at this

stage is often overlooked (cf. Table 1). Secure BPMN

modeling ensures that access controls, role permis-

sions, and interface protections are embedded early in

the development lifecycle. By transforming BPMN

into machine-readable formats like XML, supported

by frameworks such as OWASP XML Security, these

processes become secure and executable. This ap-

proach not only enhances security but also maintains

operational efﬁciency and compliance with industry

standards such as ISO/IEC 27000 (2022).

Incident Management in Early Development

Phases. Incident management, while critical, is

typically addressed in operational contexts post-

deployment (Tøndel et al., 2014). This narrow focus

neglects the importance of reusable, traceable, and

early incident management mechanisms during devel-

opment. By testing functions related to logging, alert-

ing, and recovery in pre-deployment, systems can im-

prove their ability to detect and respond to incidents.

For example, not only security-critical systems (e.g.,

ERP systems) but also systems with special require-

ments to safety (e.g., cyber-physical systems in man-

ufacturing) can beneﬁt from such tests. We believe

that business process and their models may also ben-

eﬁt in this context. For instance, a log ﬁle can be

generated after completing a process step (e.g., order

creation), or dependent systems can be conﬁgured to

create logs at these points to enable recovery and en-

hance security. Overall, we argue that validating in-

cident response templates as part of pre-deployment

testing enhances preparedness and ensures that secu-

rity measures remain robust throughout the develop-

ment lifecycle.

Comprehensive Source-Code Testing. We argue

that, although source-code testing is a well-known

research ﬁeld (Varela-Vaca et al., 2019), it is often

neglected in the analyzed literature. Furthermore,

testing is typically only conducted in feature-based

or product-based ways. However, family-based test-

ing might also be a feasible strategy, involving cross-

conﬁgurations and -dependencies between systems of

a larger product portfolio (May et al., 2024a). Testing

efforts should also address novel challenges related to

planting, such as vulnerabilities introduced through

reused code from external sources, i.e., clone-and-

own (Krüger and Berger, 2020). Due to the increas-

ing application of large-language models, we expect

an even growing challenge in this context. In general,

technologies related to artiﬁcial intelligence may be

particularly prone to misbehavior, leading to signif-

icant risks related to their reliability and trust (May

et al., 2024b).

Standard Adoption and Compliance. Not surpris-

ingly, the adoption of domain legal regulations and

standards (e.g., manufacturing, healthcare) remains

inconsistent, reﬂecting the challenges in aligning

domain-speciﬁc needs with established PLE work-

ﬂows (Kenner et al., 2021). Integrating periodic

reviews of compliance measures into PLE ensures

alignment with evolving regulations and industry

practices, supporting the successful transfer of so-

lutions from theory into practice. However, stan-

dards are often resource-intensive to implement, de-

terring their practical application in smaller-scale

or resource-constrained projects. We argue that

lightweight adaptations tailored to speciﬁc domains,

combined with automated compliance tools, could

streamline their adoption.

Third-Party Dependencies and Services. The re-

liance on third-party services introduces signiﬁcant

vulnerabilities, such as different levels of authentica-

tion, non-isolation, or the use of legacy systems with

inadequate security protection functions (Benaroch,

2021). However, only few of the analyzed studies

provide comprehensive strategies for managing these

dependencies. We argue that standardized evalua-

tion criteria for third-party components in PLE, in-

cluding compliance and risk assessments, are essen-

tial (NIST SP 800-30r1, 2012). Furthermore, more

preventive approaches rather than reactive approaches

are needed to better meet the security objectives of the

CIA triad (Samonas and Coss, 2014).

5.1 Threats to Validity

There are several potential threats that might impair

the internal (i.e., conﬁdence that variables caused ef-

fects) and external validity (i.e., generalizability of

ﬁndings to other settings). These are outlined in the

following.

ICSOFT 2025 - 20th International Conference on Software Technologies

Internal Validity. Threats to internal validity include

potential biases from subjective decisions in deﬁning

meta-characteristics and revising the framework ex-

tension iteratively. While the literature selection re-

lied on three major literature databases, we may not

considered all relevant research. To mitigate this, we

employed snowballing to minimize the probability of

overlooking relevant literature. Additionally, the ter-

minology in the analyzed papers may have been mis-

interpreted. To address this, ambiguous terms were

discussed and clariﬁed among the authors. Vary-

ing levels of detail in the publications posed another

threat, which we addressed by ensuring that the ﬁrst

and second authors discussed the extracted data from

the selected works to minimize potential knowledge

bias. In general, threats to internal validity were ad-

dressed by adopting a systematic methodology (Nick-

erson et al., 2013) that integrates two complementary

construction strategies (cf. Figure 1) while actively

involving experienced researchers and practitioners

throughout the identiﬁcation, synthesis, and discus-

sion process.

External Validity. The external validity is inﬂuenced

by its narrow focus on secure PLE frameworks and

workﬂows, potentially overlooking broader security

approaches. Although the inclusion criteria ensured

relevance, restricting the analysis to 49 papers may

have excluded additional valuable perspectives. How-

ever, by including literature published between 2005

and 2024, we argue that we considered a sufﬁcient

time frame, while ensuring timeliness of the analyzed

research. Furthermore, the lack of a practical evalua-

tion limits the generalizability to real-world contexts.

To address this limitation, a comprehensive evaluation

is already planned for future research by validating

the extension in both PLE and security communities.

6 RELATED WORK

Security in PLE is increasingly recognized within the

variability community. For instance, Krieter et al.

(2018) explored securely handling product lines in

cloud environments using Intel SGX, while Kenner

et al. (2020) proposed representing attack vectors

through feature models. Additionally, Varela-Vaca

et al. (2020, 2021, 2023) leveraged feature models

for automated veriﬁcation and management of system

vulnerabilities and security requirements.

Beyond solutions for speciﬁc security concerns,

the niche ﬁeld of security-engineering frameworks

and workﬂows in PLE has emerged, forming the

foundation of our empirical-to-conceptual construc-

tion strategy (Nickerson et al., 2013). Three key ap-

proaches stand out: Fægri and Hallsteinsen (2006) in-

troduced a reference architecture for security-focused

decision support in domain engineering; Mellado

et al. (2007) developed the SREPPLine framework for

systematic security-requirements engineering, further

reﬁned until 2010 (Mellado et al., 2010). Varela-Vaca

et al. (2019) created the CyberSPL framework for

verifying security requirements, features, and compli-

ance. A closely related work is by May et al. (2023a),

who proposed a PLE framework for secure ERP sys-

tems. While sharing our focus on integrating security

engineering as a third pillar in PLE, their work is spe-

ciﬁc of ERP systems and business processes.

Although prior work has partially integrated

security and PLE (cf. Table 1), our ISO/IEC

27000-compliant extension provides a more holistic,

domain-independent perspective. By systematically

detailing processes, activities, and their relationships,

we aim to enhance understanding of security engi-

neering in PLE, treating security as an equally impor-

tant cross-cutting concern.

7 CONCLUSION

In this paper, we presented an extensions of the PLE

framework (Pohl et al., 2005), called security engi-

neering. Our approach builds on a systematic de-

velopment process (Nickerson et al., 2013), includ-

ing the analysis of 49 papers related to secure PLE.

Additionally, we relied on the ISO/IEC 27000 (2022)

series to guarantee that the overall extensions com-

plies with established standards. In this way, we

aimed to facilitate the transfer of theoretical knowl-

edge into business practice. Overall, the extension is

currently domain-independent, but may be transfer-

able to other domains (e.g., manufacturing) by apply-

ing domain-speciﬁc standards and regulations in the

problem space. Besides the presented six processes

and 12 activities of the extension, we derived further

implications and challenges related to business pro-

cesses, incident management, source-code testing, se-

curity standards, and third-party services.

In this context, we argue that further research is

needed, for example, to address gaps in successfully

handling legal regulations and security standards in

PLE as well as to protect business processes and their

variability throughout PLE development. To this end,

we already planned several future studies, includ-

ing comprehensive evaluations based on case stud-

ies and multi-stage expert interviews within the PLE

and security communities. For the security evaluation

within the planned case study, we will combine differ-

ent approaches: Speciﬁcally, the established STRIDE

Integrating Security into the Product-Line-Engineering Framework: A Security-Engineering Extension

framework (Khan et al., 2017) will be used to ana-

lyze potential threats during the design phase (e.g.,

business process modeling), while the Cyber Kill

Chain (Yadav and Rao, 2015) will assess the frame-

work’s effectiveness against potential attack phases

(e.g., source-code testing or logging).

REFERENCES

Abal, I., Melo, J., St

anciulescu, ¸S., Brabrand, C., Ribeiro,

M., and W ˛asowski, A. (2018). Variability bugs in

highly conﬁgurable systems: A qualitative analysis.

Transactions on Software Engineering, 26(3):1–34.

Achour, I., Labed, L., and Ghezala, H. B. (2015a). Formal-

ization of secure service oriented product line. In In-

ternational Conference on Software Technologies (IC-

SOFT), pages 1–8. IEEE.

Achour, I., Labed, L., and Ghezala, H. B. (2015b). Propo-

sition of secure service oriented product line. In In-

ternational Symposium on Computers in Education

(SIIE), pages 52–59. IEEE.

Adejokun, A. and Siok, M. F. (2020). Effective systems

security requirements in product line engineering. IN-

SIGHT, 23(3):26–30.

Alam, M. M., Khan, A. I., and Zafar, A. (2017). A secure

framework for software product line development. In-

ternational Journal of Computer Applications, Foun-

dation of Computer Science, 975:33–40.

Apel, S., Batory, D., Kästner, C., and Saake, G. (2013).

Feature-oriented software product lines. Springer.

Batory, D. (2004). Feature-Oriented Programming and the

AHEAD Tool Suite. In International Conference on

Software Engineering (ICSE), pages 702–703. IEEE.

Benaroch, M. (2021). Third-party induced cyber inci-

dents—much ado about nothing? Journal of Cyberse-

curity, 7(1):tyab020.

Berg, K., Bishop, J., and Muthig, D. (2005). Tracing soft-

ware product line variability: from problem to solu-

tion space. In South African Institute of Computer

Scientists and Information Technologists (SAICSIT),

pages 182–191.

Dietrich, C., Krombholz, K., Borgolte, K., and Fiebig,

T. (2018). Investigating system operators’ perspec-

tive on security misconﬁgurations. In Conference

on Computer and Communications Security (CCS),

pages 1272–1289. ACM.

Etxeberria, L. and Sagardui, G. (2008). Evaluation of

quality attribute variability in software product fam-

ilies. In nternational Conference on Engineering

of Computer-based Systems (ECBS), pages 255–264.

IEEE.

Fægri, T. E. and Hallsteinsen, S. (2006). A software product

line reference architecture for security. In Software

Product Lines, pages 275–326. Springer.

Fernandez, E. B., Yoshioka, N., and Washizaki, H. (2015).

Patterns for security and privacy in cloud ecosystems.

In International Workshop on Evolving Security and

Privacy Requirements Engineering (ESPRE), pages

13–18. IEEE.

Fernandez, E. B., Yoshioka, N., Washizaki, H., and Syed,

M. H. (2016). Modeling and security in cloud ecosys-

tems. Future Internet, 8(2):13.

Gomes, A. T. A., Ziviani, A., Correa, B. S. P. M., Teixeira,

I. M., and Moreira, V. M. (2012). Splice: A software

product line for healthcare. In International Health

Informatics Symposium (IHI), pages 721–726. ACM.

Guana, V. and Correal, D. (2012). Improving software

product line conﬁguration: A quality attribute-driven

approach. Information and Software Technology,

55(3):541–562.

Hammani, F. Z., Rhanoui, M., and El Asri, B. (2014). To-

wards a variable non-functional requirements integra-

tion for component-based product line a generic ap-

proach. In World Conference on Complex Systems

(WCCS), pages 146–151. IEEE.

Horcas, J. M., Pinto, M., and Fuentes, L. (2013). Variabil-

ity and dependency modeling of quality attributes. In

Conference Series on Software Engineering and Ad-

vanced Applications (SEAA), pages 185–188. IEEE.

Horcas, J.-M., Pinto, M., and Fuentes, L. (2018). Vari-

ability models for generating efﬁcient conﬁgurations

of functional quality attributes. Information and Soft-

ware Technology, 95:147–164.

Horcas, J.-M., Pinto, M., and Fuentes, L. (2019). Soft-

ware product line engineering: A practical experi-

ence. In Systems and Software Product Line Confer-

ence (SPLC), pages 164–176. ACM.

Hundt, C., Mehner, K., Pfeiffer, C., and Sokenou, D.

(2007). Improving alignment of crosscutting features

with code in product line engineering. Journal of Ob-

ject Technology, 6(9):417–436.

Iglesias, A., Lu, H., Arellano, C., Yue, T., Ali, S., and Sagar-

dui, G. (2017). Product line engineering of monitor-

ing functionality in industrial cyber-physical systems:

A domain analysis. In Systems and Software Product

Line Conference (SPLC), pages 195–204. ACM.

Ines, A., Khadouma, S., Labed, L., and Ghezala, H. B.

(2011). Towards a secure service oriented product

line. In International Conference on Software En-

gineering Research and Practice (SERP), pages 1–7.

Citeseer.

Iqbal, M., Hafeez, Y., Almashﬁ, N., Alsirhani, A., Alser-

hani, F., Ali, S., Humayun, M., and Jamal, M. (2024).

Enhancing secure development in globally distributed

software product lines: A machine learning-powered

framework for cyber-resilient ecosystems. Comput-

ers, Materials & Continua, 79(3).

ISO/IEC 27000 (2022). Information technology – Security

techniques – Information security management sys-

tems. Standard, ISO.

Kenner, A., Dassow, S., Lausberger, C., Krüger, J., and Le-

ich, T. (2020). Using variability modeling to support

security evaluations: Virtualizing the right attack sce-

narios. In International Working Conference on Vari-

ability Modelling of Software-Intensive Systems (Va-

MoS), pages 1–9. ACM.

Kenner, A., May, R., Krüger, J., Saake, G., and Leich, T.

(2021). Safety, security, and conﬁgurable software

ICSOFT 2025 - 20th International Conference on Software Technologies

systems: A systematic mapping study. In Systems

and Software Product Line Conference (SPLC), page

148–159. ACM.

Khan, R., McLaughlin, K., Laverty, D., and Sezer, S.

(2017). Stride-based threat modeling for cyber-

physical systems. In ISGT-Europe, pages 1–6. IEEE.

Kim, J., Park, S., and Sugumaran, V. (2008). DRAMA:

A framework for domain requirements analysis and

modeling architectures in software product lines.

Journal of Systems and Software, 81(1):37–55.

Kitchenham, B. A., Budgen, D., and Brereton, O. P. (2015).

Evidence-based software engineering and systematic

reviews. CRC Press.

Kobelsky, K. W. (2014). A conceptual model for segrega-

tion of duties: Integrating theory and practice for man-

ual and it-supported processes. International Journal

of Accounting Information Systems, 15(4):304–322.

Krieter, S., Krüger, J., Weichbrodt, N., Sartakov, V. A.,

Kapitza, R., and Leich, T. (2018). Towards secure

dynamic product lines in the cloud. In International

Conference on Software Engineering (ICSE), pages 5–

8. ACM.

Krüger, J. and Berger, T. (2020). An empirical analy-

sis of the costs of clone-and platform-oriented soft-

ware reuse. In International Conference on the Foun-

dations of Software Engineering (ESEC/FSE), pages

432–444. ACM.

May, R., Alex, A., Suresh, R., and Leich, T. (2024a).

Product-line engineering for smart manufacturing: A

systematic mapping study on security concepts. In In-

ternational Conference on Software Technologies (IC-

SOFT), pages 323–330. SciTePress.

May, R., Biermann, C., Kenner, A., Krüger, J., and Leich,

T. (2023a). A product-line-engineering framework for

secure enterprise-resource-planning systems. In Inter-

national Conference on ENTERprise Information Sys-

tems (CENTERIS), pages 1–8. Elsevier.

May, R., Biermann, C., Krüger, J., Saake, G., and Leich,

T. (2022). A systematic mapping study of security

concepts for conﬁgurable data storages. In Systems

and Software Product Line Conference (SPLC), pages

108–119. ACM.

May, R., Biermann, C., Krüger, J., and Leich, T. (2025).

Asking security practitioners: Did you ﬁnd the vul-

nerable (mis)conﬁguration? In International Work-

ing Conference on Variability Modelling of Software-

Intensive Systems (VaMoS), pages 1–10. ACM.

May, R. et al. (2023b). A systematic mapping study on

security in conﬁgurable safety-critical systems based

on product-line concepts. In International Conference

on Software Technologies (ICSOFT), pages 217–224.

SciTePress.

May, R., Krüger, J., and Leich, T. (2024b). Sok: How

artiﬁcial-intelligence incidents can jeopardize safety

and security. In International Conference on Avail-

ability, Reliability, and Security (ARES), pages 1–12.

ACM.

Mellado, D., Fernández-Medina, E., and Piattini, M.

(2007). Sreppline: Towards a security requirements

engineering process for software product lines. In In-

ternational Workshop on Security In Information Sys-

tems (WOSIS), pages 220–232. SciTePress.

Mellado, D., Fernández-Medina, E., and Piattini, M.

(2008a). Security requirements engineering process

for software product lines: A case study. In Interna-

tional Conference on Software Engineering Advances

(ICSEA), pages 1–6. IEEE.

Mellado, D., Fernández-Medina, E., and Piattini, M.

(2008b). Security requirements in software prod-

uct lines. In International Conference on Secu-

rity and Cryptography (SECRYPT), pages 442–449.

SciTePress.

Mellado, D., Fernandez-Medina, E., and Piattini, M.

(2008c). Security requirements variability for soft-

ware product lines. In International Conference on

Availability, Reliability, and Security (ARES), pages

1413–1420. IEEE.

Mellado, D., Fernández-Medina, E., and Piattini, M.

(2008d). Towards security requirements management

for software product lines: A security domain require-

ments engineering process. Computer Standards &

Interfaces, 30(6):361–371.

Mellado, D., Fernández-Medina, E., and Piattini, M.

(2010). Security requirements engineering framework

for software product lines. Information and Software

Technology, 52(10):1094–1117.

Mellado, D., Mouratidis, H., and Fernández-Medina, E.

(2014). Secure tropos framework for software product

lines requirements engineering. Computer Standards

& Interfaces, 36(4):711–722.

Mellado, D., Rodríguez, J., Fernández-Medina, E., and Pi-

attini, M. (2009). Automated support for security re-

quirements engineering in software product line do-

main engineering. In International Conference on

Availability, Reliability, and Security (ARES), pages

224–231. IEEE.

Mesa, O., Vieira, R., Viana, M., Durelli, V. H. S., Cirilo, E.,

Kalinowski, M., and Lucena, C. (2018). Understand-

ing vulnerabilities in ppugin-based web systems: An

exploratory study of wordpress. In Systems and Soft-

ware Product Line Conference (SPLC), pages 149–

159. ACM.

Murwantara, I. M. (2012). Hybrid anp: Quality attributes

decision modeling of a product line architecture de-

sign. In International Conference on Uncertainty Rea-

soning and Knowledge Engineering (URKE), pages

30–34. IEEE.

Myllärniemi, V., Raatikainen, M., and Männistö, T. (2015).

Representing and conﬁguring security variability in

software product lines. In International Confer-

ence on the Quality of Software Architectures (QoSA),

pages 1–10. ACM.

Navas, J., Voirin, J.-L., Paul, S., and Bonnet, S. (2020). To-

wards a model-based approach to systems and cyber-

security: Co-engineering in a product line context. IN-

SIGHT, 23(3):39–43.

Nickerson, R. C., Varshney, U., and Muntermann, J. (2013).

A method for taxonomy development and its applica-

tion in information systems. European Journal of In-

formation Systems, 22(3):336–359.

Integrating Security into the Product-Line-Engineering Framework: A Security-Engineering Extension

NIST SP 800-150 (2016). Guide to cyber threat information

sharing. Standard, National Institute of Standards and

Technology.

NIST SP 800-30r1 (2012). Guide for conducting risk as-

sessments. Standard, National Institute of Standards

and Technology.

Pohl, K. et al. (2005). Software product line engineering:

Foundations, principles, and techniques. Springer.

Reinhartz-Berger, I., Cohen, S., Bettin, J., Clark, T., and

Sturm, A. (2013). Domain engineering. Product

Lines, Languages and Conceptual Models.

Rodríguez, J., Fernández-Medina, E., Piattini, M., and Mel-

lado, D. (2011). A security requirements engineering

tool for domain engineering in software product lines.

In Non-Functional Properties in Service Oriented Ar-

chitecture: Requirements, Models and Methods, pages

73–92. IGI Global.

Samonas, S. and Coss, D. (2014). The CIA strikes back:

Redeﬁning conﬁdentiality, integrity and availability

in security. Journal of Information System Security,

10(3).

Sion, L., Van Landuyt, D., Yskout, K., and Joosen, W.

(2016). Towards systematically addressing security

variability in software product lines. In Systems

and Software Product Line Conference (SPLC), pages

342–343. ACM.

Sprovieri, D., Argyropoulos, N., Souveyet, C., Mazo, R.,

Mouratidis, H., and Fish, A. (2017). Security align-

ment analysis of software product lines. In Interna-

tional Conference on Enterprise Systems (ES), pages

97–103. IEEE.

Sánchez, L. E., Diaz-Pace, J. A., Zunino, A., Moisan, S.,

and Rigault, J.-P. (2014). An approach for manag-

ing quality attributes at runtime using feature models.

In Brazilian Symposium on Software Components, Ar-

chitectures, and Reuse (SBCARS), pages 11–20. IEEE.

Tan, L., Lin, Y., and Ye, H. (2012). Modeling quality at-

tributes in software product line architecture. In World

Congress on Engineering and Technology (SCET),

pages 1–5. IEEE.

ter Beek, M. H., Legay, A., Lafuente, A. L., and Vandin,

A. (2020). Variability meets security: Quantitative se-

curity modeling and analysis of highly customizable

attack scenarios. In International Working Confer-

ence on Variability Modelling of Software-Intensive

Systems (VaMoS), pages 1–9. ACM.

Thüm, T. et al. (2014). A classiﬁcation and survey of anal-

ysis strategies for software product lines. Computing

Surveys, 47(1):1–45.

Tomashchuk, O., Van Landuyt, D., and Joosen, W. (2021).

The architectural divergence problem in security and

privacy of ehealth iot product lines. In Systems

and Software Product Line Conference (SPLC), pages

114–119. ACM.

Tøndel, I. A., Line, M. B., and Jaatun, M. G. (2014). Infor-

mation security incident management: Current prac-

tice as reported in the literature. Computers & Secu-

rity, 45:42–57.

Trujillo, S., Alonso, I., Hamid, B., Gonzalez, D., Blanco,

M., and Zhang, H. (2011). Towards variability sup-

port for security and dependability patterns: a case

study. In Systems and Software Product Line Con-

ference (SPLC), pages 1–4. ACM.

van der Linden, F. J. et al. (2007). Software product lines in

action. Springer.

Varela-Vaca, A. J. et al. (2023). Feature models to boost the

vulnerability management process. Journal of Systems

and Software, 195:1–22.

Varela-Vaca, Á. J., Gasca, R., Ceballos, R., Gómez-López,

M. T., and Bernaldez Torres, P. (2019). CyberSPL: A

framework for the veriﬁcation of cybersecurity policy

compliance of system conﬁgurations using software

product lines. Applied Sciences, 9(24):1–28.

Varela-Vaca, A. J. and Gasca, R. M. (2015). Formalization

of security patterns as a means to infer security con-

trols in business processes. Logic Journal of the IGPL,

23(1):57–72.

Varela-Vaca, Á. J., Gasca, R. M., Carmona-Fombella, J. A.,

and T., G.-L. M. (2020). Amadeus: Towards the auto-

mated security testing. In Systems and Software Prod-

uct Line Conference (SPLC), pages 1–12. ACM.

Varela-Vaca, Á. J., Rosado, D. G., Sánchez, L. E., Gómez-

López, M. T., Gasca, R. M., and Fernández-Medina,

E. (2021). Carmen: A framework for the veriﬁcation

and diagnosis of the speciﬁcation of security require-

ments in cyber-physical systems. Computers in Indus-

try, 132:103524.

Villela, K., Arif, T., and Zanardini, D. (2012). Towards

product conﬁguration taking into account quality con-

cerns. In Systems and Software Product Line Confer-

ence (SPLC), pages 82–90. ACM.

Williams, P., Moss, P., Bataller, S., and Hassell, S. (2020).

Engineering a cyber resilient product line. INSIGHT,

23(3):17–21.

Wilson, B. and Young, B. (2020). Cyber secure and resilient

approaches for feature based variation management.

In International Symposium on Stabilization, Safety,

and Security of Distributed Systems (SSS), pages 1–6.

IEEE.

Yadav, T. and Rao, A. M. (2015). Technical aspects of cyber

kill chain. In International Symposium on Security in

Computing and Communication (SSCC), pages 438–

452. Springer.

Ya’u, B. I., Nordin, A., and Salleh, N. (2018). Require-

ments patterns structure for specifying and reusing

software product line requirements. In International

Conference on Information and Communication Tech-

nology for The Muslim World (ICT4M), pages 185–

190. IEEE.

Young, B., Darbin, R., and Clements, P. (2020). Sys-

tem security engineering and feature-based product

line engineering: A productive marriage. INSIGHT,

23(3):13–16.

Yu, D., Geng, P., and Wu, W. (2012). Constructing trace-

ability between features and requirements for software

product line engineering. In Asia-Paciﬁc Software En-

gineering Conference (APSEC), volume 2, pages 27–

34. IEEE.

Zhang, G., Ye, H., and Lin, Y. (2011). Modelling quality

attributes in feature models in software product line

engineering. In International Conference on Software

Technologies (ICSOFT), pages 249–254. SciTePress.

ICSOFT 2025 - 20th International Conference on Software Technologies