Towards Resolving Security Smells in Microservices, Model-Driven

Philip Wizenty

3 a

, Francisco Ponce

2,4 b

, Florian Rademacher

3 c

, Jacopo Soldani

1 d

Hernán Astudillo

2,4 e

, Antonio Brogi

1 f

and Sabine Sachweh

3 g

University of Pisa, Pisa, Italy

Universidad Técnica Federico Santa María, Valparaíso, Chile

IDiAL Institute, University of Applied Sciences and Arts Dortmund, Germany

ITiSB, Universidad Andrés Bello, Viña del Mar, Chile

Keywords:

Microservice Architecture, Model-Driven Engineering, Security, Bad Smells, Refactoring.

Abstract:

Resolving security issues in microservice applications is crucial, as many IT companies rely on microservices

to deliver their core businesses. Security smells denote possible symptoms of such security issues. However,

detecting security smells and reasoning on how to resolve them through refactoring is complex and costly,

mainly because of the intrinsic complexity of microservice architectures. This paper presents the ﬁrst idea

towards supporting a model-driven resolution of microservices’ security smell. The proposed method relies

on LEMMA to model microservice applications by suitably extending LEMMA itself to enable the modeling

of microservices’ security aspects. The proposed method then enables processing LEMMA models to auto-

matically detect security smells in modeled microservice applications and recommend the refactorings known

to resolve the identiﬁed security smells. To assess the feasibility of the proposed method, this paper also intro-

duces a proof-of-concept implementation of the proposed LEMMA-based, automated microservices’ security

smell detection and refactoring.

1 INTRODUCTION

Microservice Architecture (MSA) (Newman, 2015)

is becoming increasingly popular for building enter-

prise applications, with companies like Amazon, Net-

ﬂix, and Twitter already relying on MSAs to deliver

their core businesses (Thönes, 2015). The popular-

ity of microservices is mainly due to their cloud-

native (Gannon et al., 2017) nature, which enables

microservice applications to fully exploit the poten-

tials of cloud computing, and to the fact that mi-

croservices natively align with the increasingly popu-

lar DevOps practices (Balalaie et al., 2016).

MSA is essentially service-oriented architecture,

adhering to an extended set of design principles that

https://orcid.org/0000-0002-3588-5174

https://orcid.org/0000-0002-6411-0511

https://orcid.org/0000-0003-0784-9245

https://orcid.org/0000-0002-2435-3543

https://orcid.org/0000-0002-6487-5813

https://orcid.org/0000-0003-2048-2468

https://orcid.org/0000-0003-1343-3553

make microservice applications highly distributed,

dynamic, and fault-resilient (Zimmermann, 2017). As

a result, MSA inherits the traditional security con-

cerns and practices for service-oriented architectures

whilst also bringing up new security challenges, in-

cluding the so-called security smells, which were ﬁrst

elicited in (Ponce et al., 2022b).

Microservice security smells are possible symp-

toms of (typically unintentional) bad design deci-

sions, which can negatively affect the overall appli-

cation’s security (Ponce et al., 2022b). The impact of

microservice security smells can be resolved by ap-

plying known refactorings to them, which contribute

to securing the application while obviously avoid-

ing altering the functionalities provided to clients.

Although refactoring security smells requires effort

from development teams, it can help to improve the

overall application quality (Bass et al., 2012).

However, detecting microservice security smells

and reasoning on how to refactor them is complex,

costly, and error-prone. This is mainly due to the in-

trinsic complexity of MSA itself, which typically re-

sults in applications comprising many interacting mi-

Wizenty, P., Ponce, F., Rademacher, F., Soldani, J., Astudillo, H., Brogi, A. and Sachweh, S.

Towards Resolving Security Smells in Microservices, Model-Driven.

DOI: 10.5220/0012049800003538

In Proceedings of the 18th International Conference on Software Technologies (ICSOFT 2023), pages 15-26

ISBN: 978-989-758-665-1; ISSN: 2184-2833

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

croservices (Ponce et al., 2022a). This paper aims to

pave the way toward automated detection and refac-

toring of microservices security smells, focusing on

the two most recognized smells according to (Ponce

et al., 2022b). More precisely, we investigate the po-

tential of Model-Driven Engineering (MDE) (Combe-

male et al., 2017) to this purpose by extending the

Language Ecosystem for Modeling Microservice Ar-

chitecture (LEMMA) (Rademacher, 2022), which has

been speciﬁcally designed to apply MDE in microser-

vices design, development, and operation.

The main contributions of this paper are:

• We introduce a ﬁrst approach to MDE-based reso-

lution of microservice security smells. More pre-

cisely, we extend LEMMA to model security as-

pects of microservices and propose a method to

automatically process LEMMA models to detect

the two most recognized security smells and rec-

ommend refactorings to resolve their effects.

• We present and discuss the feasibility assessment

of our proposed method, which includes a proof-

of-concept implementation, and which shows that

our method facilitates the detection and refactor-

ing of microservice security issues in LEMMA

models of a third-party application.

The rest of this paper is as follows. Section 2 pro-

vides background on microservice security smells and

LEMMA. Section 3 presents a motivating example.

Section 4 introduces our method for detecting and

refactoring microservice security smells in LEMMA

models, whose proof-of-concept implementation is in

Section 5. Sections 6 to 8 provide a discussion of our

approach, present related work, and draw some con-

cluding remarks, respectively.

2 BACKGROUND

We hereafter provide the necessary background on

microservice security smells (Section 2.1) and on

LEMMA as a concrete approach towards viewpoint-

based modeling of microservices (Section 2.2).

2.1 Smells and Refactorings for

Microservice Security

In an application, a microservice security smell can

indicate a poor decision that may have been made un-

intentionally, potentially harming the overall security

of the application (Ponce et al., 2022b). The effects of

security smells can be resolved by refactoring the ap-

plication or the services therein without altering the

functionality provided to clients. Although this pro-

cess may require effort from development teams, it

can help to improve the overall quality of the applica-

tion (Bass et al., 2012).

We hereafter recall the two security smells for

microservices that are most recognized according to

(Ponce et al., 2022b), viz., Publicly Accessible Mi-

croservices and Insufﬁcient Access Control. We also

recall the refactorings allowing to resolve such smells.

Publicly Accessible Microservices. The Publicly

Accessible Microservices security smell occurs when-

ever the microservices forming an application are di-

rectly accessible by external clients. Each publicly ac-

cessible microservice should enact authentication by

asking users to provide their full set of credentials.

The exposure increases the attack surface, raising the

risk of conﬁdentiality violations, and reducing the ap-

plication’s overall maintainability and usability.

The suggested refactoring is to Add an API Gate-

way, which should be used as an entry point for

the application. The formerly exposed microservices

APIs can then be accessed through the gateway, and

authentication can be performed centrally, overall re-

ducing the application’s attack surface and simplify-

ing authentication auditing tasks. Development teams

can also exploit the gateway to secure an application

through a ﬁrewall, blocking all external requests to

the internal microservices.

Insufﬁcient Access Control. The Insufﬁcient Access

Control smell occurs when the microservices in an ap-

plication do not enforce access control. This may re-

sult in conﬁdentiality violations, as attackers can trick

a service and violate data or business functions they

should be unable to access. In particular, microser-

vices can be vulnerable to the "confused deputy prob-

lem", where attackers deceive a service into reveal-

ing information or executing operations that should

rather be restricted. Traditional identity control mod-

els may also not be enough for microservice applica-

tions, where client permissions should be veriﬁed at

each level of the applications, and each microservice

must have a system to accept or reject any particular

request automatically.

The suggested refactoring is to Use OAuth 2.0 as

an access delegation framework that enables suitable

access control to the microservices forming an appli-

cation. OAuth 2.0 is indeed a token-based access con-

trol system that lets a resource owner grant a client

access to a particular resource on their behalf.

ICSOFT 2023 - 18th International Conference on Software Technologies

2.2 Viewpoint-Based Microservice

Modeling with LEMMA

MSA engineering is inherently complex, and en-

tails challenges in architecture design, implementa-

tion, and operation (Soldani et al., 2018), as well

as in development organization (Di Francesco et al.,

2018; Knoche and Hasselbring, 2019). For exam-

ple, the capabilities provided by microservices need

to be optimized so that they are distinct without be-

ing too ﬁne-grained, thereby allowing targeted scal-

ing and preventing overly communication simultane-

ously (design challenge). On the other hand, given

microservices’ maximization of independence, devel-

opers, and software architects are concerned with

a potentially high degree of technology heterogene-

ity that increases maintainability costs and learn-

ing curves (implementation challenge). Additionally,

MSA adoption can only be successful by orienting the

structure of the development organization towards the

software architecture, which involves the alignment

of interaction relationships between MSA teams to

those of microservices intending to streamline knowl-

edge sharing (organizational challenge).

To tackle these challenges, researchers studied the

application of MDE (Combemale et al., 2017) to fa-

cilitate MSA engineering by a targeted abstraction

from complexity. The resulting modeling approaches

are however very heterogeneous, and the majority fo-

cuses on a single phase in MSA engineering, i.e., mi-

croservice design (Kapferer and Zimmermann, 2020;

Hassan et al., 2017), implementation (Terzi

c et al.,

2018; JHipster, 2023), or operation (Soldani et al.,

2021; JHipster, 2023). As a result, these approaches

neither allow an integrated, model-based expression

of concerns across different phases in MSA engineer-

ing, nor do they support a consistent sharing of knowl-

edge among MSA teams.

To cope with these drawbacks in model-driven

MSA engineering, the MDE ecosystem LEMMA was

conceived (Rademacher, 2022). LEMMA provides a

set of modeling languages to capture various concerns

in MSA engineering from stakeholder-oriented archi-

tecture viewpoints. MSA models constructed with

those languages can be integrated based on an im-

port mechanism that enables referencing between el-

ements of heterogeneous models to support reuse and

increase the information content of captured view-

points. The presented approach for security smell res-

olution in microservice architectures relies on the fol-

lowing LEMMA modeling languages.

Technology Modeling Language (TML). LEM-

MA’s TML targets the Technology Viewpoint on mi-

croservice architectures. That is, it allows for the

construction of technology models that capture tech-

nology decisions related to microservices and their

deployment, e.g., communication protocols and de-

ployment technologies. Additionally, the TML sup-

ports the deﬁnition of technology aspects that apply

to speciﬁc elements in LEMMA models, e.g., mod-

eled microservices and their interfaces, or infrastruc-

ture nodes. Given their ﬂexibility, technology aspects

can also be exploited to enable subsequent augmenta-

tion of LEMMA models with additional metadata.

Service Modeling Language (SML). LEMMA’s

SML reiﬁes the Service Viewpoint in MSA engi-

neering. To this end, it provides modeling concepts

to specify microservices, their interfaces, operations

and endpoints in service models. Among others, the

SML integrates with the TML so that LEMMA ser-

vice models can import LEMMA technology mod-

els to specify, e.g., protocol-dependent communica-

tion endpoints such as HTTP addresses together with

the available methods to operate on them.

Operation Modeling Language (OML). LEMMA’s

OML focuses on MSA’s Operation Viewpoint. Con-

sequently, the language supports the speciﬁcation and

conﬁguration of microservice containers and infras-

tructure nodes, e.g., for service discovery or load

balancing, in operation models. Similarly to the

SML, the OML integrates with the TML to cope with

MSA’s technology heterogeneity w.r.t. microservice

operation and deployment (Knoche and Hasselbring,

2019). More precisely, technologies for microservice

deployment and infrastructure usage can ﬂexibly be

speciﬁed in technology models, making them refer-

enceable from operation models.

Besides model-based description of microservices

and their operation, LEMMA also anticipates model

processing, and has already been used to foster MSA

team integration by model transformation (Sorgalla

et al., 2021) and increase microservice development

efﬁciency by code generation (Rademacher et al.,

2020). In the following, we rely on LEMMA’s capa-

bilities in model processing to identify microservices’

security smells by static analysis of service and oper-

ation models, and suggest resolution actions by inter-

active model refactoring.

3 MOTIVATING EXAMPLE

This section introduces a motivating example to ex-

plain our approach toward model-driven microservice

security smell resolution. The example application

represents a widely-used ﬁctional insurance company

called Lakeside Mutual. The application’s source

Towards Resolving Security Smells in Microservices, Model-Driven

Infrastructure Components

Logging

Service

Discovery

Database

Customer

Management

Backend

Customer

Management

Frontend

Customer

Self-Service

Backend

Customer

Self-Service

Frontend

Policy

Management

Backend

Policy

Management

Frontend

Risk

Management

Client

Risk

Management

Server

Customer

Core

Message

Broker

http gRPC http

http

http / amqp

amqp http

http

Legend:

Infrastructure

Component

Microservice Frontend

Protocol /

Communication

Direction

Databases

Figure 1: Lakeside Mutual MSA example architecture.

code is publicly accessible on Github

, and is a com-

mon example in MSA-based research (Kapferer and

Zimmermann, 2020; Panichella et al., 2021; Sorgalla

et al., 2021). Figure 1 depicts the underlying architec-

ture of the motivating example application, including

functional microservices, infrastructure components,

and frontend services.

Each functional microservice (i.e. Policy-

ManagementBackend, RiskManagementServer,

CustomerManagementBackend, and Customer-

SelfServiceBackend) features a standalone front-

end component for user interaction. Infrastructure

components, e.g., MessageBroker and Service-

Discovery, provide support functionalities for inter-

service communication using HTTP and AMQP for syn-

chronous and asynchronous requests, respectively.

Furthermore, the application data handling has

a dedicated Database per functional microservice

to foster loose coupling among services and enable

the independent development of the application’s mi-

croservices. Finally, the Logging Service pro-

vides monitoring and operational functionalities.

Being this a demonstrator application, not pre-

tending to be an engineered and production-ready sys-

tem, we may expect it to feature several security is-

sues. Indeed, if manually analyzing the application

in terms of design decisions, technologies used, and

security conﬁgurations, we may discover such issues,

which include the following two:

• The APIs of all functional microservices of the

https://github.com/Microservice-API-Patterns/

LakesideMutual

Lakeside Mutual application are publicly ex-

posed. This exposure is an occurrence of the Pub-

licly Accessible Microservice smell, which de-

notes an increased security violation risk by ex-

tending the attack surface. Furthermore, the sepa-

rately exposed APIs of the microservices also re-

duce maintainability and usability.

• The Lakeside Mutual application also includes in-

stances of the Insufﬁcient Access Control smell on

its API endpoints, which can be exploited for mis-

use, possibly leading to conﬁdentiality violations

and data leaks.

By knowing this, we may consider implementing

the Add an API Gateway and Use OAuth 2.0 refac-

torings, which are known to resolve the above-listed

smells. However, with a complex and costly appli-

cation analysis, smell detection, and refactoring are

currently to be done manually. It would be better to

have support for automating the detection of security

smells and reasoning on how to refactor them, which

is precisely our goal in this paper.

4 MODEL-DRIVEN SECURITY

SMELL RESOLUTION

This section explores our approach towards model-

based microservice security smell resolution based

on the motivating example from Section 3 and the

identiﬁed deﬁciencies in the architecture design and

security conﬁguration. Therefore, Section 4.1 pro-

vides insights into the aspect-oriented modeling of

security smells using LEMMA’s TML. Then, Sec-

tion 4.2 elaborates the detection possibilities of se-

curity smells in MSA depending on modeled secu-

rity aspects via LEMMA’s modeling languages, and

the potential refactoring strategies for resolving iden-

tiﬁed security smells. Finally, Section 4.3 describes

the user-guided refactoring process with LEMMA.

4.1 Modeling Microservice Security

Aspects

The modeling of microservice security conﬁgurations

leverages LEMMA’s TML aspect concept to incorpo-

rate meta-information into a LEMMA service- or op-

eration model, as discussed in Section 2.2. The pro-

cess of modeling security conﬁgurations in the form

of LEMMA aspects consists of four sequential activ-

ities (M.1 to M.4), which are depicted in an UML ac-

tivity diagram (OMG, 2017) in Figure 2.

The modeling process in LEMMA begins by se-

lecting a security smell (M.1-Figure 2), such as Pub-

ICSOFT 2023 - 18th International Conference on Software Technologies

Select Microservice

Security Smell

Use Existing LEMMA

Technology Model

Create LEMMA

Technology Model

LEMMA Security

Smell Model

Extend LEMMA Model

With Architecture

Information

Extended LEMMA

Security Smell Model

M.4

M.3a

M.1

M.3b

Modeling Microservice Security Smells

Security Smell Model: TML model with integrated security smells

M.2

Derive Architecture

Relevant Information

From Security Smell

[Smell Exists In Model ]

[Model Lacks Smell ]

Figure 2: Process of modeling microservices’ security aspects with LEMMA.

licly Accessible Microservices or Insufﬁcient Access

Control. The next activity (M.2-Figure 2) involves an-

alyzing the smell to identify the underlying security or

architecture decision that gives rise to it. For example,

in the case of the Publicly Accessible Microservices

smell, the decision not to use an API gateway to ac-

cess all exposed microservices is the root cause of the

security smell (Richardson, 2019). Furthermore, an

analysis of the API gateway highlights that the corre-

sponding architecture pattern consists of the gateways

component, which is responsible for API composition

and routing functionalities, and the backend microser-

vices API exposure.

The subsequent activity employs the obtained ar-

chitecture information to model the security smell us-

ing LEMMA’s TML. This involves either selecting an

appropriate technology model (M.3a-Figure 2) or cre-

ating a new one (M.3b-Figure 2) that should be ex-

tended with the derived information.

Extending LEMMA’s technology model is part of

activity M.4-Figure 2, which involves modeling all

derived architecture information. The resulting model

can be used for automated tests to identify security

smells in LEMMA models. The model presented in

Listing 1 includes the modeled architecture informa-

tion derived from the security smells being consid-

ered, namely, Publicly Accessible Microservices and

Insufﬁcient Access Control.

Listing 1 Line 1 deﬁnes SecurityAspects as

the name of the LEMMA technology model. The

subsequent Lines 2–10 contain service aspects

that could be applied to the microservice con-

cept of LEMMA’s SML. More precisely, the

usesApiGateway aspect explicitly models that the

microservices expose its interface via an API Gate-

way (Line 3). Line 4 instead introduces the aspect

Authorization to deﬁne a protocol for access del-

egation, and Line 7 models an aspect to enable role-

based access for microservices API endpoints.

Additionally, to model an API Gateway with

Listing 1: LEMMA technology model with derived security

smell architecture information for security smell publicly

accessible microservices and insufﬁcient access control.

1 technology SecurityAspects {

2 service aspects{

3 aspect usesApiGateway for microservices;

4 aspect Authorization for microservices {

5 string protocolName;

6 }

7 aspect Secured for interfaces, operations {

8 string role;

9 }

10 }

11 operation aspects {

12 aspect ApiGateway for infrastructure;

13 }

14 }

LEMMA’s OML, Lines 11–13 of Listing 1 specify an

operation aspect named ApiGateway to identify

an infrastructure node in LEMMA’s operation models

as an API Gateway.

4.2 Detecting Security Smells

This section builds upon the previously created tech-

nology models (c.f. Section 4.1) as an indicator to de-

tect security smells in LEMMA’s service or operation

models for microservices. Figure 3 depicts the detec-

tion process and includes activities D.1 to D.3. Ac-

tivity D1 leverages the Extended LEMMA Security

Smell Model in association with additional LEMMA-

Technology Models, e.g., Spring

or Java

models

to specify the microservices’ API and dependencies

to other components of the systems.

For example, Listing 2 depicts a concrete

LEMMA service model from the motivating example

(c.f. Section 3) for the Customer Core microservice.

Lines 1 to 2 in listing 2 comprises LEMMA’s model

import functionality. In this case, the service model

imports the domain LEMMA domain data model

(Rademacher, 2022) for API speciﬁcation. Addition-

ally, the spring and securityAspect LEMMA

https://spring.io

https://www.docker.com

Towards Resolving Security Smells in Microservices, Model-Driven

Extended LEMMA

Security Smell Model

Detecting Microservice Security Smells

Lemma Technology Models: LEMMA models with operation or service technologies

Security Smell Information: Detected security smells

Create LEMMA

Service Model

LEMMA Service

Model

Create LEMMA

Operation Model

LEMMA Technology

Models

LEMMA

Operation Model

Security Smell

Detection

Detected

Security Smells

D.3

D.2

D.1

Figure 3: Activities of detecting microservices’ security aspects with LEMMA.

Listing 2: LEMMA service model for the Customer Core

microservice from the motivating example.

1 import datatypes from "customerCore.data" as domain

2 import technology from "spring.technology" as spring

4 @technology(spring)

5 @spring::

aspects.ApplicationName("CustomerCore")

6 @spring::

aspects.Port(8080)

7 public functional microservice com.lakeside.CustomerCore {

8 @endpoints(java::

protocols.rest: "/cities";)

9 interface cityStaticDataHolder {

10 ---

11 Get the cities for a particular postal code.

12 @required postalCode the postal code

13 ---

14 @endpoints({spring::

protocols.rest: "/{code}";})

15 @spring::

aspects.GetMapping

16 getCitiesForPostalCode(

17 sync in code : string,

18 sync out cities : domain::customerCore

19 .CitiesResponseDto

20 );}

21 ...

22 }

technology model is included to enhance the service

model with technology and architecture-related infor-

mation, e.g., spring as a framework for the realiza-

tion of the Customer Core microservice in Line 4.

Lines 5–6 (listing 2) then deﬁne service-speciﬁc

properties, which relate to Spring-based conﬁgura-

tions for the microservice application name and op-

erating port. Line 7 speciﬁes the fully qualiﬁed

name com.lakeside.CustomerCore of the mi-

croservice, including an excerpt of its API deﬁnition

in Lines 8–20. Specifying the microservices’ API by

deﬁning the resource URI in Line 8 and the name in

Line 9.

The cityStaticDataHolder interface from

listing 2 speciﬁes a single endpoint in Lines 10–20.

The speciﬁcation begins with a comment describing

the endpoint’s general functionality and required pa-

rameters, followed by the endpoint-speciﬁc exten-

sion of the interfaces URI in Line 14 for the rest

over HTTP protocol. Line 15 then adds the Spring

framework-speciﬁc aspect GetMapping to the end-

point, indicating that the endpoint supports access via

the HTTP-method get. Lines 16 to 20 ﬁnally spec-

ify the body deﬁnition for the endpoint containing in-

coming and outgoing parameters, including their cor-

Listing 3: LEMMA operation model for the Customer Core

microservice from the motivating example.

1 import microservices from "customerCore.services"

2 as customerCore

3 import technology from "deploymentBase.technology"

4 as deploymentBase

5 import technology from "protocol.technology" as protocol

6 import nodes from "infrastructure.operation" as

infrastructure

8 @technology(deploymentBase)

9 @technology(protocol)

10 container CustomerCoreContainer

11 deployment technology deploymentBase::

deployment.Docker

12 deploys customerCore::com.lakeside.CustomerCore

13 depends on nodes

14 infrastructure::ServiceDiscovery,

15 infrastructure::H2Database {

16 default values {

17 basic endpoints { protocolTechnology::

protocols.rest: "http://localhost:8110"; }

19 }

20 }

responding data types.

The next activity, D.2 (c.f. Figure 3), consists of

the operation model creation using LEMMA’s OML.

The operation model contains the deployment and

operation speciﬁcations. Listing 3 deﬁnes the op-

eration model for the Customer Core microservice

with dependencies to infrastructure components, e.g.,

databases or Service Discoveries. The listing begins

with an import of different LEMMA models from

Line 1 to 6. The ﬁrst import consists of the Customer

Core service model (c.f. Listing 2) to specify the mi-

croservice deployment. Lines 3–5 contain the import

statements for the deploymentBase and protocol

technology models, with the technologies necessary

for deployment speciﬁcation.

Listing 3 then continues with Lines 8–9 assigning

the imported technologies to the CustomerCore-

Container (Line 10) to enable their usage in the

deployment speciﬁcation for the container. The con-

tainer in LEMMA’s OML is a component that encap-

sulates all relevant information for deploying a spe-

ciﬁc microservice. Therefore, in Line 11, the deploy-

ment technology docker is assigned to the container,

as well as the deployed CustomerCore microservice

(Line 12).

ICSOFT 2023 - 18th International Conference on Software Technologies

Detected Security

Smells

LEMMA

Operation Model

LEMMA Service

Model

Refactor

Operation Model

Refactor Service

Model

Select Security Smell

Resolving Microservice Security Smells

LEMMA Models: LEMMA models containing API or deployment speciﬁcations

Detected Security Smells: List of Security Smells detected in LEMMA models

R.1a

R.1b

R.2

R.6R.4

R.5

Select Security Smell

Resolution Strategy

R.3

Mark Security Smells

As Intentionally

Ignored

Preview Selected

Refactoring

Results

Conﬁrm

Refactored Model

Changes

Refactored LEMMA

Model

[Resolve Smell]

[Ignore

Smell]

Figure 4: Activities of resolving microservices’ security aspects with LEMMA.

Runtime dependencies to infrastructural com-

ponents, such as databases or service discoveries,

needed for scalability and synchronous service com-

munication, are speciﬁed from Line 13 to 15. This in-

cludes dependencies to LEMMA infrastructure mod-

els, describing the deployment of a Eureka

service

discovery and a H2

database.

The last part of the listing from Line 16 to 19 de-

ﬁnes default values, which are used for service

operation. In this case, the basic endpoint for

communication via HTTP and, therefore, as the be-

ginning of the URI extended by endpoint speciﬁcation

of the service model (c.f. Listing 2).

Activity D.3 (c.f. Figure 3) consists of the detec-

tion process. For this purpose, the service and op-

eration model is analyzed via model-speciﬁc valida-

tors. The model validators for security smell can be

explicitly enabled in the Eclipse-based model editor

of LEMMA. According to the case that the validators

detect a security smell in the models, they display a

warning in the model editor stating the name of the

security smell and possible strategies for resolving it.

4.3 Resolving Security Smells

This section introduces the activities followed to re-

solve the detected security smells. It also presents

the user-guided process using the LEMMA’s model-

ing editor. The resolution process, depicted in Fig-

ure 4, begins with activity R.1a for service and R.1b

for operation models.

After selecting the model kind, the next activity

(R.2-Figure 4) involves choosing the security smell

that needs to be addressed in the refactoring process.

For each security smell, there are different strategies

for resolution (Ponce et al., 2022b) (activity R.3-

Figure 4). For instance, the Publicly Accessible Mi-

croservices security smell can be resolved by using

https://github.com/Netﬂix/eureka

https://www.h2database.com

Listing 4: Refactored LEMMA operation model for the

Customer Core microservice from the motivating example.

1 ...

2 @technology(deploymentBase)

3 @technology(protocolTechnology)

4 container CustomerCoreContainer ...

5 depends on nodes

6 infrastructure::ServiceDiscovery,

7 infrastructure::H2Database,

8 infrastructure::APIGateway

9 ...}

an API Gateway or by disabling the public exposure

of the service. It should be noted that exposing the mi-

croservice publicly can also be an intentional design

decision that should be marked intentionally (activ-

ity R.4-Figure 4). As part of the resolution process,

deliberately ﬂagging a security smell as "ignored" is

a strategy used to notify the user of its presence and

acknowledge their design decisions.

Following the selection of the resolution strategy,

the next activity is to preview the refactoring results

speciﬁc to the chosen strategy. LEMMA’s modeling

editor provides a workﬂow to guide the user through

this process. Finally, the last activity involves con-

ﬁrming the model changes and applying the resolu-

tion strategy to the involved models. (activity R.6-

Figure 4).

To illustrate the results of resolving the Publicly

Accessible Microservices security smell using the

strategy of including an API Gateway for public mi-

croservice exposure, an excerpt of the refactored op-

eration model of the Customer Core service is shown

in Listing 4.

Generally, the operation model remains un-

changed except for adding Line 8. The line speci-

ﬁes a depends on dependency to the infrastructural

component of an API Gateway. Due to the inclu-

sion of the API Gateway in the resolution strategy, a

corresponding operation model is also created in the

refactoring process of the Customer Core model.

Listing 5 speciﬁes the deployment of the API

Gateway infrastructure component using Netﬂix Zuul

Towards Resolving Security Smells in Microservices, Model-Driven

Listing 5: LEMMA operation model for an API Gateway

using the Zuul technology.

1 import ...

2 @technology(Zuul)

3 APIGateway is Zuul::

infrastructure.Zuul

4 depends on nodes ServiceDiscovery

5 used by services coreService::com.lakeside.CustomerCore,

6 used by nodes coreContainer::CustomerCoreContainer {

7 default values {

8 hostname = "APIGateway"

9 port = 8080

10 apiUri = "eureka:8080"

11 }

12 }

13 ...

as a concrete technology. Lines 2–3 assign the Zuul

technology to the corresponding speciﬁcation of an

APIGateway. The next line deﬁnes that the API

Gateway depends on a ServiceDiscovery to ful-

ﬁll its functionalities. Additionally, the used by

speciﬁcations in Lines 5–6 deﬁne that the Customer

Core microservices API is exposed via the Gateway.

The remaining lines of the listing deﬁne default

values, e.g., the hostname or operation port.

5 PROOF OF CONCEPT

IMPLEMENTATION

This section presents the proof-of-concept implemen-

tation towards the MDE-based resolution of microser-

vices security smells using LEMMA. The proof-of-

concept is intended to demonstrate the practical fea-

sibility of model-driven security smell resolution pro-

cess for publicly accessible microservices (c.f. sec-

tion 2) described in Section 4, being this the ﬁrst

step towards a full-ﬂedged, validated support for

LEMMA-based resolution of security smells in mi-

croservice applications.

The proof-of-concept implementation has been

developed by suitably extending the current Eclipse-

based support for LEMMA. Figure 5 depicts

LEMMA’s Eclipse-based editor with the opened Cus-

tomer Core Operation model presented in Listing 3.

The ﬁgure displays a warning in the Eclipse editor

indicating that a Publicly Accessible Microservices

smell was detected in the model. Furthermore, by

hovering over the warning, LEMMA’s security smell

resolution functionality provides the option for re-

solving the security smell by leveraging the Eclipse

Quickﬁx

function, addressing Activity R.2 of the

resolution process.

The selection of the quick ﬁx option starts the res-

olution process by addressing activity R.3 (c.f. Fig-

ure 4) with the possibility to select a resolution strat-

https://www.eclipse.org/Xtext/documentation/310_

eclipse_support.html#quick-ﬁxes

Figure 5: LEMMA Eclipse editor presenting the Customer

Core operation model with security smell publicly accessi-

ble microservices.

Figure 6: Selection of the security smell-speciﬁc strategy

for resolving publicly accessible microservices.

egy. The strategies are security smell speciﬁc, and

Figure 6 depicts the option for resolving publicly ac-

cessible microservices.

Besides the selected option to resolve the secu-

rity smell via an API Gateway, there is also the op-

tion to mark the smell explicitly as to be ignored to

disable the warning by a design decision. Addition-

ally, conﬁguring the Customer Core microservice as

internal is an option to resolve the security smell

by disabling public exposure.

The next steps of the process addressing activities

R.5 and R.6 consist of previewing and conﬁrming

the proposed refactoring adaption of the service and

operation model kind. The LEMMA editor previews

every modiﬁed model during the security smell reso-

lution process to guide the user. Figure 7 depicts such

a preview for integrating an API Gateway. The pre-

view displays the infrastructure component of an API

Gateway that is included in the infrastructure opera-

tion model (c.f. Figure 7 (a.)) and the adaption of the

Customer Core operation model (c.f. Figure 7 (b.))

The ﬁnal activity of LEMMA’s security smell res-

olution process is conﬁrming the proposed changes.

In addition to the presented security smell resolution

functionality, LEMMA provides means towards code

ICSOFT 2023 - 18th International Conference on Software Technologies

(a) Preview of the extension with an API Gateway of the

infrastructure operation model.

(b) Preview of the adaption of the Customer Core

operation model with API Gateway dependency.

Figure 7: Refactoring previews of the Customer Core and

API Gateway operation model for resolving publicly acces-

sible microservices.

generation, e.g., the generation of infrastructure com-

ponents like API gateways and service discoveries.

The process for resolving Insufﬁcient Access Con-

trol in microservices includes the same activities as

described for the Publicly Available Microservices se-

curity smell except for the resolution strategy. The

strategy depends on the proposed refactorings for

the corresponding microservice security smell (sec-

tion 2). One solution to resolve the issue of insufﬁ-

cient access control for microservices is to incorpo-

rate an authorization protocol such as OAuth2 (Ponce

et al., 2022a).

Section 4.2 introduces in listing 2 the Customer

Core LEMMA service model. Due to the lack of a

speciﬁcation of an authorization protocol for the mi-

croservice, the security of the service suffers from in-

sufﬁcient access control. Integrating the OAuth2 as

an authorization protocol resolves the security smell.

Listing 1 speciﬁes a LEMMA technology model with

an Authorization and Secured aspect to specify

a protocol for role-based access control of microser-

vices. The following listing 6 shows the LEMMA

model for the CustomerCore microservice with the

resolved security smell. To resolve the insufﬁcient ac-

cess control security, Line 3 imports the security-

Aspcet technology model and Line 5 applies the se-

curity technology to the speciﬁed microservice. Line

8 deﬁnes OAuth2 as an authorization protocol to the

Customer Core microservice. Additionally, to enable

role-based authorization at a microservice endpoint

granularity, Line 18 applies the Secured aspect to

the getCitiesForPostalCode endpoint.

6 DISCUSSION

Generating software system architecture models us-

ing LEMMAs is a manual process that can challenge

development teams. Furthermore, as the software sys-

tem evolves, the models must be updated to reﬂect the

Listing 6: LEMMA service model for the Customer Core

microservice from the motivating example.

1 ...

2 import technology from "securityAspects.technology"

3 as securityAspects

4 @technology(spring)

5 @technology(securityAspects)

6 @spring::

aspects.ApplicationName("CustomerCore")

7 @spring::

aspects.Port

8 @securityAspects::

aspects.Authorization(^protocol="OAuth2")

9 public functional microservice com.lakeside.CustomerCore {

10 @endpoints(java::

protocols.rest: "/cities";)

11 interface cityStaticDataHolder {

12 ---

13 Get the cities for a particular postal code.

14 @required postalCode the postal code

15 ---

16 @endpoints({spring::

protocols.rest: "/{postalCode}"

;})

17 @spring::

aspects.GetMapping

18 @securityAspects::

aspects.Secured("ROLE

USER")

19 getCitiesForPostalCode(...);}

20 ...

21 }

changes in the source code. To overcome this chal-

lenge, we plan to integrate Software Architecture Re-

construction (SAR) (Bass et al., 2013) into our ap-

proach to derive LEMMA models from source code

artifacts automatically. This will eliminate the need

for manual model generation and enable the models

to be updated automatically as the system evolves.

While our approach currently detects only two of

the microservices’ security smells identiﬁed in (Ponce

et al., 2022b), these two smells are among the three

most recognized in MSA. Nonetheless, one limita-

tion of our approach is that it does not yet cover all

the microservices’ security smells. However, we be-

lieve that the aspect-oriented modeling capabilities of

LEMMA show promising capabilities to detect addi-

tional security smells.

The current implementation of our approach fo-

cuses on resolving microservices’ security smells de-

tected in the LEMMA models, providing developers

with awareness of these security smells and offering

automated strategies for their resolution. The actual

process of resolving security smells in the source code

still requires manual intervention from software de-

velopers. However, by leveraging LEMMA’s code

generation functionalities in conjunction with the up-

dated model, it is possible to resolve selected security

smells at the implementation level as well.

7 RELATED WORK

Ponce et al. propose a set of microservice security

smells in (Ponce et al., 2022b), including refactor-

ings that resolve their effects. Automatically detect-

ing such smells in microservices and refactoring ap-

plications to resolve their effects is however still an

open issue. Indeed, to the best of our knowledge, the

Towards Resolving Security Smells in Microservices, Model-Driven

only available work in this direction is that by (Ponce

et al., 2022a), which assumes that smells have been

identiﬁed and proposes a trade-off analysis to decide

whether it is worth (or not) to apply a refactoring, de-

pending on how the security smell and refactoring im-

pact the overall application quality.

There are already some methods and tools for an-

alyzing microservices applications’ security, which

can also be used to detect other security smells.

For instance, (Rahman et al., 2019) proposes a

static analysis technique to detect security smells in

infrastructure-as-code (Morris, 2020) scripts. (Rah-

man et al., 2019) however,» differs from our proposal

in its objectives, as it focuses on detecting security

smells for infrastructure-as-code only, while we con-

sider the detection and refactoring microservice secu-

rity smells for different viewpoints, e.g., the service

or operation viewpoint.

Production-ready tools for security analysis, e.g.,

such as Kubesec.io,

Checkov,

OWASP Zed Appli-

cation Proxy (ZAP),

and SonarQube.

provide val-

idated solutions for vulnerability assessment and se-

curity weaknesses detection, which can also be used

for microservices applications. Our proposal com-

plements the analyses enacted by the above-listed

tools, enabling the detection and refactoring of the

microservice security smells in (Ponce et al., 2022b),

in addition to the vulnerabilities and security weak-

nesses they identify.

Additional existing approaches provide the possi-

bility to identify and resolve architectural smells for

microservices. (Pigazzini et al., 2020) and (Soldani

et al., 2021) propose two different solutions for de-

tecting architectural smells in microservice applica-

tions. They both share our baseline idea of starting

from smells identiﬁed with industry-driven reviews,

with (Pigazzini et al., 2020) picking those from (Taibi

and Lenarduzzi, 2018), while (Soldani et al., 2021)

picking those from (Neri et al., 2020). (Soldani et al.,

2021) actually also shares our baseline idea of using

MDE to detect and refactor smells. The main differ-

ence between (Pigazzini et al., 2020), (Soldani et al.,

2021), and our proposal relies on the considered types

of smells, with (Pigazzini et al., 2020) and (Soldani

et al., 2021) focusing on architectural smells. We

rather complement their results by enabling detection

and refactoring of microservice security smells from

(Ponce et al., 2022b).

Similar considerations apply to (Balalaie et al.,

2018) and (Haselböck et al., 2017), which both or-

https://kubesec.io

https://www.checkov.io

https://owasp.org/www-project-zap/

http://sonarqube.org/

ganize information retrieved from practitioners or

industry-scale projects into guidelines for designing

microservice applications while avoiding including

well-known architectural smells therein. We indeed

complement (Balalaie et al., 2018) and (Haselböck

et al., 2017) in their effort towards resolving smell oc-

currences in microservice applications by enabling to

detect microservices’ security smells and to refactor

them to resolve their possible effects.

Finally, it is also worth relating our microservice-

oriented proposal with existing solutions for detect-

ing smells in classical services. For instance, (Gar-

cia et al., 2009), (Arcelli et al., 2019) and (Sanchez

et al., 2015) present three different MDE approaches

to detect architectural smells in service, with (Garcia

et al., 2009) and (Arcelli et al., 2019) relying on UML

to model services, while (Sanchez et al., 2015) rely-

ing on Archery. (Arcelli Fontana et al., 2017) and

(Vidal et al., 2015) instead allow to analyze of the

source code of a service to detect the smells therein,

also supporting refactoring to resolve the occurrence

of identiﬁed smells. Similarly to the above-discussed

approaches, the difference between our proposal and

those in (Garcia et al., 2009), (Arcelli et al., 2019),

(Sanchez et al., 2015), (Arcelli Fontana et al., 2017),

and (Vidal et al., 2015) resides in the type of consid-

ered smells, with our proposal complementing their

results by enabling to detect and refactor security

smells in microservice applications.

8 CONCLUSIONS

We have introduced an approach for model-driven

resolution of microservices’ security smells based

on extending LEMMA to the purpose. Our ap-

proach process extended LEMMA functionalities to

detect the two most recognized microservices’ secu-

rity smells automatically and to recommend refactor-

ing strategies to resolve their effects.

To assess the feasibility of the proposed approach,

we have also presented its proof-of-concept imple-

mentation, also discussing how such implementation

enables detecting and refactoring microservice secu-

rity smells in the LEMMA model of an existing third-

party application. The presented approach introduced

a ﬁrst step towards automated, MDE-based security

smell resolution.

For future work, we plan to follow the exact mod-

eling and analysis methodology to extend the cur-

rent implementation into a full-ﬂedged prototype fea-

turing a model-driven resolution of security smells

occurring in MSA. Furthermore, we plan to include

software architecture reconstruction to automatically

ICSOFT 2023 - 18th International Conference on Software Technologies

derive security-aware LEMMA models based on the

current implementation of the software system to ease

the integration of our approach in MSA development.

We also plan to exploit the full-ﬂedged prototype

to validate and evaluate our method on real-world ap-

plications, with the goal of demonstrating how our ap-

proach facilitates the development process of MSA by

providing means for security smell resolution.

In this perspective, we also plan to assist devel-

opers in deciding whether/how to refactor a secu-

rity smell detected in an MSA, e.g., by integrating

our full-ﬂedged prototype with trade-off analyses and

code generation functionalities to automatically re-

solve the security smell also on the level of implemen-

tation. Additionally, we plan to extend our approach

to work with other microservice-related smells, e.g.,

architectural smells.

ACKNOWLEDGMENTS

This work was partially supported by ANID un-

der grant PIA/APOYO AFB180002, Instituto de

tecnología para la innovación en salud y bien-

estar, facultad de ingeniería (Universidad Andrés

Bello, Chile), and by the project hOlistic Sustain-

able Management of distributed softWARE systems

(OSMWARE, UNIPI PRA_2022_64), funded by the

University of Pisa, Italy.

REFERENCES

Arcelli, D., Cortellessa, V., and Pompeo, D. D. (2019). Au-

tomating performance antipattern detection and soft-

ware refactoring in UML models. In Wang, X., Lo,

D., and Shihab, E., editors, 2019 International Con-

ference on Software Analysis, Evolution and Reengi-

neering, , pages 639–643. SANER 2019, IEEE Com-

puter Society.

Arcelli Fontana, F., Pigazzini, I., Roveda, R., Tamburri, D.,

Zanoni, M., and Di Nitto, E. (2017). Arcan: A tool

for architectural smells detection. In Malavolta, I. and

Capilla, R., editors, 2017 IEEE International Con-

ference on Software Architecture Workshops, , pages

282–285. ICSA 2017 Workshops, IEEE Computer So-

ciety.

Balalaie, A., Heydarnoori, A., and Jamshidi, P. (2016). Mi-

croservices architecture enables devops: Migration to

a cloud-native architecture. IEEE Software, 33(3):42–

52.

Balalaie, A., Heydarnoori, A., Jamshidi, P., Tamburri,

D. A., and Lynn, T. (2018). Microservices migra-

tion patterns. Software: Practice and Experience,

48(11):2019–2042.

Bass, L., Clements, P., and Kazman, R. (2012). Soft-

ware Architecture in Practice. Addison-Wesley Pro-

fessional, 3rd edition.

Bass, L., Clements, P., and Kazman, R. (2013). Software

Architecture in Practice. Addison-Wesley, third edi-

tion.

Combemale, B., France, R. B., Jézéquel, J.-M., Rumpe, B.,

Steel, J., and Vojtisek, D. (2017). Engineering Mod-

eling Languages: Turning Domain Knowledge into

Tools. CRC Press, ﬁrst edition.

Di Francesco, P., Lago, P., and Malavolta, I. (2018). Migrat-

ing towards microservice architectures: An industrial

survey. In 2018 IEEE International Conference on

Software Architecture (ICSA), pages 29–38. IEEE.

Gannon, D., Barga, R., and Sundaresan, N. (2017). Cloud-

native applications. IEEE Cloud Computing, 4(5):16–

21.

Garcia, J., Popescu, D., Edwards, G., and Medvidovic, N.

(2009). Identifying architectural bad smells. In Win-

ter, A., Ferenc, R., and Knodel, J., editors, Proceed-

ings of the 2009 European Conference on Software

Maintenance and Reengineering, , pages 255–258,

USA. CSMR 2009, IEEE Computer Society.

Haselböck, S., Weinreich, R., and Buchgeher, G. (2017).

Decision models for microservices: Design areas,

stakeholders, use cases, and requirements. In Lopes,

A. and de Lemos, R., editors, Software Architecture,

, pages 155–170, Cham. Springer International Pub-

lishing.

Hassan, S., Ali, N., and Bahsoon, R. (2017). Microservice

ambients: An architectural meta-modelling approach

for microservice granularity. In 2017 IEEE Interna-

tional Conference on Software Architecture (ICSA),

pages 1–10. IEEE.

JHipster (2023). JHipster Domain Language (JDL). https:

//www.jhipster.tech/ jdl/ intro.

Kapferer, S. and Zimmermann, O. (2020). Domain-driven

service design: Context modeling, model refactor-

ing and contract generation. In Service-Oriented

Computing: 14th Symposium and Summer School

on Service-Oriented Computing, SummerSOC 2020,

Crete, Greece, September 13-19, 2020 14, pages 189–

208. Springer.

Knoche, H. and Hasselbring, W. (2019). Drivers and barri-

ers for microservice adoption – a survey among pro-

fessionals in Germany. Enterprise Modelling and In-

formation Systems Architectures, 14(1):1–35. German

Informatics Society.

Morris, K. (2020). Infrastructure as code. O’Reilly Media.

Neri, D., Soldani, J., Zimmermann, O., and Brogi,

A. (2020). Design principles, architectural smells

and refactorings for microservices: a multivocal re-

view. SICS Software-Intensive Cyber-Physical Sys-

tems, 35(1):3–15.

Newman, S. (2015). Building Microservices: Designing

Fine-Grained Systems. O’Reilly.

OMG (2017). OMG Uniﬁed Modeling Language (OMG

UML) version 2.5.1. Standard formal/17-12-05, Ob-

ject Management Group.

Towards Resolving Security Smells in Microservices, Model-Driven

Panichella, S., Rahman, M. I., and Taibi, D. (2021). Struc-

tural coupling for microservices. arXiv preprint

arXiv:2103.04674.

Pigazzini, I., Fontana, F. A., Lenarduzzi, V., and Taibi, D.

(2020). Towards microservice smells detection. In

Proceedings of the 3rd International Conference on

Technical Debt, page 92–97, New York, NY, USA.

TechDebt 2020, Association for Computing Machin-

ery.

Ponce, F., Soldani, J., Astudillo, H., and Brogi, A. (2022a).

Should microservice security smells stay or be refac-

tored? towards a trade-off analysis. In Gerostathopou-

los, I. et al., editors, Software Architecture, pages 131–

139. Springer International Publishing.

Ponce, F., Soldani, J., Astudillo, H., and Brogi, A. (2022b).

Smells and refactorings for microservices security: A

multivocal literature review. Journal of Systems and

Software, 192:111393.

Rademacher, F. (2022). A Language Ecosystem for Model-

ing Microservice Architecture. PhD thesis, University

of Kassel.

Rademacher, F., Sachweh, S., and Zündorf, A. (2020). De-

riving microservice code from underspeciﬁed domain

models using DevOps-enabled modeling languages

and model transformations. In 2020 46th Euromicro

Conference on Software Engineering and Advanced

Applications (SEAA), pages 229–236. IEEE.

Rahman, A., Parnin, C., and Williams, L. (2019). The seven

sins: Security smells in infrastructure as code scripts.

In 2019 IEEE/ACM 41st International Conference on

Software Engineering (ICSE), pages 164–175.

Richardson, C. (2019). Microservices Patterns. Manning

Publications.

Sanchez, A., Barbosa, L. S., and Madeira, A. (2015). Mod-

elling and verifying smell-free architectures with the

archery language. In Canal, C. and Idani, A., editors,

Software Engineering and Formal Methods, , pages

147–163, Cham. SEFM 2015, Springer International

Publishing.

Soldani, J., Muntoni, G., Neri, D., and Brogi, A. (2021).

The µtosca toolchain: Mining, analyzing, and refac-

toring microservice-based architectures. Software:

Practice and Experience, 51(7):1591–1621.

Soldani, J., Tamburri, D. A., and Heuvel, W.-J. V. D. (2018).

The pains and gains of microservices: A systematic

grey literature review. Journal of Systems and Soft-

ware, 146:215–232. Elsevier.

Sorgalla, J., Wizenty, P., Rademacher, F., Sachweh, S., and

Zündorf, A. (2021). Applying model-driven engineer-

ing to stimulate the adoption of devops processes in

small and medium-sized development organizations:

the case for microservice architecture. SN Computer

Science, 2(6):459.

Taibi, D. and Lenarduzzi, V. (2018). On the deﬁnition of

microservice bad smells. IEEE Software, 35(3):56–

62.

Terzi

c, B., Dimitrieski, V., Kordi

c, S., Milosavljevi

c, G.,

and Lukovi

c, I. (2018). Development and evaluation

of MicroBuilder: a model-driven tool for the speciﬁ-

cation of REST microservice software architectures.

Enterprise Information Systems, 12(8-9):1034–1057.

Taylor & Francis.

Thönes, J. (2015). Microservices. IEEE Software,

32(1):116–116.

Vidal, S., Vazquez, H., Diaz-Pace, J. A., Marcos, C., Gar-

cia, A., and Oizumi, W. (2015). JSpIRIT: A ﬂexi-

ble tool for the analysis of code smells. In Marín, B.

and Soto, R., editors, 34th International Conference

of the Chilean Computer Science Society, , pages 1–

6. SCCC 2015, IEEE Computer Society.

Zimmermann, O. (2017). Microservices tenets. Computer

Science - Research and Development, 32(3):301–310.

ICSOFT 2023 - 18th International Conference on Software Technologies