Computer Science Review 41 (2021) 100415

Contents lists available at ScienceDirect

Computer Science Review

journal homepage: www.elsevier.com/locate/cosrev

Review article

Securing microservices and microservice architectures: A systematic

mapping study
∗
Abdelhakim Hannousse a , , Salima Yahiouche b
a
Department of Computer Science, Université 8 Mai 1945 Guelma, BP 401, Guelma 24000, Algeria
b
LRS laboratory, Badji Mokhtar University, BP 12, Annaba 23000, Algeria

article info a b s t r a c t

Article history: Microservice architectures (MSA) are becoming trending alternatives to existing software development
Received 21 June 2020 paradigms notably for developing complex and distributed applications. Microservices emerged as
Received in revised form 4 May 2021 an architectural design pattern aiming to address the scalability and ease the maintenance of
Accepted 16 June 2021
online services. However, security breaches have increased threatening availability, integrity and
Available online 27 June 2021
confidentiality of microservice-based systems. A growing body of literature is found addressing security
Keywords: threats and security mechanisms to individual microservices and microservice architectures. The
Microservices aim of this study is to provide a helpful guide to developers about already recognized threats on
Microservice architectures microservices and how they can be detected, mitigated or prevented; we also aim to identify potential
Security research gaps on securing MSA. In this paper, we conduct a systematic mapping in order to categorize
Systematic mapping threats on MSA with their security proposals. Therefore, we extracted threats and details of proposed
solutions reported in selected studies. Obtained results are used to design a lightweight ontology
for security patterns of MSA. The ontology can be queried to identify source of threats, security
mechanisms used to prevent each threat, applicability layer and validation techniques used for each
mechanism. The systematic search yielded 1067 studies of which 46 are selected as primary studies.
The results of the mapping revealed an unbalanced research focus in favor of external attacks; auditing
and enforcing access control are the most investigated techniques compared with prevention and
mitigation. Additionally, we found that most proposed solutions are soft-infrastructure applicable layer
compared with other layers such as communication and deployment. We also found that performance
analysis and case studies are the most used validation techniques of security proposals.
© 2021 Elsevier Inc. All rights reserved.

Contents

1. Introduction......................................................................................................................................................................................................................... 2
2. Background.......................................................................................................................................................................................................................... 2
2.1. Microservice architectures .................................................................................................................................................................................... 2
2.2. Systematic mapping .............................................................................................................................................................................................. 3
3. Related work ....................................................................................................................................................................................................................... 3
4. Research methodology ....................................................................................................................................................................................................... 4
4.1. Research objectives................................................................................................................................................................................................ 4
4.2. Research questions ................................................................................................................................................................................................ 4
4.3. Search process........................................................................................................................................................................................................ 4
4.4. Study selection process ......................................................................................................................................................................................... 5
4.5. Inclusion and exclusion criteria ........................................................................................................................................................................... 5
4.6. Quality assessment ................................................................................................................................................................................................ 5
4.7. Data extraction process......................................................................................................................................................................................... 6
4.8. Data synthesis ........................................................................................................................................................................................................ 6
5. Results of the mapping...................................................................................................................................................................................................... 6
5.1. Overview of selected studies................................................................................................................................................................................ 6
5.2. MSA security threats (RQ1) .................................................................................................................................................................................. 8

∗ Corresponding author.
E-mail addresses: [email protected] (A. Hannousse), [email protected] (S. Yahiouche).

https://doi.org/10.1016/j.cosrev.2021.100415
1574-0137/© 2021 Elsevier Inc. All rights reserved.
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

5.3. Microservice security mechanisms (RQ2) ........................................................................................................................................................... 8

5.3.1. Microservice security application levels (RQ3)................................................................................................................................... 9
5.3.2. MSA security mechanisms target platforms (RQ4) ............................................................................................................................ 10
5.3.3. Microservice security V&V methods (RQ5) ......................................................................................................................................... 10
6. An ontology for securing MSA .......................................................................................................................................................................................... 11
7. Discussion............................................................................................................................................................................................................................ 12
7.1. Bias towards external threats, user and data attacks ...................................................................................................................................... 12
7.2. Lack of innovative solutions for authorization and mitigation ...................................................................................................................... 12
7.3. Lack of appropriate solutions to secure individual microservices ................................................................................................................. 13
7.4. Lack of appropriate solutions to emerging technologies................................................................................................................................. 13
7.5. Absence of appropriate comparison techniques............................................................................................................................................... 13
8. Threats to validity .............................................................................................................................................................................................................. 13
8.1. Construct validity ................................................................................................................................................................................................. 13
8.2. Internal validity .................................................................................................................................................................................................... 14
8.3. External validity.................................................................................................................................................................................................... 14
8.4. Conclusion validity ............................................................................................................................................................................................... 14
9. Conclusion ........................................................................................................................................................................................................................... 14
Declaration of competing interest.................................................................................................................................................................................... 14
References ........................................................................................................................................................................................................................... 14

systems. We systematically identify existing studies addressing

1. Introduction threats and proposing security solutions to MSA. We apply a thor-
ough protocol to extract, classify, and organize reported threats
Nowadays, systems are becoming more complex, larger and with the security solutions proposed to mitigate and prevent
more expensive due to the rapid growth of requirements and them. The contributions of the study can be summarized as:
adoption of new technologies. Moreover, due to competitors,
many companies need to make changes to their systems as fast as 1. identify the most relevant threats concerning microservices
possible and without affecting their systems availability. This re- and microservice architectures
quires appropriate designs, architectural styles and development 2. point out the set of security mechanisms used to detect,
processes. Software engineering provides different paradigms to mitigate and prevent those threats
partially meet those needs by decomposing software systems into 3. determine the set of techniques and tools used to examine
fine-grained software units for better modularity, maintainability and validate proposed solutions
and reusability, and hence reduce time-to-market. 4. end up with a lightweight ontology for security in mi-
Recently, microservice architectures (MSA) [1] has emerged croservice architectures
as a new architectural style allowing building software systems
The reminder of this paper is structured as follows: Section 2
by composing lightweight services that perform very cohesive
gives a succinct background on used techniques and approaches
business functions. Microservices are the mainstay of MSA. A
in this paper, specifically, microservice architectures and sys-
microservice is a fine-grained software unit that can be cre-
tematic mapping elaboration process; Section 3 overviews and
ated, initialized, duplicated, and destroyed independently from
discusses related works; Section 4 details our research methodol-
other microservices of the same system. Moreover, microservices
ogy; Section 5 presents the mapping results; Section 6 describes
can be deployed across heterogeneous execution platforms over
the proposed ontology for MSA; Section 7 highlights potential re-
the network. Using microservices enables high scalability and
search gaps; Section 8 discusses threats to validity and Section 9
flexibility of large scale and distributed software systems.
concludes the paper.
Although the advantages brought by adopting microservice
architectures in developing complex systems, MSA as a novel
2. Background
technology comes with many flaws [2] and security is one of the
serious challenges that need to be tackled [1]. In fact, security is a
2.1. Microservice architectures
longstanding problem in networking systems, but with microser-
vices, security becomes more challenging. This is due to the large
Microservices is a trending architectural style that aim to
number of entry points and overload on communication traffic
design complex systems as collections of fine grained and loosely
emerged by decomposing systems into smaller, independent and
coupled software artifacts called microservices; each microser-
distributed software units. Moreover, trusts cannot simply be
vice implements a small part or even a single function of the busi-
established between individual microservices in the network that
ness logic of applications [3]. Their efficient loose coupling en-
often come from different and unknown providers.
ables their development using different programming languages,
Due to the massive attacks reported on companies adopt-
use different database technologies, and be tested in isolation
ing MSA1 such as Netflix and Amazon, dealing with security
with respect to the rest of underlying systems. Microservices may
breaches became an urgent need. Several works in the literature
communicate with each other directly using an HTTP resource API
have noticed the need to investigate security of MSA [1,3,4].
or indirectly by means of message brokers (see Fig. 1). Microser-
However, security threats are diverse and are continually in-
vices can either be deployed in virtual machines or lightweight
creasing. Security proposals are also increasing and vary from
containers. The use of containers for deploying microservices
securing individual microservices into complete architectures and
is preferred due to their simplicity, lower cost, and their fast
infrastructures.
initialization and execution.
In this article, we conduct a systematic mapping to uncover
Regarding software quality attributes, adopting microservices
the main threats menacing the security of microservice-based
increases reusability and interoperability, enables scalability and
enhances maintainability of complex software systems. Within
1 Threatpost: https://threatpost.com. adequate distributed platforms and technologies, microservices
2
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Fig. 1. Microservice architecture.

can easily be deployed, replicated, replaced, and destroyed inde- from primary papers are visualized, results are interpreted, re-
pendently without affecting systems availability. Moreover, im- search questions are answered and the mapping is validated and
plementing a single business capability per microservices allows documented. Fig. 2 depicts the overall process for conducting
their use in different applications and application domains. The systematic mapping studies as proposed in [8]. The quality as-
main characteristics that differentiate microservices architectural sessment step is depicted in Fig. 2 within a dashed line box since
style from monolithic and its ancestor service-oriented architec- it is optional as stated in [6,8].
tures is the smaller size, scalability and independence of each unit
constituting a system. 3. Related work
Microservices are getting more attention and becoming
adopted in industry. Currently, microservices are used by widely We found in the literature several secondary studies (sys-
recognized companies such as Coca Cola, Amazon, eBay and tematic reviews or mappings) dedicated to investigate the state-
NetFlix. Specifically, microservices are becoming more popular in of-the-art of MSA in general. Surprisingly, few works are found
software and IT service companies [5]. focusing on security aspects in MSA. All found studies, except
Although the advantages brought by adopting microservice the work of Vale et al. [9], are either platform or technology
architectures in developing complex systems, security is one of dependent investigations.
the serious challenges that need to be tackled. Thus, there is an Vale et al. [9] conducted a similar investigation to our study.
urgent need to identify and check current trends in overcoming They conducted a systematic mapping to reveal adopted security
security challenges in microservice architectures which is the aim mechanisms for microservice-based systems. The study exam-
of the present paper. ined 26 papers published from November 2018 to March 2019.
Vale et al. [9] focused only on security mechanisms and cate-
2.2. Systematic mapping gorized the 18 identified mechanisms according to their focus,
and classified validation techniques according to their nature. The
A systematic mapping is a kind of evidence-based software study revealed that (1) authentication and authorization are the
engineering (EBSE) [6]. The aim of a systematic mapping is to most frequently adopted mechanisms for securing microservices,
provide an overview of a research area by building a classification (2) case studies and experiments are the most validation tech-
scheme and structuring evidences on a research field. niques used for security proposals, (3) absence of patterns for
Peterson et al. [7,8] has proposed an overall process for the microservices-based systems security. Our study is broader and
elaboration of systematic mappings. The process is composed of improves Vale et al. [9] work in several ways. In this study we
three main steps: planning, conducting and reporting. By planning, include published papers since 2011. Moreover, besides security
one can start by justifying the need and scope of the mapping, mechanisms, we also focus on identifying security threats and
formulate the set of research questions, develop and validate a the applicability of proposed solutions regarding their execution
protocol specifying all the decisions relevant to conducting the platforms and architectural layers.
mapping. The protocol includes the identification of search terms, Yu et al. [10] presented a survey on security in microservice-
search strategy, literature sources that need to be used to retrieve based fog applications. The survey included papers published
relevant papers, how and in which base found papers are selected between 2010 and 2017. The focus of Yu et al. [10] was domain
and included in the mapping, what data need to be extracted specific; they focused on determining security challenges and
from selected papers and how extracted data are synthesized and potential solutions of adopting microservices in fog computing.
classified. By conducting, the initially validated protocol from the The security issues identified by the study concerns containers,
planning step is executed; thus, the identified sources are used to data, and network vulnerabilities. They also proposed a solution
retrieve papers, found papers are examined for relevance; useful for inter-service communication in fog applications.
data are then extracted from admitted papers and extracted Monteiro et al. [11] identified a set of elements related to
data are synthesized and classified. By reporting, extracted data microservices implementation in cloud computing. They reported
3
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Fig. 2. The overall process for elaborating systematic mapping.

the same security aspects discussed by Yu et al. [10]. They con- of found papers, propose or use an existing classification scheme,
cluded that availability and trustworthiness are the two major data extraction and studies mapping. In the sequel, we describe
security requirements in MSA. the details of each step.
Nkomo et al. [12] conducted a systematic review on prac-
tices that can be incorporated into the development process 4.1. Research objectives
of microservice-based systems. The focus of Nkomo et al. [12]
was to propose general guidelines where security can be tackled The adoption of microservice architectures in developing high-
earlier when developing microservice-based applications putting sensitive systems such as industry, raises a question on the risks
much emphasis on microservices composition. They ended up associated with the deployment of microservices in distributed
with five security-focused development activities: (1) identify and highly accessible platforms. In this study, we aim to iden-
security requirements of microservice composition, (2) adopt se- tify the threats which could target individual microservices and
cure programming best practices, (3) validate security require- microservice architectures and may endanger systems’ security,
ments and secure programming best practices, (4) secure con- stability and reliability. Moreover, we aim to collect and catego-
figuration of runtime infrastructure, and (5) continuously mon- rize all known threats and the endeavors to mitigate and prevent
itor the behavior of microservices. Considering security as a pri- them in easy-to-handle, reliable and extensible structures such
mary concern throughout the life-cycle of microservice-based as ontology. This enables: (1) researchers and practitioners to
systems is mandatory; however, experiences show that all se- have an overview of the risks that could threaten their existing
curity threats cannot be identified earlier especially with the or future systems and (2) share experiences on how to mitigate
continuous evolving of technologies. and prevent already recognized security threats. To sum up, the
Sultan et al. [13] presented a survey on the security of con- objectives of this research can be reformulated as follows:
tainers; they identified main threats due to images, registries, O1. identify and categorize threats targeting individual mi-
orchestration, containers themselves, side channels and host OS
croservices and microservice architectures.
risks. They distinguished two kinds of solutions to containers
O2. recognize and categorize the endeavors to detect, mitigate
security: software-based and hardware-based solutions without
and prevent recognized security threats.
further investigation of proposed solutions. Belair et al. [14] com-
O3. discern the set of validation techniques and tools used to
plements the work of Sultan et al. [13] by proposing a taxonomy
corroborate identified security mechanisms.
for containers’ security proposals. Belair et al. [14] focused on se-
O4. deduce and share a lightweight ontology for securing
curity solutions at the infrastructure level putting much empha-
microservice based systems.
sis on data transmission through virtualization. Three categories
were identified: configuration-based, code-based and rule-based
4.2. Research questions
defense. They reported the fact that Linux security model (LSM),
the powerful defense framework targeting Linux, cannot be easily
adapted to containers to improve security. The aim of this study is to identify the set of security vul-
Compared with the works of Yu et al. [10] and Monteiro nerabilities and how they can be tackled in microservice-based
et al. [11], our study is domain and platform independent and systems. Thus, we formulate our research questions in light of
includes more recent endeavors with broader focus on proposed the aims of our study and following the guidelines of Kuhrmann
solutions to security threats. Compared with the works in [13] et al. [16]. This study is conducted with five main questions
and [14], we focus in our study on security issues concerning MSA in mind. These questions are described in Table 1 with their
in general and not only containers. corresponding motivation and related objectives.

4. Research methodology 4.3. Search process

In this section we present the details of the protocol adopted Search string used in this study is designed to be generic
for conducting this mapping study. Following the guidelines of and simple. It is constructed based on search terms concerned
Peterson et al. [7] and Felderer and Craver [15], a systematic with population and intervention as suggested by Petticrew and
mapping study should include the following primary steps: a defi- Roberts in [17]. Population refers to the application area which is
nition of research questions, search for relevant papers, screening microservices and microservice architectures where intervention
4
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Table 1
Research questions with their motivations and relevant objectives.
No Research Question Main Motivation Objectives
RQ1 What are the most addressed security threats, This research question distinguishes the list of O1, O4
risks, and vulnerabilities of microservices and mostly treated vulnerabilities from those
microservice architectures and how they can needing further investigations.
be classified?
RQ2 What are existing approaches and techniques This research question provides an overview of O2, O4
used for securing microservices and existing approaches and techniques used for
microservice architectures and how they can securing microservice-based systems.
be classified?
RQ3 At what level of architecture the proposed This research question indicates where O2, O4
techniques and approaches are applicable for security is applied highlighting the less
securing microservices? focused levels of microservice architectures.
RQ4 What domains or platforms are the focus of This research question shows whether the O2, O4
existing solutions for securing microservices focus of the proposed solutions is platform
and microservice architectures? specific or platform independent.
RQ5 What kind of evidence is given regarding the This research question evaluates the maturity O3
evaluation and validation of proposed of existing security techniques highlighting the
approaches and techniques for securing set of empirical strategies used to validate
microservices and microservice architectures? proposed solutions.

is security, vulnerabilities and attacks. Accordingly, final adopted Table 2

search string is : Inclusion criteria.
ID Criteria
("microservice" OR "micro-service" OR "micro service") I1 papers published since 2011 including early publications
AND I2 papers written in English
("architecture" OR "design" OR "system" OR "structure") I3 papers subject to peer reviews
AND I4 papers including studies conducted with security aspects of
microservices or microservice architectures as their primary topics
("security" OR "vulnerability" OR "attack")
I5 papers proposing frameworks, techniques, methods, or tools to
For retrieving relevant studies, we followed the guidelines of secure microservices or microservice architectures
I6 papers presenting qualitative or quantitative evaluation of security
Kuhrmann et al. [16]. Thus, we adopted the use of the following
techniques used for microservices or microservice architectures
online academic libraries:

• IEEE Xplorer (https://ieeexplore.ieee.org) Table 3

• ACM Digital Library (https://dl.acm.org) Exclusion criteria.
• SpringerLink (https://link.springer.com) ID Criteria
• ScienceDirect (https://www.sciencedirect.com/) E1 papers addressing security in distributed platforms and technologies
such as clouds without explicit referring to microservices
• Wiley Online Library (https://onlinelibrary.wiley.com)
E2 papers describing general aspects of microservice architectures
without putting much emphasis on the security issue
To avoid missing relevant studies, we complement our au- E3 tutorial papers and editorials
tomatic search by conducting recursive backward and forward E4 papers presenting reviews, surveys or secondary studies on the
snowballing on selected studies as suggested by Wohllin [18,19]. security of microservices or microservice architectures
By backward snowballing, we check the relevance of references in E5 books or book chapters, because they usually undergo little peer
review and present general ideas already published in journals or
approved papers. By forward snowballing, we check the relevance conferences
of papers citing approved papers. The snowballing is recursively E6 papers without full text available
applied to each newly approved paper. Google Scholar is used as
a sole source for forward snowballing.

to cover all published papers since 2011 including early publi-

4.4. Study selection process
cations. The starting year 2011 is adopted since there was no
consensus on the term microservice architectures prior 2011 [3].
The set of retrieved papers by automatic search followed two Only English written papers addressing security aspects or secu-
screening stages. In the first stage, titles and abstracts were read rity solutions to microservices or microservice architectures are
to measure relevance. In the second stage, full texts of papers included. The full list of adopted inclusion and exclusion criteria
were examined to check if they meet our inclusion criteria. The are presented in Tables 2 and 3 respectively.
list of all the papers are screened separately by the two au-
thors; decisions are exchanged and conflicts are discussed and 4.6. Quality assessment
solved. Found papers from snowballing are also screened sepa-
rately by the two authors before deciding whether to be included As advised by Peterson et al. [8], quality assessment of iden-
or excluded. tified papers is also required for mapping studies to answer that
sufficient information is available for data extraction. Therefore,
4.5. Inclusion and exclusion criteria we conduct a quality assessment process to evaluate the overall
strength and included details of selected papers. A questionnaire
The number of retrieved papers by online academic libraries is formed of four items has been considered. The questionnaire is
reduced by specifying a strict number of inclusion and exclusion inspired from [20,21] and adapted to our research topic. The set
criteria. In this study, only peer-reviewed papers from journals of adopted assessment criteria are summarized in Table 4 with
and conferences are included. The automatic search is conducted their associated scores.
5
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Table 4 Table 6
Quality assessment criteria. Number of studies returned by each repository.
ID Criteria Score Repository Search results
QA1 Does the study clearly address any of security Yes/No IEEE Xplorer 50
issues in microservice architectures? ACM Digital Library 46
QA2 Does the study present a clear solution to any {0, 0.5, 1} SpringerLink 678
security threat in microservice architectures? ScienceDirect 255
QA3 Has the study been cited by other articles? {0, 1} Wiley Online Library 38
QA4 Has the study been published in ranked {1, 0.5, 0} Total 1067
journal or conference proceedings

existing taxonomies [1,11,22] in identifying categories and their

In this study, score 1 is awarded to studies when an item could
relationships. We also used grounded theory [23] as a comple-
be answered as Yes and 0 when the answer was No (case of QA1).
mentary approach to generate missing categories from extracted
For QA2 criterion, score 1 is attributed to studies presenting a
data items. Specifically, we used open coding and selective coding
detailed and validated solution to a security threat, score 0.5 is
to identify categories and their relationships with existing cate-
attributed to studies providing only an overview of the solution
gories from D6, D9 and D10-11. In this study, grounded theory is
or framework, and score 0 is attributed to studies without clear
used in an iterative process, where categories and subcategories
solutions. For QA3 item, score 1 is attributed to studies with
are changed in each iteration until reaching a stability state.
number of citations greater or equal 3; score 0 is attributed to
studies with number of citations less than 3. Google Scholar is
5. Results of the mapping
considered to get the number of citations. This latter is adopted
to not penalize early publications. For QA4 item, paper sources
In this section we describe and detail the results of the map-
are ranked following the CORE conference ranking: A or B (+1),
ping study answering the five research questions outlined in
C (+0.5) and not ranked (0) and Journal Citation Reports (JCR):
Section 4.2.
Q1-2(+1), Q3-4 (0.5), not ranked (0). The four adopted criteria
are treated equally and the total score of each study is calculated 5.1. Overview of selected studies
by summing up their four measured values. Only studies with a
quality score greater than or equal 2 are included in this study. The search process is conducted in December 2019 and yielded
46 distinct papers published since 2011. The designed query is
4.7. Data extraction process applied to the set of selected libraries. Table 6 shows the number
of returned papers by each library.
Following the guidelines of Peterson et al. [7] a data extraction The set of 1067 retrieved papers by the different search en-
form is designed as illustrated in Table 5. Each paper is described gines are gathered and duplicate papers are removed. This re-
in terms of its metadata such as year of publication, source and duces the number to 1065. By screening titles and abstracts of
type. In addition, a set of required information for our analysis remaining papers, 1015 papers are excluded for their irrelevance.
are extracted. These include the list of security threats or attacks After checking the inclusion and exclusion criteria, only 37 papers
addressed by the study, proposed solutions, application level of are approved. By conducting recursive backward and forward
proposed solutions, validation method and application platforms. snowballing, 9 more papers are added. Two snowballing cycles
are performed before reaching a steady state. In the first round,
4.8. Data synthesis 7 new papers are included; in the second round, 2 more papers
are added. Fig. 3 depicts the overall selection process.
We noticed a lack of a consensus on detailed taxonomies for Fig. 4 shows the distribution of selected studies according to
security threats and security mechanisms; this prevents mapping their publication year and source. We notice that, although the
all the selected studies to appropriate and distinct categories earlier emergence of MSA in 2011, the interest into securing
answering research questions RQ1 and RQ2. Moreover, due to the microservices and microservice architectures is considered few
diversity of applications used in selected studies, their targeted years later and start getting more attentions since 2015. Fig. 4
platforms and used verification and validation techniques, it was also shows that the maximum number of publications come from
necessary to properly categorize those studies answering RQ3, IEEE Xplorer and none from Wiley meets our inclusion criteria.
RQ4 and RQ5. Table 7 shows the complete list of selected studies with their
For mapping properly all the selected studies to proper cate- year, type of publication, how they are found and their measured
gories for each research question, we used our experiences and quality assessment score.

Table 5
Data extraction form.
ID Data item Description RQ
D1 Study ID first author name + year
D2 Year year of the publication
D3 Source source of the publication
D4 Type conference or journal paper
D5 Category analysis, solution proposal or case study
D6 Threats addressed security threats RQ1
D7 Source of Threats internal or external RQ1
D8 Solution type general protection measures, framework, technique, tool or methodology proposal RQ2
D9 Security mechanisms set of security mechanisms proposed or used in the study RQ2
D10 Applicability level architectural level where the security mechanism is applied RQ3
D11 Validation method verification and validation techniques used to check the feasibility of the proposed solution RQ5
D12 Domain/Platform domains or platforms applicable for the proposed solution RQ4

6
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Table 7
List of selected studies with their quality assessment score: C: Conference paper,
J: Journal paper, A: Automatic search, S: Snowballing.
ID Cite Year Type Publisher Search type Score
p1 [12] 2019 C Springer A 3
p2 [24] 2018 C Springer A 3
p3 [25] 2020 C Springer A 3
p4 [26] 2017 C Springer A 4
p5 [27] 2017 C Springer A 3
p6 [28] 2018 C Springer A 3
p7 [29] 2019 C Springer A 3
p8 [30] 2018 C IEEE A 3
p9 [31] 2018 C IEEE A 3
p10 [32] 2018 C IEEE A 4
p11 [33] 2016 C IEEE A 3
p12 [34] 2015 C IEEE A 3.5
p13 [35] 2018 C IEEE A 2
p14 [36] 2017 C IEEE A 4
p15 [37] 2017 C IEEE A 4
p16 [38] 2016 C IEEE A 3
p17 [1] 2018 C IEEE A 4
p18 [39] 2018 C IEEE A 3
p19 [40] 2019 J IEEE A 4
p20 [41] 2019 C IEEE A 3.5
p21 [42] 2019 C IEEE A 3
p22 [43] 2018 C IEEE A 4
p23 [44] 2018 C IEEE A 3
p24 [45] 2019 J IEEE A 4
p25 [46] 2017 C IEEE S 3
p26 [47] 2018 C IEEE S 4
p27 [48] 2019 J IEEE S 3
p28 [49] 2016 J IEEE S 4
p29 [50] 2019 J JSW S 3
p30 [51] 2017 J IOP S 3
p31 [52] 2019 C CITRENZ S 2
p32 [53] 2018 J IJERT S 3
p33 [54] 2019 J IASKS S 3
p34 [55] 2018 C Springer A 2
p35 [56] 2019 C ACM A 2
p36 [57] 2017 C ACM A 3
p37 [58] 2018 C ACM A 3
p38 [59] 2018 C ACM A 4
p39 [60] 2019 C ACM A 4
p40 [61] 2019 C ACM A 4
p41 [62] 2019 C ACM A 4
Fig. 3. Paper selection process. p42 [63] 2019 C ACM A 3
p43 [64] 2019 J Science Direct A 4
p44 [65] 2018 J Science Direct A 3
Following the guidelines of Kuhrmann et al. [16], we also p45 [66] 2019 J Science Direct A 3
experienced the use of Word Clouds to analyze the appropri- p46 [67] 2019 J Science Direct A 4
ateness of our result set of primary studies. Fig. 5 illustrates
the most frequent words used in selected papers based on their
titles and abstracts. The Figure shows that the most used words service. Attacks, vulnerabilities and risks are rarely used in titles
are microservice, security, application, architecture, system and and abstracts.

Fig. 4. Distribution of selected studies by year and digital library.

7
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Fig. 5. Keywords cloud of primary studies.

Fig. 7. MSA security solutions.

Table 8 shows the set of MSA security threats addressed by

primary studies grouped by category. The results revealed that
unauthorized access, sensitive data exposure and compromis-
ing individual microservices are the most treated and addressed
threats by contemporary studies. In addition, infrastructure at-
tacks are the most diverse but with less addressed attacks in
selected studies.

5.3. Microservice security mechanisms (RQ2)

Due to the diversity of proposed solutions, we classify MSA

security mechanisms addressed in primary studies regarding the
Fig. 6. MSA security source of threats. nature of their proposals as follows:

• General protection measures: use of general security tech-

niques to mitigate common known threats in MSA, or a set
5.2. MSA security threats (RQ1) of general guidelines on choosing appropriate languages and
technologies.
Microservice architecture as an emerging development • Framework-based solutions: architectural frameworks for
paradigm in software engineering brings new security threats and MSA incorporating specific modules to handle some security
vulnerabilities. These threats may come from insiders (i.e. inter- aspects and mechanisms such as authorization, continuous
nal attacks) or from outsiders (i.e. external attacks). For proper monitoring, diagnosis.
securing microservice-based systems, all threats, regardless of • Technique-based solutions: newly designed or adopted tech-
their origin, need to be detected and prevented using either niques from other domains to mitigate or prevent some
available mitigation techniques or through proposing innovative security threats in MSA.
solutions. In this study, we identify the focus of existing endeav- • Tool-based solutions: newly developed tools implementing
ors with respect to the source of threats (internal, external or security measures.
both). Fig. 6 depicts the distribution of identified and selected • Algorithm-based solutions: new algorithms conceived for the
studies regarding the addressed source of threats. The results detection or prevention of security threats.
show that 63% of primary studies focus on external attacks, only • Protocol-based solutions: new protocols conceived for the
13% focus on internal attacks and 24% focus on both source protection of communications among the different MSA ar-
of threats. This clearly indicates an unbalanced research focus chitectural elements.
towards external attacks. • Analysis: experimentation, comparison or discussion of ex-
Due to the plethora of taxonomies of security threats and isting security mechanisms of MSA.
lack of a consensus among their categorization, we adopted, a
Our investigation (see Fig. 7) shows that 33% of the studies
classification based on targets of attacks. Accordingly, threats in
proposed new techniques for securing MSA and 31% proposed
MSA can be classified into: framework-based solutions and 13% proposed general protection
measures. Few studies developed new tools, algorithms or pro-
• User-based attacks: attacks where users are involved directly
tocols. Specifically, the authors of P17 have analyzed existing
(i.e. malicious user actions) or indirectly (i.e. inadvertent
security mechanisms and proposed a framework based on the
insider actions).
insights of the conducted analysis.
• Data attacks: threats targeting sensitive data that can be Proposed solutions for securing microservices and microser-
disclosed and manipulated by attackers. vice architectures can be classified into proposals for enforcing
• Infrastructure attacks: attacks targeting MSA architectural Access Control (i.e. authentication and/or authorization policies),
elements and platforms such as monitors, discovery service, auditing, mitigation and prevention:
message broker, load balancer, etc.
• Software attacks: threats involving code transformation or • Access Control - Authentication: techniques used to verify the
injection for malicious purposes. identity of users requiring access to MSA resources and data.
8
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Table 8
MSA security threats per category.
Threats Percentage Studies
User-based Attacks 58.70%
Brute Force Attack 4.35% [50,52]
Cross-Site Request Forgery (CSRF) 13.00% [28,29,50,52,55,57]
Spoofing 4.35% [28,47]
Malicious Insider 4.35% [29,45]
Unauthorized Access 50.00% [12,25,28–31,33,35–37,43,46,47,50–53,58–60,64–66]
Violate non-repudiation 2.17% [24]

Data Attacks 47.83%

Eavesdropping 2.17% [64]
Heartblead 4.35% [28,47]
Man in The Middle attack (MiTM) 6.52% [28,37,61]
Padding Oracle On Downgraded Legacy Encryption attack (POODLE) 2.17% [28]
Replay attack 6.52% [37,54,65]
Sensitive data exposure 30.43% [24,26,28,31,35,36,41,45,46,49,60,64,66,67]
Sniffing attack 6.52% [25,28,29]

Infrastructure Attacks 41.30%

Compromise containers 15.21% [1,37,40,55–57,62]
Compromise virtual machines 8.70% [1,34,55,57]
Compromise discovery service 4.35% [12,28]
Compromise hypervisor 8.70% [1,26,28,49]
Compromise management interface 2.17% [45]
Compromise network nodes 2.17% [1]
Compromise operating systems 4.35% [26,49]
Downgrade attack 4.35% [24,58]
Hardware backdoors 2.17% [28]
Malicious images 4.35% [28,62]
Malicious provider 2.17% [28]
Misconfiguration 4.35% [28,43]
Port scan attack 2.17% [25]
Sandbox escape 2.17% [28]
Session hijacking 4.35% [28,29]
Stress attack 4.35% [44,45]
Cold boot attack 2.17% [26]

Software Attacks 50.00%

Code reuse attack 4.35% [39,61]
Compromise microservices 32.61% [1,27,28,32,34,40,42,43,47,54,55,57,62,65,67]
Disrupt sensitive operation 2.17% [24]
Denial of Service (DoS) 17.39% [28,37,50,52,55,57,63]
Injection 15.22% [1,29,50,52,55,57,63]

• Access Control - Authorization: techniques used to check 5.3.1. Microservice security application levels (RQ3)
users’ permissions for accessing specific MSA resources or The adoption of MSA as an architectural design of distributed
data. applications introduces security vulnerabilities in different archi-
• Auditing: techniques applied at runtime for discovering se- tectural layers. Thus, security measures need to be taken in every
curity gaps and may: (1) subsequently initiate appropriate layer of MSA. In this study, we distinguish the following layers:
measures or (2) simply report security breaches to relevant
• Microservice: Individual microservices are the mainstays of
supervisory authority.
MSA, those microservices can be blocked or compromised
• Mitigation: techniques that limit the damage of attacks when through injection of malicious code. Thus, security measures
they appear. Mitigation techniques can be integrated into to adopt only trusted microservices and protect them from
existing microservice-based systems. internal and external attacks need to be taken.
• Prevention: techniques that try to stop attacks from hap- • Composition: Connections among microservices can be bro-
pening in the first place. Prevention techniques need to be ken. Moreover, compromising a single microservice may
considered when developing new microservice-based sys- affect the security of the whole system due to the in-
tems. secure configuration options for individual microservices,
their locations and inter-connections. Several security mea-
Table 9 shows the list of proposed solutions mapped into our sures need to be taken at this level to secure the overall
classification with the proportion rate for each proposal with architecture of microservice-based systems.
respect to the total set of primary studies. The results show that • API: Finely tuned attacks on APIs can bypass traditional se-
much emphasis is put on proposing auditing techniques (43.48%), curity measures provided by API gateways. Hence, assets can
enforcing authentication and/or authorization (39.13%2 ), and pre- be accessed and controlled by malicious users. Appropriate
vention (34.78%), where less attention is being paid to mitigation security measures should be taken at API gateways to avoid
(10.87%). such vulnerabilities.
• Communication: Data exchanged between microservices
through event-buses can be intercepted and altered by ma-
2 This value is calculated by collecting all the papers from authorization licious insiders. Thus, securing communication channels be-
and/or authentication categories and removing duplicates; the obtained number tween microservices is mandatory for securing microservice-
is divided by the total number of papers. based systems.
9
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Table 9
MSA security mechanism per category.
Security Mechanisms Percentage Studies
Authentication 28.26%
Centralized Access Control Manager 6.52% [29,33,37]
Certificates 6.52% [12,28,47]
Open ID 6.52% [30,48,59]
Single Sign On (SSO) 4.35% [30,51]
White-list HTTP/IP 4.35% [12,53]
HIP exchange protocol 2.17% [37]
J-PAKE protocol 4.35% [54,65]
Distribute sessions 2.17% [51]
HTTP signatures 2.17% [53]

Authorization 21.74%
Attribute Based Access Control (ABAC) 2.17% [33]
Role Based Access Control (RBAC) 6.52% [29,54,59]
R/W Permission to message broker 2.17% [12]
OAuth 2 17.39% [29,30,33,48,50,52,53,59]

Authentication & Authorization 23.91%

JSON Web Token (JWT) 17.39% [12,28,30,36,48,51,53,59]
Firewalls 8.70% [25,32,33,48]

Auditing 43.48%
Continuous monitoring 34.78% [1,24,25,27,32,34,42–44,48,55–57,60,62,66]
Scan container images 2.17% [12]
Static/Dynamic code analysis 8.70% [28,49,60,67]
Machine learning 6.52% [32,43,56]
Intrusion detection 4.35% [1,48]

Mitigation 10.87%
Roll-back/Restart microservices 2.17% [1]
Scale up/down N-variant microservices 2.17% [1]
Short-lived tokens 2.17% [29]
Diversification 4.35% [1,39]
IP shuffling 2.17% [40]
Live migration 4.35% [40,42]
Deception 2.17% [42]
Isolation of suspicious microservices 2.17% [1]

Prevention 34.78%
Blockchain technology 4.35% [31,35]
Encryption 10.87% [1,24,37,46,64]
Hardware Security Module (HMS) 2.17% [28]
Least privilege 2.17% [28]
No shared memory access 2.17% [28]
Proper design 6.52% [38,41,61]
Secure languages 4.35% [28,58]
Smart contracts 6.52% [31,33,35]
TLS protocol 6.52% [26,28,36]
SGX technology with enclaves 6.52% [26,28,49]

• Deployment: Containers holding microservices can also be much emphasis are put to conceive solutions applicable at soft-
sources of vulnerabilities. Containers can be compromised infrastructure and API gateways where less attention is being paid
through gaining an unauthorized access or deriving vulner- to composition and hard-infrastructure layers.
abilities from using images from untrusted sources. Thus,
appropriate security measures should also be taken at this 5.3.2. MSA security mechanisms target platforms (RQ4)
The identified papers in this study are classified regarding the
level.
target platforms and applications for their proposed solutions.
• Soft-Infrastructure: Infrastructure vulnerabilities are lower Table 11 shows that 34.78% of papers proposed MSA security
level vulnerabilities that can affect practically every soft- solutions that work for different platforms; closer proportion is
ware entity running on the network including monitors, found for solutions to deal with securing microservices in the
registries, message brokers, load balancers and other orches- cloud platform. Few studies proposed platform specific solutions
trators. Thus, introducing techniques at this level to guaran- such as 5G platform, IoT, Web applications, kubernetes platforms
tee the security of the diverse software network entities and and Springer framework.
the safety of their configuration is of higher importance.
• Hard-Infrastructure: Hardware components are also vulnera- 5.3.3. Microservice security V&V methods (RQ5)
ble to attacks. Attackers may use bugs and backdoors inten- For validating the proposed solutions, we distinguished the
tionally or unintentionally introduced at manufacturing [68] use of several verification and validation approaches:
to initiate attacks. These vulnerabilities need to be tackled • Validation by simulation: this includes: (1) use of simulated
by introducing appropriate error and backdoor detection lab environments or testbeds for testing proposed designs,
mechanisms. (2) simulation of attacks with check bypassing of proposed
security measures.
Table 10 shows the distribution of solutions provided by pri- • Manual testing: this includes: (1) use case-based testing, (2)
mary studies per their application layers. The study revealed that emulate attacks, and (3) reconfigure-testing cycles.
10
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Table 10
MSA security application levels.
Application Layer Percentage Studies
Microservice 20.00% [1,27,39,46–48,60,63,67]
Composition 6.67% [38,41,48]
API 35.56% [12,24,28–31,33,35–37,46,50–53,59]
Communication 22.22% [26,28,30,31,35–37,54,59,65]
Deployment 13.33% [26,40,45,46,49,66]
Soft-Infrastructure 68.89% [1,12,24,25,27–34,36,37,39,42–44,47–49,51,55–60,62,64,67]
Hard-Infrastructure 8.89% [26,40,42,49]

Table 11
MSA security application platforms.
Applications/ Platforms Percentage Studies
IoT applications 13.04% [32,36,43,46,47,58]
Cloud platforms 28.26% [26,30,33,34,37,40,44,45,49,55,57,64,67]
Osmotic computing 2.17% [35]
Container-based platforms 10.87% [39,40,42,56,62]
Web applications 6.52% [44,63,66]
Springer platform 4.35% [50,52]
Kubernetes platform 2.17% [25]
5G platform 2.17% [59]
Independent 34.78% [1,12,24,27–29,31,38,41,48,51,53,54,60,61,65]

Table 12
MSA security verification and validation methods.
V&V methods Percentage Studies
Simulation 6.52% [25,36,47]
Manual Testing 8.70% [42,44,52,66]
Performance analysis 39.13% [1,26,28,29,32,34,36,37,40,42–44,47,49,57,58,64,67]
Qualitative analysis 10.87% [27,30,51,53,64]
Quantitative analysis 8.70% [37,43,56,67]
Adhoc metrics 6.52% [39,42,43]
Case study based validation 26.09% [24,31,33,36,38,46,54,60–63,65]
Proof of concept (POC) 2.17% [50]
Tool-based testing 10.87% [52,55,59,61,67]
Formal verification 2.17% [41]
Complexity measuring 6.52% [1,42,45]
Methodology-based validation 4.35% [39,45]

• Performance analysis: this is performed by measuring over- • Methodology based analysis: use predefined and well-known
heads, latency, throughput, memory storage, CPU usage, methodologies such as OWASP risk rating, attack surface or
response time, and traffic measurement. security risk comparison.
• Qualitative analysis: compare or verify and validate a set
Table 12 shows that performance analysis and case study
of qualitative requirements. These include: causing single
based validation are the most adopted techniques for verification
point to failure, complexity of cracking, complexity of im- and validation. Formal verification, POC and methodology-based
plementation and potential inherent bottleneck. analysis are the least used methods for validation. Validation by
• Quantitative analysis: comparing the proposed solution with simulation and adhoc metrics are found used in equal measure
similar proposals using quantitative metrics such as session with a rate equal to 6.52%. Most simulation methods adopted
sustainability, and popular machine learning metrics. simulated lab environments or testbeds. Only P3 used simulated
• Adhoc metrics: proposing specific metrics for the evaluation attacks to evaluate the proposed technique. Note that most ex-
of proposals. For example, P18 proposed a diversification amined studies used more than one validation techniques and 2
index as a security measure to validate the proposal. Authors studies (P17 and P27) proposed solutions without using any men-
of P21 used a quality of deception metric to evaluate the tioned validation technique. Instead, they discussed the details of
proposed deception mechanism. proposed solutions and claimed that they are sufficient enough
• Case study based validation: use case studies to validate the to mitigate the addressed security threat(s).
feasibility of the proposed solution.
• Proof of concept (POC): develop a prototype to demonstrate 6. An ontology for securing MSA
the feasibility of the proposed solution.
• Tool-based testing: use unit-based testing tools such as Intel- Making the results of our study practical and extendable and
liJ IDEA.3 due to the static nature of taxonomies, we propose an ontology-
• Formal verification: use model checkers or theorem provers based representation of our results similar to the approach pro-
to check the validity of specified properties. posed in [69]. Within an ontology, one can describe relationships
• Complexity measuring: estimate temporal complexity of pro- among ontology concepts and individuals. In our study, rela-
posed algorithms implementing solutions. tionships between security threats and security mechanisms are
mandatory. In addition, mapping security mechanisms to their
applicability architectural levels and platforms is necessary. Fig. 8
3 IntelliJ IDEA: https://www.jetbrains.com/fr-fr/idea/. describes the overall MSA ontology retrieved from this study.
11
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Table 13 7.1. Bias towards external threats, user and data attacks
Relationships between ontology classes.
Object Properties Domain Range Although IBM X-Force [70] reported that 60% of all attacks
applicableAt SecurityMechanism ArchitecturalLayer were carried out by insiders, the study shows that only 13%
applicableTo SecurityMechanism TargetPlatform of primary studies focus on internal attacks. This is probably
hasSource SecurityThreat ThreatSource
due to the fact that external threats are easier to be handled
hasType SecurityMechanism SolutionType
treatedBy SecurityThreat SecurityMechanism compared with internal threats. External threats are common in
treats SecurityMechanism SecurityThreat networking systems and can usually be identified and prevented
validatedThrough SecurityMechanism Security_V&V_Technique by means of strong firewalls and intrusion detection systems;
internal threats often requires considerable policy changes and
Table 14
continuous monitoring of internal traffics. This is owing to privi-
OWL-DL Query samples. leges awarded and sensitive data exposed to insiders. Moreover,
ID Query the diversity of attacks is basically due to the adoption of Zero
Q1 SecurityMechanism and (treats value Unauthorized_Access)
Trust model [71] that suggests to afford no default trust to users,
Q2 SecurityThreat and (treatedBy value Continuous_Monitoring) devices, applications, or packets; instead every action and entity
Q3 SecurityMechanism and (applicableAt value Microservice) need to be authenticated and authorized appropriately. Moreover,
Q4 SecurityThreat and (hasSource value Internal) infrastructure attacks are less addressed due to their complexity
since most attacks require low level solutions especially those
related to hardware, nodes and operating systems. Attacks from
The ontology is developed using Protégé4 and its consistency and other categories often require high level or software-based so-
lutions that can easily be integrated into existing platforms and
coherence are checked using the Protégé Debugger option. The
technologies. This justifies why software, user-based, and data
main concepts of the ontology are:
attacks earned more attention than infrastructure attacks. Thus,
1. SecurityMechanism: describes the set of security mecha- we advocate for research studies that investigate threats caused
by insiders in microservice-based applications. In addition, we
nisms proposed for MSA that have been retrieved by this
suggest to investigate all OWASP identified vulnerabilities with
study.
their effects when adopting microservice architectures.
2. SecurityThreat: describes the set of security threats threat-
ening microservices and microservice architecture that 7.2. Lack of innovative solutions for authorization and mitigation
have been retrieved by this study.
3. ArchitecturalLayer: describes the different architectural lay- The mapping results showed that much emphasis is put on
ers of MSA. authentication and authorization techniques. In fact, this is de-
4. TargetPlatform: describes the set of platforms addressed fensible since authentication and authorization are basic security
by the security mechanisms retrieved by this study. For mechanisms to any secure system. They form a front defense
platform independent solutions, an individual named Inde- line in the protection of the different microservice architecture
pendent is added to this concept class. elements (i.e. individual microservices, API gateway, containers,
5. SolutionType: describes the solution type for each proposed microservice registry, etc.). However, studies considering authen-
mechanism. tication and authorization are less innovative since they propose
6. ThreatSource: describes the source of each threat: internal combination of existing techniques and standards. For example,
or external. the authors of P8 proposed a combination of OAuth 2.0, JWT,
7. Security_V&V_Technique: describes the verification and val- Open ID and SSO used by a special authentication and autho-
idation techniques used for recognized security mecha- rization orchestrator. On the contrary, besides general continuous
monitoring and code analysis, audition proposals are showing
nisms.
the integration of artificial intelligence techniques such as ma-
Relationships between classes are reflected through Protégé chine learning and self-learning algorithms (P10, P22, P35). Those
techniques are based on runtime analysis of user and/or mi-
object properties presented in Table 13.
croservice behaviors and (semi-)automatically take predefined
For the usability of the ontology, OWL-DL queries can be used
actions in reaction to suspicious behaviors. Most, if not all, pro-
to investigate the ontology structure. Table 14 describes some of
posals for mitigation are Moving Target Defense-based solutions
useful queries described in OWL-DL. In Table 14, Q1 can be used (MTD) [72]. The idea behind MTD is to continuously perform
to retrieve the list of security mechanisms applied to deal with transformation of system components and configurations pre-
Unauthorized_access threat. Q2 returns the list of security threats venting attackers from acquiring knowledge about target systems
that can be alleviated by continuous monitoring. Q3 returns the to be used to initiate harmful attacks. This includes periodically
list of security mechanisms applied at individual microservices. update or restart microservices, IP shuffling, and live migration of
Finally, Q4 returns the list of internal threats recognized in this microservices. Specifically, the authors of P21 proposed deception
study. The overall ontology is available at https://github.com/ through live cloning and sandboxing of suspicious containers
hannousse/MSASecurity in an OWL format. respecting the same network overloading and performance to
deceive attackers. Prevention proposals are the most diverse tech-
niques. They vary from using physical computing devices such
7. Discussion as Hardware Security Module (HMS), powerful techniques and
technologies such as encryption and Blockchain into adopting
In this section, we highlight potential research gaps that re- software design decisions such as using secure programming
quire further investigations in the field. Those research gaps are languages and smart contracts. Therefore, more powerful and in-
basically identified through the analysis of the mapping results. novative solutions are required for authentication/authorization.
Moreover, due to the lower rate of mitigation techniques and
their applicability to existing microservice-based systems, we
4 https://protege.stanford.edu/. advocate more research on mitigation.
12
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

Fig. 8. Ontology for MSA security.

7.3. Lack of appropriate solutions to secure individual microservices side, performance analysis is very important for checking the
suitability of proposed solutions to particular environments and
Although, microservices are the mainstay of MSA, securing platforms; it is also important for decision makers. Even though
individual microservices is not getting a higher rate. The less performance analysis is applicable to different proposals and
interest in hard-infrastructure solutions is defensible due to their found adopted with the higher rate (39.13%) not all the studies
complexity and cost-intensive compared with soft-infrastructure have adopted it. Note that the diversity and incompatibility of
based solutions. However, individual microservices, their com- validation techniques make the comparison of proposed solutions
position and communication should have much attention than harder. The adoption of performance analysis by all the studies
that has been revealed. Specifically, communication protection is may alleviate this problem.
of a high importance regarding the huge number and nature of
transmitted data in the communication channels. 8. Threats to validity

7.4. Lack of appropriate solutions to emerging technologies In this section we describe construct, internal, external and
conclusion validity threats and how we mitigated their effects on
Cloud-focused and platform independent solutions are found the obtained results.
within higher rates, 34.78% and 28.26%, respectively. The interest
to cloud computing is understandable due to different facilities 8.1. Construct validity
provided to companies by adopting MSA for developing their
applications. Adopting MSA for developing applications in the A construct validity threat to our study concerns the identifi-
cloud allow companies to integrate existing legacy systems, to cation of primary studies from the large set of papers found in the
grow with demands and to use up-to-date and intuitive inter- literature. For this sake, we adopted the guidelines of Kuhrmann
faces. Solutions provided for IoT applications are also getting et al. [16] for the selection of search engines. Search keywords
more attentions due to the specificity and the growing needs to are carefully chosen; they are meant to be as general as possible
those applications in the market. However, more attention should and designed following the guidelines Petticrew and Roberts [17].
be paid to 5G platforms. These are emerging technologies that To avoid bias to search engines, we completed our search by
requires specific attentions. snowballing technique [19] over already identified papers. The
use of several iterations of the snowballing technique allowed
7.5. Absence of appropriate comparison techniques the identification of nine more relevant papers in which five
were not indexed by the selected search engines. For ensuring
The study revealed the adoption of several validation tech- the inclusion of high quality papers, we adopted a set of strict
niques. This is due to the nature of proposed solutions. For ex- inclusion and exclusion criteria where only peer-reviewed journal
ample, formal verification is adopted when formal specification of and conference papers are acceted for their completeness and suf-
systems and their properties are described (e.g.; p20). In the other ficient results. However, since only papers explicitly referring to
13
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

microservices or microservice architectures were included, some microservices that can radically lead to a chain defection in MSA.
papers focusing on securing the deployment layer, specifically Moreover, continuous monitoring became very popular among
Docker containers [73] were omitted. MSA designers to prevent possibly future threats. Encryption
remains the most used technique facing sensitive data exposure.
8.2. Internal validity Regarding noticed unbalanced research focus on external attacks
and prevention techniques, we advocate more studies studying
An internal validity threat concerns the data extraction from internal attacks and proposing mitigation techniques. Moreover,
the set of included studies. Both authors are incorporated in more studies are suggested for treating individual microservice
this process. Following the guidelines of Peterson et al. [7], a and communication layers vulnerabilities.
data extraction form is designed by the first author, discussed
and updated after a deep discussion with the second author. Declaration of competing interest
Each author has filled the form independently; after solving the
disagreements between the two authors, a unique and final form The authors declare that they have no known competing finan-
is adopted for the rest of the study. Following the guidelines of cial interests or personal relationships that could have appeared
Kitchenham et al. [6], the kappa coefficient is estimated and found to influence the work reported in this paper.
equal 0.94 which is evaluated as very good or almost perfect score
according to [6].
References
8.3. External validity
[1] T. Yarygina, A.H. Bagge, Overcoming security challenges in microservice
architectures, in: 2018 IEEE Symposium on Service-Oriented System En-
An external validity threat concerns the generalization of the gineering (SOSE), 2018, pp. 11–20, http://dx.doi.org/10.1109/SOSE.2018.
results of the study. The classification schemes adopted in this 00011.
mapping are constructed based on retrieved papers. Future pub- [2] S. Baškarada, V. Nguyen, A. Koronios, Architecting microservices: Practical
opportunities and challenges, J. Comput. Inf. Syst. (2018) 1–9, http://dx.
lished studies may fit to the proposed scheme where many others doi.org/10.1080/08874417.2018.1520056.
may not. For this sake, we developed an ontology incorporat- [3] N. Dragoni, S. Giallorenzo, A.L. Lafuente, M. Mazzara, F. Montesi, R.
ing all the classification schemes. The constructed ontology is Mustafin, L. Safina, Microservices: Yesterday, Today, and Tomorrow,
made freely available for researchers and practitioners for further Springer International Publishing, Cham, 2017, pp. 195–216, (Chapter 12).
updates when new studies are published and not fitting the http://dx.doi.org/10.1007/978-3-319-67425-4_12.
[4] N. Alshuqayran, N. Ali, R. Evans, A systematic mapping study in mi-
proposed schemes.
croservice architecture, in: 2016 IEEE 9th International Conference on
Service-Oriented Computing and Applications (SOCA), IEEE, 2016, pp.
8.4. Conclusion validity 44–51.
[5] J. Bogner, J. Fritzsch, S. Wagner, A. Zimmermann, Microservices in indus-
A conclusion validity threat to our study concerns the adop- try: Insights into technologies, characteristics, and software quality, in:
2019 IEEE International Conference on Software Architecture Companion
tion of taxonomies for security threats and mechanisms. In fact, (ICSA-C), 2019, pp. 187–195, http://dx.doi.org/10.1109/ICSA-C.2019.00041.
several taxonomies are investigated [1,11,22], however, none of [6] B.A. Kitchenham, D. Budgen, P. Brereton, Evidence-Based Software
those taxonomies enables the proper classification of all the iden- Engineering and Systematic Reviews, Chapman & Hall/CRC, 2015.
tified studies. Thus, we used open and selective coding from [7] K. Petersen, R. Feldt, S. Mujtaba, M. Mattsson, Systematic mapping studies
grounded theory [23] and we adopted a classification based on in software engineering, in: Proceedings of the 12th International Con-
ference on Evaluation and Assessment in Software Engineering, EASE’08,
deeper analysis of the focus and the proposed solutions of iden- Swindon, UK, 2008, pp. 68–77.
tified papers. Some of the categories of our classifications are [8] K. Petersen, S. Vakkalanka, L. Kuzniarz, Guidelines for conducting sys-
already used in existing taxonomies, some are either used as they tematic mapping studies in software engineering: An update, Inf. Softw.
are or adapted to fulfill the context of our study. Technol. 64 (2015) 1–18, http://dx.doi.org/10.1016/j.infsof.2015.03.007.
[9] A.P. Vale, G. Márquez, H. Astudillo, E.B. Fernandez, Security mechanisms
used in microservices-based systems: A systematic mapping, in: XLV Latin
9. Conclusion
American Computing Conference, 2019, pp. 1–10.
[10] D. Yu, Y. Jin, Y. Zhang, X. Zheng, A survey on security issues in ser-
In this study, we conducted a systematic mapping on securing vices communication of microservices-enabled fog applications, Concurr.
microservices focusing on threats, nature, applicability platforms, Comput.: Pract. Exper. 31 (22) (2019) e4436, e4436 cpe.4436, http://dx.
and validation techniques of security proposals. The study exam- doi.org/10.1002/cpe.4436. arXiv:https://onlinelibrary.wiley.com/doi/pdf/10.
1002/cpe.4436.
ined 46 papers published since 2011. The results revealed that
[11] L. de Aguiar Monteiro, W.H.C. Almeida, R.R. Hazin, A.C. de Lima, S.K.G.
unauthorized access, sensitive data exposure and compromis- e Silva, F.S. Ferraz, A survey on microservice security–trends in architec-
ing individual microservices are the most treated and addressed ture, privacy and standardization on cloud computing environments, Int.
threats by contemporary studies. The results also revealed that J. Adv. Secur. 11 (3–4) (2018) 201–213.
auditing, enforcing access control, and prevention based solu- [12] P. Nkomo, M. Coetzee, Software development activities for secure mi-
croservices, in: S. Misra, O. Gervasi, B. Murgante, E. Stankova, V. Korkhov,
tions are the most proposed security mechanisms. Additionally, C. Torre, A.M.A. Rocha, D. Taniar, B.O. Apduhan, E. Tarantino (Eds.),
we found that most proposed solutions are applicable at soft- Poceedings of International Conference on Computational Science and its
infrastructure layer of MSA. Our study shows that 34.78% of Applications, ICCSA 2019, Springer International Publishing, Cham, 2019,
papers proposed MSA security solutions that work for different pp. 573–585.
platforms, the same proportion is noticed for cloud-based so- [13] S. Sultan, I. Ahmad, T. Dimitriou, Container security: Issues, challenges, and
the road ahead, IEEE Access 7 (2019) 52976–52996, http://dx.doi.org/10.
lutions. Finally, we found that most verification and validation 1109/ACCESS.2019.2911732.
methods were based on performance analysis, and case studies. [14] M. Bélair, S. Laniepce, J.-M. Menaud, Leveraging kernel security mecha-
We also proposed and made available an ontology summarizing nisms to improve container security: A survey, in: Proceedings of the 14th
and gathering the retrieved results. The proposed ontology can be International Conference on Availability, Reliability and Security, ARES ’19,
ACM, New York, NY, USA, 2019, pp. 76:1–76:6, http://dx.doi.org/10.1145/
used as a guide to developers about recognized threats and secu-
3339252.3340502.
rity mechanisms for MSA. We noticed that most addressed threats [15] M. Felderer, J.C. Carver, Guidelines for systematic mapping studies in secu-
are well-known for other architectural styles and few are con- rity engineering, in: Empirical Research for Software Security: Foundations
cerned directly with MSA. Specifically, compromising individual and Experience, CRC Press, 2018, pp. 47–69.

14
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

[16] M. Kuhrmann, D.M. Fernández, M. Daneva, On the pragmatic design of [35] A. Buzachis, M. and Villari, Basic principles of osmotic computing: Secure
literature studies in software engineering: an experience-based guideline, and dependable microelements (mels) orchestration leveraging blockchain
Empir. Softw. Eng. 22 (6) (2017) 2852–2891, http://dx.doi.org/10.1007/ facilities, in: 2018 IEEE/ACM International Conference on Utility and Cloud
s10664-016-9492-y. Computing Companion (UCC Companion), 2018, pp. 47–52, http://dx.doi.
[17] M. Petticrew, H. Roberts, Systematic Reviews in the Social Sciences: A org/10.1109/UCC-Companion.2018.00033.
Practical Guide, John Wiley & Sons, Ltd, 2006. [36] V.M. George, Q.H. Mahmoud, Claimsware: A claims-based middleware for
[18] C. Wohlin, Guidelines for snowballing in systematic literature studies and securing iot services, in: 2017 IEEE 41st Annual Computer Software and
a replication in software engineering, in: Proceedings of the 18th Interna- Applications Conference (COMPSAC), 1, 2017, pp. 649–654, http://dx.doi.
tional Conference on Evaluation and Assessment in Software Engineering, org/10.1109/COMPSAC.2017.85.
EASE ’14, Association for Computing Machinery, New York, NY, USA, 2014, [37] A. Ranjbar, M. Komu, P. Salmela, T. Aura, Synaptic: Secure and persistent
pp. 1–10, http://dx.doi.org/10.1145/2601248.2601268. connectivity for containers, in: 2017 17th IEEE/ACM International Sympo-
[19] C. Wohlin, Second-generation systematic literature studies using snow- sium on Cluster, Cloud and Grid Computing (CCGRID), 2017, pp. 262–267,
balling, in: Proceedings of the 20th International Conference on Evaluation http://dx.doi.org/10.1109/CCGRID.2017.62.
and Assessment in Software Engineering, EASE ’16, Association for Com- [38] M. Ahmadvand, A. Ibrahim, Requirements reconciliation for scalable and
puting Machinery, New York, NY, USA, 2016, pp. 1–6, http://dx.doi.org/10. secure microservice (de)composition, in: 2016 IEEE 24th International
1145/2915970.2916006. Requirements Engineering Conference Workshops (REW), 2016, pp. 68–73,
http://dx.doi.org/10.1109/REW.2016.026.
[20] M.S. Farooq, S. Riaz, A. Abid, T. Umer, Y.B. Zikria, Role of iot technology
[39] K.A. Torkura, M.I.H. Sukmana, A.V.D.M. Kayem, A cyber risk based
in agriculture: A systematic literature review, Electronics 9 (2). http:
moving target defense mechanism for microservice architectures, in:
//dx.doi.org/10.3390/electronics9020319.
2018 IEEE Intl Conf on Parallel Distributed Processing with Applica-
[21] A. Fernandez, E. Insfran, S. Abrahão, Usability evaluation methods for
tions, Ubiquitous Computing Communications, Big Data Cloud Computing,
the web: A systematic mapping study, Inf. Softw. Technol. 53 (8) (2011)
Social Computing Networking, Sustainable Computing Communications
789–817, http://dx.doi.org/10.1016/j.infsof.2011.02.007.
(ISPA/IUCC/BDCloud/SocialCom/SustainCom), 2018, pp. 932–939, http://dx.
[22] OWASP, Owasp Top 10: The Ten Most Critical Web Application Security doi.org/10.1109/BDCloud.2018.00137.
Risks, Tech. Rep., OWASP Foundation, 2017. [40] H. Jin, Z. Li, D. Zou, B. Yuan, Dseom: A framework for dynamic security
[23] A.L. Strauss, J.M. Corbin, Basics of Qualitative Research: Techniques and evaluation and optimization of mtd in container-based cloud, IEEE Trans.
Procedures for Developing Grounded Theory, Sage Publications, Thousand Dependable Secure Comput. (2019) 1–12, http://dx.doi.org/10.1109/TDSC.
Oaks, Calif, 1998. 2019.2916666.
[24] M. Ahmadvand, A. Pretschner, K. Ball, D. Eyring, Integrity protection [41] C. Gerking, D. Schubert, Component-based refinement and verification of
against insiders in microservice-based infrastructures: From threats to a information-flow security policies for cyber–physical microservice archi-
security framework, in: M. Mazzara, I. Ober, G. Salaün (Eds.), Proceedings tectures, in: 2019 IEEE International Conference on Software Architecture
of Federation of International Conferences on Software Technologies: (ICSA), 2019, pp. 61–70, http://dx.doi.org/10.1109/ICSA.2019.00015.
Applications and Foundations, Springer International Publishing, Cham, [42] A. Osman, P. Bruckner, H. Salah, F.H.P. Fitzek, T. Strufe, M. Fischer,
2018, pp. 573–588. Sandnet: Towards high quality of deception in container-based microser-
[25] N. Surantha, F. Ivan, Secure kubernetes networking design based on zero vice architectures, in: ICC 2019-2019 IEEE International Conference on
trust model: A case study of financial service enterprise in indonesia, Communications (ICC), 2019, pp. 1–7, http://dx.doi.org/10.1109/ICC.2019.
in: L. Barolli, F. Xhafa, O.K. Hussain (Eds.), Proceedings of International 8761171.
Conference on Innovative Mobile and Internet Services in Ubiquitous [43] M. Pahl, F. Aubet, All eyes on you: Distributed multi-dimensional iot
Computing, Springer International Publishing, Cham, 2020, pp. 348–361. microservice anomaly detection, in: 2018 14th International Conference
[26] S. Brenner, T. Hundt, G. Mazzeo, R. Kapitza, Secure cloud micro services on Network and Service Management (CNSM), 2018, pp. 72–80.
using intel sgx, in: L.Y. Chen, H.P. Reiser (Eds.), Proceedings of IFIP [44] R. Ravichandiran, H. Bannazadeh, A. Leon-Garcia, Anomaly detection using
International Conference on Distributed Applications and Interoperable resource behaviour analysis for autoscaling systems, in: 2018 4th IEEE
Systems, Springer International Publishing, Cham, 2017, pp. 177–191. Conference on Network Softwarization and Workshops (NetSoft), 2018, pp.
[27] C. Otterstad, T. Yarygina, Low-level exploitation mitigation by diverse 192–196, http://dx.doi.org/10.1109/NETSOFT.2018.8460025.
microservices, in: F. De Paoli, S. Schulte, E. Broch Johnsen (Eds.), Proceed- [45] Z. Wen, T. Lin, R. Yang, S. Ji, R. Ranjan, A. Romanovsky, C. Lin, J. Xu, Ga-
ings of the 6th IFIP WG 2.14 European Conference on Service-Oriented par: Dependable microservice orchestration framework for geo-distributed
and Cloud Computing, Springer International Publishing, Cham, 2017, pp. clouds, IEEE Trans. Parallel Distrib. Syst. (2019) 1–16, http://dx.doi.org/10.
49–56, http://dx.doi.org/10.1007/978-3-319-67262-5_4. 1109/TPDS.2019.2929389.
[46] D. Lu, D. Huang, A. Walenstein, D. Medhi, A secure microservice framework
[28] T. Yarygina, C. Otterstad, A game of microservices: Automated intrusion
for iot, in: 2017 IEEE Symposium on Service-Oriented System Engineering
response, in: S. Bonomi, E. Rivière (Eds.), Proceedings of IFIP Interna-
(SOSE), 2017, pp. 9–18, http://dx.doi.org/10.1109/SOSE.2017.27.
tional Conference on Distributed Applications and Interoperable Systems,
Springer International Publishing, Cham, 2018, pp. 169–177, http://dx.doi. [47] M. Pahl, L. Donini, Securing iot microservices with certificates, in: NOMS
org/10.1007/978-3-319-93767-0_12. 2018-2018 IEEE/IFIP Network Operations and Management Symposium,
2018, pp. 1–5, http://dx.doi.org/10.1109/NOMS.2018.8406189.
[29] A. Nehme, V. Jesus, K. Mahbub, A. Abdallah, Fine-grained access control for
[48] A. Nehme, V. Jesus, K. Mahbub, A. Abdallah, Securing microservices, IT Prof.
microservices, in: N. Zincir-Heywood, G. Bonfante, M. Debbabi, J. Garcia-
21 (1) (2019) 42–49, http://dx.doi.org/10.1109/MITP.2018.2876987.
Alfaro (Eds.), Proceedings of the International Symposium on Foundations
[49] C. Fetzer, Building critical applications using microservices, IEEE Secur.
and Practice of Security, Springer International Publishing, Cham, 2019, pp.
Privacy 14 (6) (2016) 86–89, http://dx.doi.org/10.1109/MSP.2016.129.
285–300, http://dx.doi.org/10.1007/978-3-030-18419-3_19.
[50] Q. Nguyen, O.F. Baker, Applying spring security framework and oauth2 to
[30] A. Bánáti, E. Kail, K. Karóczkai, M. Kozlovszky, Authentication and au-
protect microservice architecture API, JSW 14 (6) (2019) 257–264.
thorization orchestrator for microservice-based software architectures,
[51] X. He, X. Yang, Authentication and authorization of end user in microser-
in: 2018 41st International Convention on Information and Communi-
vice architecture, J. Phys. Conf. Ser. 910 (2017) 012060, http://dx.doi.org/
cation Technology, Electronics and Microelectronics (MIPRO), 2018, pp.
10.1088/1742-6596/910/1/012060.
1180–1184, http://dx.doi.org/10.23919/MIPRO.2018.8400214.
[52] O. Baker, Q. Nguyen, A novel approach to secure microservice architecture
[31] D. Nagothu, R. Xu, S.Y. Nikouei, Y. Chen, A microservice-enabled archi- from owasp vulnerabilities, in: Proceedings of the 10th Annual CITRENZ
tecture for smart surveillance using blockchain technology, in: 2018 IEEE Conference (2019), ITx New Zealand’s Conference of IT, Nelson, NZ, 2019,
International Smart Cities Conference (ISC2), 2018, pp. 1–4, http://dx.doi. pp. 54–58.
org/10.1109/ISC2.2018.8656968. [53] J. Salibindla, Microservices api security, Int. J. Eng. Res. Technol. 7 (1)
[32] M. Pahl, F. Aubet, S. Liebald, Graph-based iot microservice security, (2018) 277–281.
in: NOMS 2018-2018 IEEE/IFIP Network Operations and Management [54] K. Jander, L. Braubach, A. Pokahr, Practical defense-in-depth solution for
Symposium, 2018, pp. 1–3, http://dx.doi.org/10.1109/NOMS.2018.8406118. microservice systems, J. Ubiquit. Syst. Pervasive Netw. 11 (1) (2019) 17–25,
[33] Tran Quang Thanh, S. Covaci, T. Magedanz, P. Gouvas, A. Zafeiropoulos, http://dx.doi.org/10.5383/juspn.11.01.003.
Embedding security and privacy into the development and operation of [55] K.A. Torkura, M.I. Sukmana, F. Cheng, C. Meinel, Cavas: Neutralizing
cloud applications and services, in: 2016 17th International Telecommuni- application and container security vulnerabilities in the cloud native era,
cations Network Strategy and Planning Symposium (Networks), 2016, pp. in: International Conference on Security and Privacy in Communication
31–36, http://dx.doi.org/10.1109/NETWKS.2016.7751149. Systems, Springer, 2018, pp. 471–490.
[34] Y. Sun, S. Nanda, T. Jaeger, Security-as-a-service for microservices-based [56] J. Chen, H. Huang, H. Chen, Informer: Irregular traffic detection for
cloud applications, in: 2015 IEEE 7th International Conference on Cloud containerized microservices rpc in the real world, in: Proceedings of the
Computing Technology and Science (CloudCom), 2015, pp. 50–57, http: 4th ACM/IEEE Symposium on Edge Computing, SEC ’19, ACM, New York,
//dx.doi.org/10.1109/CloudCom.2015.93. NY, USA, 2019, pp. 389–394, http://dx.doi.org/10.1145/3318216.3363375.

15
A. Hannousse and S. Yahiouche Computer Science Review 41 (2021) 100415

[57] K.A. Torkura, M.I. Sukmana, C. Meinel, Integrating continuous security [64] M. Krämer, S. Frese, A. Kuijper, Implementing secure applications in smart
assessments in microservices and cloud native applications, in: Proceedings city clouds using microservices, Future Gener. Comput. Syst. 99 (2019)
of The10th International Conference on Utility and Cloud Computing, UCC 308–320, http://dx.doi.org/10.1016/j.future.2019.04.042.
’17, ACM, New York, NY, USA, 2017, pp. 171–180, http://dx.doi.org/10. [65] K. Jander, L. Braubach, A. Pokahr, Defense-in-depth and role authentication
1145/3147213.3147229. for microservice systems, Procedia Comput. Sci. 130 (2018) 456–463,
[58] S. Akkermans, B. Crispo, W. Joosen, D. Hughes, Polyglot cerberos: Re- the 9th International Conference on Ambient Systems, Networks and
source security, interoperability and multi-tenancy for iot services on Technologies (ANT 2018) / The 8th International Conference on Sustainable
a multilingual platform, in: Proceedings of the 15th EAI International Energy Information Technology (SEIT-2018) / Affiliated Workshops. http:
Conference on Mobile and Ubiquitous Systems: Computing, Networking //dx.doi.org/10.1016/j.procs.2018.04.047.
and Services, MobiQuitous ’18, ACM, New York, NY, USA, 2018, pp. 59–68, [66] S. Abidi, M. Essafi, C.G. Guegan, M. Fakhri, H. Witti, H.H.B. Ghezala, A
http://dx.doi.org/10.1145/3286978.3286997. web service security governance approach based on dedicated micro-
[59] D. Guija, M.S. Siddiqui, Identity and access control for micro-services based services, in: Knowledge-Based and Intelligent Information & Engineering
5g nfv platforms, in: Proceedings of the 13th International Conference on Systems: Proceedings of the 23rd International Conference KES2019, Pro-
Availability, Reliability and Security, ARES 2018, ACM, New York, NY, USA, cedia Comput. Sci. 159 (2019) 372–386, http://dx.doi.org/10.1016/j.procs.
2018, pp. 46:1–46:10, http://dx.doi.org/10.1145/3230833.3233255. 2019.09.192.
[60] X. Li, Y. Chen, Z. Lin, Towards automated inter-service authorization for [67] M. Elsayed, M. Zulkernine, Offering security diagnosis as a service for cloud
microservice applications, in: Proceedings of the ACM SIGCOMM 2019 saas applications, J. Inf. Secur. Appl. 44 (2019) 32–48, http://dx.doi.org/10.
Conference Posters and Demos, SIGCOMM Posters and Demos ’19, ACM, 1016/j.jisa.2018.11.006.
New York, NY, USA, 2019, pp. 3–5, http://dx.doi.org/10.1145/3342280. [68] V. Mavroudis, A. Cerulli, P. Svenda, D. Cvrcek, D. Klinec, G. Danezis,
3342288. A touch of evil: High-assurance cryptographic hardware from untrusted
[61] G. Márquez, H. Astudillo, Identifying availability tactics to support security components, in: Proceedings of the 2017 ACM SIGSAC Conference on Com-
architectural design of microservice-based systems, in: Proceedings of the puter and Communications Security, CCS ’17, Association for Computing
13th European Conference on Software Architecture - Volume 2, ECSA ’19, Machinery, New York, NY, USA, 2017, pp. 1583–1600, http://dx.doi.org/10.
ACM, New York, NY, USA, 2019, pp. 123–129, http://dx.doi.org/10.1145/ 1145/3133956.3133961.
3344948.3344996. [69] A.P. Vale, E.B. Fernandez, An ontology for security patterns, in: 2019 38th
[62] A. Ibrahim, S. Bozhinoski, A. Pretschner, Attack graph generation for International Conference of the Chilean Computer Science Society (SCCC),
microservice architecture, in: Proceedings of the 34th ACM/SIGAPP Sym- 2019, pp. 1–8, http://dx.doi.org/10.1109/SCCC49216.2019.8966393.
posium on Applied Computing, SAC ’19, ACM, New York, NY, USA, 2019, [70] IBM, An integrated approach to insider threat protection, 2016, URL https:
pp. 1235–1242, http://dx.doi.org/10.1145/3297280.3297401. //www.ibm.com/security/services/insider-threat-protection.
[63] D.M. Stallenberg, A. Panichella, Jcomix: A search-based tool to detect xml [71] J. Kindervag, S. Balaouras, K. Mak, Build Security Into Your Network’s Dna:
injection vulnerabilities in web applications, in: Proceedings of the 2019 The Zero Trust Network Architecture, Tech. rep. Forrester Research, 2012.
27th ACM Joint Meeting on European Software Engineering Conference and [72] R. Zhuang, S.A. DeLoach, X. Ou, Towards a theory of moving target defense,
Symposium on the Foundations of Software Engineering, ESEC/FSE 2019, in: Proceedings of the First ACM Workshop on Moving Target Defense,
ACM, New York, NY, USA, 2019, pp. 1090–1094, http://dx.doi.org/10.1145/ MTD ’14, Association for Computing Machinery, New York, NY, USA, 2014,
3338906.3341178. pp. 31–40, http://dx.doi.org/10.1145/2663474.2663479.
[73] D. Merkel, Docker: lightweight linux containers for consistent development
and deployment, Linux J. 2014 (239) (2014) 2.

16